On 10 October 2012 04:51, Clint Priest <cpri...@zerocue.com> wrote:
> Wow, I'm surprised by all the talk about this RFC this time around. I
> posted this numerous times in the past trying to elicit feedback and got
> little to none, so I took the time to write it as I thought it should be
> written. Some of these things will take considerable effort to
> fix/correct/change.
Sometimes things get overlooked. Lots of suggestions make their way to
the list, usually by people who have no way to implement the feature
and they disappear as quickly as they are suggested. Be happy you ARE
getting feedback now. The fact people now see this as something that
may be implemented as it is (in a way they don't necessarily like) is
prompting them to speak up about their concerns.
>> What concerns me with the current implementation is that it leaks many
>> implementation details, in particular the fact that the accessors are
>> implemented as *real* __getXYZ methods and automatic implementations also
>> use *real* $__XYZ properties.
> I don't particularly see this as a problem (the ability to use it as a
> getter or call it as a function), but see my comments at the end. I also
> don’t particularly see the point of auto implemented getters/setters (
> public $h { get; set; } )
For me the problem is simply that you can call the accessor functions
directly. I don't like it.
I don't like the fact that accessors and their associated properties
are implemented as direct (yet slightly obfuscated/hidden) elements of
the containing class. It's unintuitive (I'd even go as far as saying
confusing)
A property should be a property, not a collection of hidden methods
and variables. If it needs to be seen whether a property implements
accessors, this should be done through reflection.
>> ## 3 - Can directly access $__automaticProperty and even unset it (causing
>> notices in the internal code)
> I'm not even sure that automatic backing fields are even desired
See above I guess, I agree that these "hidden" properties should not
exist in the first place.
>> I think it would
>> be better to cleanly separate out the accessor implementation. It might
>> require more code now, but will be better in the long run.
> All three of these issues, could be addressed I believe by not having the
> functions and/or properties a part of the ordinary HashTables, or to have
> flags set on them. I believe there is already a SHADOW flag type defined
> which may be able to be used for this type of functionality.
Nikita do you have any other proposals for how this should be
addressed? I think most of my concerns with this revolve around the
implementation not being cleanly separated as you put it. I believe
that setters/getters would be a tremendously powerful and useful
addition to the language, just not quite like this, so lets here your
proposal please :)
>> public $property {
>> set { $this->property = ($this->property*2)+$value } get; }
>> How do I reference the property being set from within the function? The
>> way I have done it in the example will cause recursion? How can I assign to
>> "self"?
> Generally speaking, I don't know why you would use an automatic backing
> getter with a separate setter, but if you wanted to do that, at present you
> would access the automatic backing field by $this->__property.
Kind of confusing. We have to think of the users who just want to pick
this up and run with it. You can't say "I don't know why you would",
because people will do strange things, and you have to make it so that
the behaviour is predictable, and intuitive.
> The above will not cause recursion, it is protected from recursion by the
> same mechanism that __get() and __set() are protected.
Good, thanks. I didn't get to test it since I was on a bus at the time :)
> In fact, the above
> code would set an actual property named $property on the object which would
> then side-step the accessor entirely (true properties take precedence over
> accessors, though they may only be "set" from within the setter of the
> accessor. This may be a bit confusing, but I specifically wrote it this way
> for the purpose of lazy-loading.
Yep, confusing!
> The first access of the $objList property getter would create the object and
> attempt to set its-self which would be passed to the setter, the setter (now
> guarded) will directly set the property on the object, further calls to
> $objList would retrieve the already created object (bypassing the accessor).
> To get out of that situation, you would simply unset($objList) and the
> accessor would take over again.
Also confusing. (Think of the users!)
>> I think Leigh brings up some important flaws to in the current RFC. What
>> Leigh is asking for does not appear to be possible, and in my opinion, it
>> should be.
> I'm really not quite clear on what Leigh was going for with the code she
> indicated, I think she was trying to demonstrate infinite recursion which is
> not possible due to guards.
She? Only when I go shoe shopping with Nikita at the weekends...
Actually the recursion thing was just a query I hadn't tested, and you
have answered. The other question I asked was "How do you set the
default value of the property with the accessor syntax?"
> I think there is some wide-spread confusion over what an accessor is. An
> accessor does not store its own value, there is no “memory space” allocated
> for an accessor unless you use the automatic implementation ( public $h {
> get; set; } ) but if you’re going to do that, you may as well just reduce it
> to ( private $__h ) which is all the previous “accessor” would have done for
> you.
> Accessors, in my own use, are nearly always used for convenience aliases
> with conversions ( $Hours calculated based on a real stored $Seconds value)
> or as an alias to access a value from another class, they are generally not
> used to simply store or retrieve values, that’s what a property is for, an
> accessor is for executing code with the syntactic sugar of making it seem
> like it’s a variable.
In my opinion
public $property; // This is a property
public $property { // This is still a property
set { ... }
}
I don't see accessors tied to the property as ways of simply setting
some other value (in your example, setting $seconds via $hours). I
have a feeling a lot of people will not be using these simply for
conversions, they will also be using them for validation and
sanitising. You already saw Niki throwing an Exception inside an
accessor.
try {
$user->username = $rawData
} catch (InvalidUsernameException $e) {
...
}
They will expect the $username property to contain the data, not
$__username, and not having to implement $saneUsername as a second
property to store it in.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
