Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63322
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 74.115.204.53 as permitted sender)
To: Leigh <leight@gmail.com>
CC: "Nikita Popov (nikita.ppv@googlemail.com)" <nikita.ppv@googlemail.com>,
	"internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Propety Accessors v1.1
Thread-Index: Ac2lRqaw0wLAVcGGQAyyWuaNO91x4QBHSfMAABNVRgAAB5uHkAAG5DSAAAH+idA=
Date: Wed, 10 Oct 2012 12:39:39 +0000
Message-ID: <9570D903A3BECE4092E924C2985CE485612B4B50@MBX202.domain.local>
References: <9570D903A3BECE4092E924C2985CE485612B3B48@MBX202.domain.local>
	<CAPwsocHLimh+b=tdnEUethFX84esA8w0STup-hf-a963tXinMA@mail.gmail.com>
	<CACxA8bn=s6S7jc9rCAUd-40fgscxkJKKCRt77CWpCsSbgRzdrQ@mail.gmail.com>
	<9570D903A3BECE4092E924C2985CE485612B496D@MBX202.domain.local>
 <CAPwsocERvhpxGeQqGSgUY+TAnZD7mg+V1s9gceRnYaLEihjDww@mail.gmail.com>
In-Reply-To: <CAPwsocERvhpxGeQqGSgUY+TAnZD7mg+V1s9gceRnYaLEihjDww@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
From: cpriest@zerocue.com (Clint Priest)

> >> 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.
>=20
> > 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; } )
>=20
> For me the problem is simply that you can call the accessor functions dir=
ectly. I don't like it.
>=20
> 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)
>=20
> A property should be a property, not a collection of hidden methods and v=
ariables. If it needs to be seen whether a property
> implements accessors, this should be done through reflection.
>=20

Leigh, a property IS a property, a property accessor IS a series of functio=
ns.

>=20
> >> ## 3 - Can directly access $__automaticProperty and even unset it
> >> (causing notices in the internal code)
>=20
> > I'm not even sure that automatic backing fields are even desired
>=20
> See above I guess, I agree that these "hidden" properties should not exis=
t 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 cas=
e in which a "real property" is automatically implemented.

>=20
> >> 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.
>=20
> > 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 functionalit=
y.
>=20
> 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 pro=
posal please :)
>=20
> >> public $property {
> >> set { $this->property =3D ($this->property*2)+$value } get; }
>=20
> >> 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"?
>=20
> > 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->__pro=
perty.
>=20
> Kind of confusing. We have to think of the users who just want to pick th=
is 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.
>=20

I agree completely, what are you trying to achieve because the above code m=
akes it look like you are thinking of accessors as properties, which they a=
re not.  Accessors do not have their own "memory space."

>=20
> > The above will not cause recursion, it is protected from recursion by
> > the same mechanism that __get() and __set() are protected.
>=20
> Good, thanks. I didn't get to test it since I was on a bus at the time :)
>=20
> > 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.
>=20
> 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.

>=20
> > 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 ac=
cessor).
> > To get out of that situation, you would simply unset($objList) and the
> > accessor would take over again.
>=20
> Also confusing. (Think of the users!)

This does not need to be used, it's simply a way it can be used.  Again, th=
e 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.

>=20
> >> 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.
>=20
> > 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.
>=20
> She? Only when I go shoe shopping with Nikita at the weekends...

Sorry :)

>=20
> Actually the recursion thing was just a query I hadn't tested, and you ha=
ve answered. The other question I asked was "How do you set
> the default value of the property with the accessor syntax?"
>=20
> > 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.
>=20
> > 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.
>=20
> In my opinion
>=20
> public $property; // This is a property
>=20
> public $property { // This is still a property
>     set { ... }
> }
>=20

This would be where you are wrong, the 2nd $property above is not a propert=
y at all, it's a property accessor, it has no "memory space" the way a regu=
lar 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 convers=
ions, they will also be using them for validation and sanitising.
> You already saw Niki throwing an Exception inside an accessor.
>=20
> try {
>     $user->username =3D $rawData
> } catch (InvalidUsernameException $e) {
>     ...
> }
>=20
> They will expect the $username property to contain the data, not $__usern=
ame, 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 c=
onfuse everyone.