Hi!
> I asked many native speakers and all understood it as "when 5.5.0 stable
> release will be announced".
I didn't even think it may mean anything else until I've read this
thread. I don't think any significant number of voters understood it
this way, it's sound kind of weird - why would we wa
Hi Chris,
On Jan 24, 2013 2:35 AM, "Christopher Jones"
wrote:
>
>
>
> On 01/23/2013 09:37 AM, Florian Anderiasch wrote:
>>
>> On 01/21/2013 11:44 PM, Christopher Jones wrote:
>>
>>> Pierre,
>>>
>>> Can you review this RFC and the votes? The wording "5.5 final
>>> release" needs assessing. You p
On Wed, Jan 23, 2013 at 10:35 PM, Clint Priest wrote:
> On 1/23/2013 3:17 PM, Levi Morrison wrote:
>> Clint: I'm sorry that you spent all that time without hearing feedback
>> from a lot of the "No" voters. Had they been participating all along
>> perhaps it could have been avoided. We'll never kn
On 01/23/2013 09:37 AM, Florian Anderiasch wrote:
On 01/21/2013 11:44 PM, Christopher Jones wrote:
Pierre,
Can you review this RFC and the votes? The wording "5.5 final
release" needs assessing. You probably meant "first 5.5 production
release". If anyone interpreted it as it is actually
>> I also don't like the `?` for `nullable`. Just stick with PHP
>> convention and do:
>>
>> class Foo {
>> public Bar $bar = NULL;
>> }
>
>
> There is no such PHP convention. The PHP convention is *not restrict type*
> (+"loosely typed" addons).
> So NULL is automatically allow
Thank you! Will look at it tomorrow.
Am 24.01.2013 00:45, schrieb Clint Priest:
On 1/23/2013 5:04 PM, Crypto Compress wrote:
guard->in_unset = 1; /* Prevent recursion */
zend_call_method_with_1_params(&object, zobj->ce, &zobj->ce->__unset,
ZEND_UNSET_FUNC_NAME, NULL, member);
guard->in_unset
On 1/23/2013 5:04 PM, Crypto Compress wrote:
guard->in_unset = 1; /* Prevent recursion */
zend_call_method_with_1_params(&object, zobj->ce, &zobj->ce->__unset,
ZEND_UNSET_FUNC_NAME, NULL, member);
guard->in_unset = 0; /* Prevent recursion */
a) That applies to __unset (magic method) only
b) g
Hello!
1) not able to vote
2) looked at patch
3) do not understand the patch
so i have a question regarding guards... e.g.:
guard->in_unset = 1; /* Prevent recursion */
zend_call_method_with_1_params(&object, zobj->ce, &zobj->ce->__unset,
ZEND_UNSET_FUNC_NAME, NULL, member);
guard->in_unset =
On 1/23/2013 4:40 PM, Rasmus Lerdorf wrote:
I appreciate that, I'm hearing through the grapevine that some of the
"no" voters haven't even looked at the patch.
Just to be fair, I suspect quite a few "yes" voters haven't looked at,
nor understood the patch.
-Rasmus
I'd bet good money that's tr
On 01/23/2013 02:35 PM, Clint Priest wrote:
>
> On 1/23/2013 3:17 PM, Levi Morrison wrote:
>> Clint: I'm sorry that you spent all that time without hearing feedback
>> from a lot of the "No" voters. Had they been participating all along
>> perhaps it could have been avoided. We'll never know.
>
>
On 1/23/2013 3:17 PM, Levi Morrison wrote:
Clint: I'm sorry that you spent all that time without hearing feedback
from a lot of the "No" voters. Had they been participating all along
perhaps it could have been avoided. We'll never know.
I appreciate that, I'm hearing through the grapevine that
Well actually you're right. .3 was written by Dennis long ago and I
wrote accessors to be exactly as that document described except where
there was ambiguity.
@Steve Clay: this would be a perfect point to start with
Hello Levi,
Agreed, but if they are automatically generated then I see no harm in
allow custom `isset` and `unset` behavior as long as it doesn't get in
the way or complicate things.
If override of isset/unset is possible, we will end up debugging:
true === isset($this->someUninitializedV
Levi, et al.
> class Foo {
> > private $_bar;
> > public function get bar { return $this->_bar; }
> > public function set bar { $this->_bar = $value; }
> > }
> class Foo {
> private $_bar;
> public get bar() { return $this->_bar; }
> public set bar($value) { $this
On Wed, Jan 23, 2013 at 2:07 PM, Clint Priest wrote:
>
> On 1/23/2013 1:00 PM, Marco Pivetta wrote:
>>
>>
>> Actually, having the properties shown even if virtual allows us to access
>> them in a reflection-ish manner without doing dangerous assumptions like
>> "does the setter/getter exist"?
>>
>
Steve:
Like your summary. Disagree with a few points but in general I agree
with you. More below.
> 2. C# has no issetter/unsetter.
>
> IMO customizing these functions is completely unneeded for the vast majority
> of use cases and could be replaced by simpler logic: isset($this->prop)
> calls th
On 1/23/2013 3:07 PM, Crypto Compress wrote:
> I'd just like to point out the fact that RFC v1.1 from a year ago
was exactly as above but people wanted all of these other features.
They were not a property, they had no "guarding", no unset, isset,
etc. The original RFC that was exactly as c# h
> I'd just like to point out the fact that RFC v1.1 from a year ago was
exactly as above but people wanted all of these other features. They
were not a property, they had no "guarding", no unset, isset, etc. The
original RFC that was exactly as c# had it, nobody liked it. It was
changed to its
On 1/23/2013 1:00 PM, Marco Pivetta wrote:
Actually, having the properties shown even if virtual allows us to
access them in a reflection-ish manner without doing dangerous
assumptions like "does the setter/getter exist"?
The fact that the property is virtual is very useful, even though in
On Jan 23, 2013, at 1:23 PM, Steve Clay wrote:
> First of all, I think the functionality provided by Clint and Nikita's RFC
> [1] is in demand and would be an asset to PHP, but I also think it can
> repackaged more simply.
>
> People are comparing the RFC to C# [2], but while they look similar
>Personally, I don't see why 'default' can't be used:
>class Foo {
>public $bar { get; set; default 5; } }
>
>This solves the var_dump() problem, and if people want dynamic get
returning something other than the property/field value, so be it.
>C# does indeed have an internal field per propert
Hi Steve,
2. C# has no issetter/unsetter.
IMO customizing these functions is completely unneeded for the vast
majority of use cases and could be replaced by simpler logic:
isset($this->prop) calls the getter and compares to NULL;
unset($this->prop) passes NULL to the setter.
I tend to agree h
First of all, I think the functionality provided by Clint and Nikita's RFC [1] is in
demand and would be an asset to PHP, but I also think it can repackaged more simply.
People are comparing the RFC to C# [2], but while they look similar, C# has a simpler
implementation we should learn from.
On 23 January 2013 19:53, Sherif Ramadan wrote:
>
> They're not shown because they don't exist. Thus no confusion about whether
> this is a property or not. If it's a property we can see it in
> var_dump($obj). If it's magic you can only see it in
> var_dump($obj->property). With accessors you se
On Wed, Jan 23, 2013 at 12:00 PM, Clint Priest wrote:
>
> Actually you could say that last sentence is precisely opposite of the
> truth in that a var_dump() will *never* expose properties that are
> available via a magic __get() therefore a var_dump() already mis-leads the
> developer because th
On 01/21/2013 11:44 PM, Christopher Jones wrote:
> Pierre,
>
> Can you review this RFC and the votes? The wording "5.5 final
> release" needs assessing. You probably meant "first 5.5 production
> release". If anyone interpreted it as it is actually written
> i.e. "terminal 5.5 release", then t
On 1/23/2013 8:31 AM, Sherif Ramadan wrote:
Except that everything that's proposed here is possible today with __get,
__set, __isset and __unset. So already today you can't assume that a
property is a "variable". In fact, you could build something like this
using __get, etc extremely dirty:
cla
> -Original Message-
> From: Pete Boere [mailto:p...@the-echoplex.net]
> Sent: 22 January 2013 12:30
> To: internals@lists.php.net
> Subject: [PHP-DEV] __init magic method
>
> Has there ever been any discussion on an __init magic method
> for bootstraping static properties on class lo
On Wed, Jan 23, 2013 at 9:03 AM, Anthony Ferrara wrote:
> Sherif,
>
>
> Don't get me wrong, I liked it, but I also disliked the fact that it
>> introduces language changes that aren't easy to grasp or document. To me
>> this means we've borderline changed the behavior of a property (which most
>>
Sherif,
Don't get me wrong, I liked it, but I also disliked the fact that it
> introduces language changes that aren't easy to grasp or document. To me
> this means we've borderline changed the behavior of a property (which most
> PHP users currently understand to be a variable) into potential me
On Tue, Jan 22, 2013 at 6:18 AM, Clint Priest wrote:
>
> On 1/17/2013 12:20 PM, Clint Priest wrote:
>
>> I'm happy to say that Property Accessors is ready for a vote for
>> inclusion in 5.5 release.
>>
>> Nikita and I (as well as Stas a bit) have all been working hard to make
>> this happen for 5
On Tue, Jan 22, 2013 at 6:20 PM, Rasmus Lerdorf wrote:
> On 01/22/2013 03:18 AM, Clint Priest wrote:
> >
> > On 1/17/2013 12:20 PM, Clint Priest wrote:
> >> I'm happy to say that Property Accessors is ready for a vote for
> >> inclusion in 5.5 release.
> >>
> >> Nikita and I (as well as Stas a bi
On Wed, Jan 23, 2013 at 12:11 PM, Benjamin Eberlei wrote:
> On Tue, Jan 22, 2013 at 6:20 PM, Rasmus Lerdorf
> wrote:
>
> > On 01/22/2013 03:18 AM, Clint Priest wrote:
> > >
> > > On 1/17/2013 12:20 PM, Clint Priest wrote:
> > >> I'm happy to say that Property Accessors is ready for a vote for
> >
On Tue, Jan 22, 2013 at 6:20 PM, Rasmus Lerdorf wrote:
> On 01/22/2013 03:18 AM, Clint Priest wrote:
> >
> > On 1/17/2013 12:20 PM, Clint Priest wrote:
> >> I'm happy to say that Property Accessors is ready for a vote for
> >> inclusion in 5.5 release.
> >>
> >> Nikita and I (as well as Stas a bi
On 01/23/2013 01:15 AM, Pierre Joye wrote:
> About opcode cache complexity, I think apc per se is full of things we
> should simplify or drop as features to make the code base much smaller
> and much easier to test and valid, we have discussed that already and
> we disagreed. But this is a topic I
hi Rasmus,
On Tue, Jan 22, 2013 at 6:20 PM, Rasmus Lerdorf wrote:
> The simple explanation from me is that the ROI isn't there on this one.
> It adds a lot of code complexity for very little return. Yes, it saves a
> couple of lines of boilerplate code for a few people, but the cost is
> high in
On Wed, Jan 23, 2013 at 2:28 AM, Anthony Ferrara wrote:
> Rasmus,
>
> Now do 5 or even 10+ years and commits to Zend and APC. We are talking
>> about a core language feature here, so commits to the code most affected
>> is what you should be looking at and when I talk about maintenance I
>> talk a
37 matches
Mail list logo
