> >> 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.
>
Leigh, a property IS a property, a property accessor IS a series of functions.
>
> >> ## 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.
If this automatic implementation { get; set; } is not desired, I'd be happy to
rip it out, I never wanted it in the first place. This is the only case in
which a "real property" is automatically implemented.
>
> >> 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.
>
I agree completely, what are you trying to achieve because the above code makes
it look like you are thinking of accessors as properties, which they are not.
Accessors do not have their own "memory space."
>
> > 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!
Well it's confusing because you wrote it that way... thinking that somehow
$property has its own "memory space" which it does not.
>
> > 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!)
This does not need to be used, it's simply a way it can be used. Again, the
confusion I think you are running into is that you think that a property
accessor has it's own "memory space," which it does not have.
>
> >> 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...
Sorry :)
>
> 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 { ... }
> }
>
This would be where you are wrong, the 2nd $property above is not a property at
all, it's a property accessor, it has no "memory space" the way a regular
property does.
> 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.
$__username only occurs if no body is provided for a getter or setter.
It really seems like getting rid of auto-implemented properties is the only way
to get through this. I don't want them anyways and it only seems to confuse
everyone.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
