On Wed, Oct 10, 2012 at 10:50 PM, Murali Krishna Bachu
wrote:
> Hi,
>
> Links in PHP Doc page sidebar are pointed to wrong links. They are not
> accessible.
>
> http://in2.php.net/curl_version
>
> One of the Sidebar link :
> http://in2.php.net/203.199.107.5manual/en/function.curl-close.php
>
> C
Em 2012-10-10 15:52, Tjerk Meesters escreveu:
Sent from my iPhone
On 10 Oct, 2012, at 6:39 PM, Nicolai Scheer
wrote:
Hi again!
Thanks for your help an comments on the issue.
cataphract commented on the stream_get_line behaviour (returning
false
when used on an empty file) on the bug rep
On Thu, Oct 11, 2012 at 2:35 AM, Clint Priest wrote:
> Okay, I would like this to be the last time there are revisions to this
> RFC.
>
> To sum up the last few days of conversations, I have these down as points
> of contention:
>
> 1. Accessor functions should not be present on the object and c
(Let me suggest an idea irrelevant. Sorry...)
The performance of getters is critical.
For me the best solution would be a new keyword, equivalent to a "var"
without write access from outside the class:
class TimePeriod {
*property* $Hours = 1;
public function setHours($h) {
On Oct 11, 2012, at 4:59 AM, Clint Priest wrote:
> Why is everyone so dead set against read-only and write-only?
>
> I could not disagree more with you on what is "pretty" and "readable".
>
> To me:
>
> public read-only $hours {
>get { ... }
> }
>
> Is infinitely more readable
2012/10/11 Clint Priest
> Why is everyone so dead set against read-only and write-only?
>
my opinion
1.
public read-only $hours {
get { /* .. */ }
set { /* .. */ }
}
And now? That this is even possible is reason enough for me. Especially now
the engine must take care about this incon
hi,
On Thu, Oct 11, 2012 at 2:16 PM, Sebastian Krebs wrote:
> public read-only $hours {
> get { /* .. */ }
> set { /* .. */ }
> }
that should not be possible or it will be too complicated to document
or to use. Combinations of the readonly option and a setter should not
be possible.
This would produce a compile error, cannot define set, property is read-only.
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Thursday, October 11, 2012 7:43 AM
> To: Sebastian Krebs
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Propety Accesso
On 11 October 2012 12:46, Cal wrote:
> For me the best solution would be a new keyword, equivalent to a "var"
> without write access from outside the class:
New keywords should not (will not) be introduced trivially, they can
cause massive headaches with backwards compatibility breaks, and
should
On 10/10/12 10:46 PM, Jazzer Dane wrote:
If at all possible, I'd rather not add extra keywords such as read-only and
write-only to the language. If it's unnecessary than it shouldn't be done -
that's my point of view. The question is thus "is read-only necessary?".
The proposal brought up by some
Rather than go to the trouble of finding a reasonable way to hold a vote on
these issues, is there anyone against the following changes:
1) Eliminate the ability for an accessor to be called via $o->__getHours(), the
accessor functions will be completely unavailable for use except as property
r
I'm in favor of all your points Clint and type hinting would be very valuable
to me. Also, I would favor if reflection does not reveal internals either. If I
am correct, that would require ReflectionClass to have
getPropertyAccessors()/getPropertyAccessor('Hours') method and a new
ReflectionPro
2012/10/11 Clint Priest
> Rather than go to the trouble of finding a reasonable way to hold a vote
> on these issues, is there anyone against the following changes:
>
> 1) Eliminate the ability for an accessor to be called via
> $o->__getHours(), the accessor functions will be completely unavaila
You really don't want to even think about my idea? It's complementary on
some aspects, you know.
2012/10/11 Clint Priest
> Rather than go to the trouble of finding a reasonable way to hold a vote
> on these issues, is there anyone against the following changes:
>
> 1) Eliminate the ability for a
PHP Trunk, developing bug fixes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I guess I didn't see any other support for it from others and it is a subset of
what the RFC I am proposing would encompass, did I miss something with your
original email?
From: amaury.bouch...@gmail.com [mailto:amaury.bouch...@gmail.com] On Behalf Of
Amaury Bouchard
Sent: Thursday, October 11,
Alright, here is the updated RFC as per discussions for the last few days:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
If you could read it over, make sure I have all of your concerns correctly
addressed and we can leave this open for the two week waiting period while I
make th
I like it.
I assume that, in regards to static properties, the static keyword works
just as well as self and parent, correct?
On Thu, Oct 11, 2012 at 10:23 PM, Clint Priest wrote:
> Alright, here is the updated RFC as per discussions for the last few days:
>
> https://wiki.php.net/rfc/propertyge
18 matches
Mail list logo
