Clint Priest wrote:
I certainly would not want to push through the door a low quality solution, I would never
do that, but I have been working on this project myself for a year and each time I come
back, having addressed the concerns of the last batch of opinions there are a whole new
set of
On Wed, Oct 10, 2012 at 10:50 PM, Murali Krishna Bachu
murali_nit...@yahoo.co.in 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 :
Em 2012-10-10 15:52, Tjerk Meesters escreveu:
Sent from my iPhone
On 10 Oct, 2012, at 6:39 PM, Nicolai Scheer
nicolai.sch...@gmail.com 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
On Thu, Oct 11, 2012 at 2:35 AM, Clint Priest cpri...@zerocue.com 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
(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 cpri...@zerocue.com 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
2012/10/11 Clint Priest cpri...@zerocue.com
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
hi,
On Thu, Oct 11, 2012 at 2:16 PM, Sebastian Krebs krebs@gmail.com 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
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 Accessors
On 11 October 2012 12:46, Cal c...@icical.net 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
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
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
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
2012/10/11 Clint Priest cpri...@zerocue.com
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
You really don't want to even think about my idea? It's complementary on
some aspects, you know.
2012/10/11 Clint Priest cpri...@zerocue.com
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
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
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
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 cpri...@zerocue.com wrote:
Alright, here is the updated RFC as per discussions for the last few days:
19 matches
Mail list logo
