[PHP-DEV] Automatic Property Initialization
Since the feedback so far was few but positive, I'll advance the RFC to the next stage. Apart from this, any feedback is still welcome. Thanks and Regards, Gordon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Automatic Property Initialization
Independent but related to - https://wiki.php.net/rfc/constructor-promotion I wrote an RFC about porting Dart-like Automatic Property Initialization to PHP. Nikic was so generous to provide an initial PoC for it (since I don't do C): - https://wiki.php.net/rfc/automatic_property_initialization - https://github.com/php/php-src/pull/474 I am proposing this for inclusion in 5.6. There is no BC breaks afaik. The RFC suggests to allow for $this->foo as Constructor arguments to make the boilerplate code for property assignments in constructors superfluous. This is the core feature subject to discussion. I've spoken to about two dozen developers outside internals prior to suggesting this RFC and the general response was positive and the core feature unanimously deemed useful. Moreover, in the previous discussion about constructor promotion there was some messages suggesting that the now proposed syntactic approach is more preferred than using visibility keywords. The RFC also suggests some related syntactic sugar like Methodless Constructors, an alternate and shorter syntax, as well as making this available in the entire class scope. These are things I am not sure of so I am hoping for comments on these. Should this RFC get into the voting phase, we should by then have either promoted or eliminated these options through discussion. Thanks and Regards, Gordon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
Am 22.01.2013 02:46, schrieb Clint Priest: On 1/20/2013 3:11 PM, Gordon Oheim wrote: Am 17.01.2013 19:20, schrieb Clint Priest: 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.5, voting and the specifications are here: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting Thanks, -Clint Thanks Clint and Niki for your work. Sorry to respond only now that the voting process has already started. I usually don't follow/participate on internals due to the noise and poisoned atmosphere (but that's a different story). Also thanks Niki for taking the time to answer all my questions I had about this beforehand. My main issue with the implementation at hand is the weird way in which we allow the visibility on the properties to be declared, e.g. public $foo { get; protected set; } The visibility keyword on the property is watering down the visibility semantics. Either the property is public (then it can be set) or it is not public. I would have much less of a problem with this, if declaring visibility on a property could only be loosened but not tightened. That would at least be consistent with how visibility works with inheritance. It would be much better though to remove the visibility keyword from the property altogether. It almost never tells the truth. This is basically an argument against asymmetrical visibility altogether which is one of the most useful features of this proposal. I think there are many use cases where an object wants to be able to emit a message (value) but not receive one and being able to declare that fact is important. I understand the purpose and utility of having different levels of visibility. I am not argueing against that. I am argueing that putting the visibility on the property does not give accurate information about the property's visibility itself. Contrived Example: doing just public $foo (Traditional Property) means I can access the property from everywhere directly. But doing public $foo {} (Guarded Property) means I cannot access the property *at all*. So we went through full access to no access just by adding curly braces. Likewise, private $foo { public get; public set; } is not private at all. When the visiblity only applies to declared accessors we should just declare in on the accessors only. That makes for better semantics. After all, it's a guarded property, which already implies that it is hidden behind accessors and thus non-public. Removing the visibility keyword from the property altogether would also remove the purported default visibility that is applied to the accessors. I say "purported" because doing public $foo { get; protected set; } will also change the unset accessor to protected, which makes perfect sense when you think about it but is completely unobvious when the declaration claims the default visibility of all accessors to be public. The default visibility of isset is that of get and the default visibility of unset is that of set instead. To add to the confusion, doing public $foo { get; protected set; public unset; } WILL work and change the visibility of unset back to what the property claims it is. This should not be necessary when visibility on the keyword defines the default visibility. I guess it's safe to say that having the visibility on the property does very little to express anything meaningful about the property or the default visibility of *all* the accessors. Perhaps this is just a documentation problem in that somewhere the implication that public applies to all accessors when it should really say that it applies to all declared accessors. Yes, that should be stretched. I think the final documentation should also strongly emphasize that Guarded Properties is an entirely new concept and not some extension to Traditional Properties or to Magic Methods. We should prevent people from trying to map these new Guarded Properties onto their existing mental models of how Traditional Properties or Magic Methods work. It is perfectly logical that when you cannot set a value, then you cannot unset a value. Defining what you have done above is declaring that you want to allow people to get or unset the value, but not set it directly. This makes sense in some usage scenarios. As an example, perhaps $foo represents an internally generated id which is generated on the first call to the getter, you don't want outsiders to specify the id, but you're okay with having it unset so that a new one can be generated with the internal generation mechanics on the next get request. > As an aside, your previous example can also be declared like this: public $foo { get; protected set; unset; } unset is explicitly declared and implicitly implemented and is public, isset would be implicitly declared and im
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
Am 17.01.2013 19:20, schrieb Clint Priest: 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.5, voting and the specifications are here: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting Thanks, -Clint Thanks Clint and Niki for your work. Sorry to respond only now that the voting process has already started. I usually don't follow/participate on internals due to the noise and poisoned atmosphere (but that's a different story). Also thanks Niki for taking the time to answer all my questions I had about this beforehand. IMO, the new getter/setter syntax adds very little benefit for the loads of syntax it introduces. I understand that people are looking forward to that new feature though, so I won't oppose it just because I have little use for it. My main issue with the implementation at hand is the weird way in which we allow the visibility on the properties to be declared, e.g. public $foo { get; protected set; } The visibility keyword on the property is watering down the visibility semantics. Either the property is public (then it can be set) or it is not public. I would have much less of a problem with this, if declaring visibility on a property could only be loosened but not tightened. That would at least be consistent with how visibility works with inheritance. It would be much better though to remove the visibility keyword from the property altogether. It almost never tells the truth. Removing the visibility keyword from the property altogether would also remove the purported default visibility that is applied to the accessors. I say "purported" because doing public $foo { get; protected set; } will also change the unset accessor to protected, which makes perfect sense when you think about it but is completely unobvious when the declaration claims the default visibility of all accessors to be public. The default visibility of isset is that of get and the default visibility of unset is that of set instead. To add to the confusion, doing public $foo { get; protected set; public unset; } WILL work and change the visibility of unset back to what the property claims it is. This should not be necessary when visibility on the keyword defines the default visibility. I guess it's safe to say that having the visibility on the property does very little to express anything meaningful about the property or the default visibility of *all* the accessors. I briefly discussed possible solutions to this problem with Niki. Simply removing the visibility looks odd $foo { get; protected set; public unset; } but might be the easiest approach. The above would follow the same rules visibility follows for any other methods, e.g. omitting the visibility on the accessor will make it public. Both of us are not keen on introducing new keywords, though I find property $foo { get; protected set; public unset; } quite nice and it is also more obvious that this is not your regular property. Niki suggested var $foo { get; protected set; public unset; } but it's keyword recycling and one could argue that in PHP4 a var was always public. But then again, PHP4 didn't have the concept of visibility at all, so why not? If this could be changed, I'd be more willing to vote pro the proposal. TL;DR: The visibility keyword on the property is almost never giving an accurate information about the accessor visibility. Thus, it should be removed or replaced for clarity's sake. Regards, Gordon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php