> > On Sat, Oct 13, 2012 at 6:47 AM, Clint Priest <cpri...@zerocue.com> wrote:
> > The problem with that Nikita is that it would need a variable storage
> > location, which would mean a hidden, auto-implemented property. You were
> > dead-set against that from the get go.
> What I was mainly against was the particular way how automatic properties
> were implemented (with a real __property as a protected
> backing field, which was directly exposed to the user). But automatic
> properties don't really need that, or at least I don't see why. Just
> "public $foo { get; set; }" doesn't really need anything, it can be
> equivalent to "public $foo" (not that it makes much sense having it in
> that case ^^). "public $foo { get; protected set; }" can also be implemented
> without automagically generated accessor methods. This is
> what Amaury's patch does, just with a different syntax (it provides more
> detailed visibility handling, but does not need accessors).
> Another reason why it might be better to not use generated accessors for
> this, but rather just more detailed visibility flags for
> properties, is performance. Right now "public $foo" would be a "fast"
> property, but "public $foo { get; protected set; }" would turn it into a
> "slow" method based property. Not sure how important that is
> though
> :)
>
> > Keep in mind that property accessors are not properties, real properties
> > will take over the accessor, this could only be done from within the setter
> > of an accessor, but there isn't any way to create an accessor named $Hours
> > which accesses a variable named $Hours.
> "Isn't a way" as in "not possible in the current implementation" or as in
> "not possible due to technical limitations in the engine"? I was
> going to suggest to allow accessing the $foo property from within the $foo
> accessor as to avoid having to create a separate protected
> backing property. But if that's not possible for technical reasons then that
> obviously won't work out :/
>
As it is presently written, if there is a real $foo property and a real $foo
accessor, the $foo accessor is never called. This works exactly like it would
if it were __get(), in the code where __get() would be called, a check is made
for an getter with the name $foo and if it is exists, that is called in lieu of
__get. This aspect is also why lazy loading can work. If you have an accessor
$foo with a getter that "lazy loads" something expensive and then sets $foo
(via its own setter), the next time $foo is accessed it is a regular, standard
public property and the "lazy load" never gets called again (unless the real
property is unset).
> > In any case, your example below could be implemented without automatic
> > creation simply by doing the backing yourself, such as:
> >
> > private $myFoo;
> >
> > public $foo {
> > get() { return $this->myFoo; }
> > protected set($x) { $this->myFoo = $x; } }
> Yes, sure you can implement it manually. Automatic properties are only there
> to make it simpler. I can't exactly judge just how
> important asymmetric visibility will be, so I don't know just how important
> it is to make it short and easy. I can tell that Symfony has 3x
> more getters than setters and ZF has 1.6x more getters. But I'm not sure
> whether this means "many properties with asymmetric
> visibility" or "many properties with just a getter".
>
> > Shall I hold off on this discussion point before proceeding?
> Yes, please. As there isn't really a consensus on this it would be better to
> wait a bit more.
>
> Nikita
So it sounds to me like you aren't looking for "auto implementation" but rather
asymmetric visibility for properties... (aka Amaury's feature).
One of my design goals was to *not* create an additional "memory store" for
each accessor as this is not what other languages do, this is also why the auto
implementation created a separate memory store, so that every other accessor
that didn't need to store data of its own would be free from the memory
overhead of having an unused memory spot.
public $foo { get; protected set; } wouldn't be a problem to be translated to
mean "I don't really want an accessor, I want to define asymmetric visibility
on a property," the difficulty is what to do when something like this is
defined:
public $foo { get; protected set($x) { ... } }
Now we have a difficult situation. There is a real property of $foo so no
getter is called, it is referenced directly and in the case of setting it,
clearly the desired functionality given the definition is that the setter would
be called if $foo is attempted to be set within the right visibility scope.
The difficulty is that to make the above work, accessors and properties must
merge, a getter and setter check must be made on any property access which will
slow things down.
This is why, right now, properties and accessors are separated concepts, so
that there is no additional over-head for real properties.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
