Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63714
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <508C9AAA.7090508@garfieldtech.com>
References: <508A67E6.2000405@zerocue.com>
	<508C9AAA.7090508@garfieldtech.com>
Date: Tue, 30 Oct 2012 09:05:48 +0100
Message-ID: <CAH-PCH53r_d-Qf_c=WuyGBagsN49zYXEY64QCuidq9yNmhe8bQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d042de65700bdb704cd424164
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor
 Method Visibility / Callability
From: tyra3l@gmail.com (Ferenc Kovacs)

--f46d042de65700bdb704cd424164
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I would say that the proposed accessors is what we should have added back
then instead of __get/__set . The problem is that now we will have two
similar (albeit one is an ugly subset of the other) feature which needs to
co-exists.
My gut tells me that we should ditch the magic method approach with the
introduction of accessors and provide easy/automated migration.
Ofc. that would mean that we need at least one major version.
My two cents from the sidelines.
2012.10.28. 3:39, "Larry Garfield" <larry@garfieldtech.com> ezt =C3=ADrta:

> On 10/26/2012 05:37 AM, Clint Priest wrote:
>
>> I'm opening up several new threads to get discussion going on the
>> remaining "being debated" categories referenced in this 1.1 -> 1.2 chang=
e
>> spec:
>> https://wiki.php.net/rfc/**propertygetsetsyntax-as-**
>> implemented/change-requests<https://wiki.php.net/rfc/propertygetsetsynta=
x-as-implemented/change-requests>
>>
>> ------------------------------**------------------------------**
>> ------------
>> Some people are in favor of the internal functions being generated by an
>> accessor declaration should be invisible and non-callable directly. Othe=
rs
>> are in favor of leaving them visible and callable.
>>
>> *Type 1 ( Userland Programmer )**
>> *
>> As a userland programmer, someone who cares nothing for "how" php works,
>> only how their own code works. If they define an accessor they expect to
>> see an accessor, reflection should reflect that there are accessors and =
no
>> other "methods" they did not explicitly define. If they were to reflect =
on
>> all of the methods of their class and see a number of __getHours() they =
may
>> be confused as to why or where this function came from. From their
>> perspective, they have defined an accessor and "how" that accessor works=
 on
>> the inside is of no importance to them and only seeks to complicate or
>> confuse matters when they are exposed to these "implementation details" =
of
>> the php language its-self. If you tried to set a value such as $obj?abc =
=3D 1
>> through an accessor which could not be set, you would probably want to s=
ee
>> an error like: Warning, cannot set Class?abc, no setter defined.
>>
>> *Type 2 ( Internals Programmer )**
>> *
>> As an internals programmer, you want nothing hidden from you. If an
>> accessor implements special __getHours() methods to work its magic, then
>> you want to see them, you want to call them directly if you so choose. I=
n
>> effect you want nothing hidden from you. In this case you probably don't
>> even want Reflection to reflect accessors as anything different than
>> specially formatted and called methods on the class. This can be
>> understandable because you want all information available to you. You wo=
uld
>> probably not be confused if you wrote $obj?abc =3D 1 and got back an err=
or
>> like "Fatal Error: Class->__setAbc() function does not exist.
>>
>> *Unfortunately 80 to 95% of all people who use PHP are of the first
>> type.**
>> *
>> Revealing these internal matters to them would only leave them confused,
>> possibly frustrated and likely asking about it to the internals mailing
>> list to answer (repeatedly).
>> ------------------------------**------------------------------**
>> ------------
>>
>> Thoughts?
>>
>>
> Speaking as a user-land programmer that's been following this thread, but
> hasn't been able to jump in yet due to the high volume of comments...
>
> What's unclear to me is what my mental model should be for this new
> syntax.  That's important for informing how it should be exposed to me.
>
> 1) Should I have a mental model of this being some syntax candy on top of
> existing properties?  Vis, this is just a short-hand for bean-style
> classes?  By Bean style, I mean Properties that would be public but aren'=
t
> because Public Is Bad(tm), so instead we have getX()/setX() for every
> property, so that we can still use the object like a struct rather than a=
n
> object but still say we're using methods even though we've just
> reimplemented public properties with more verbose syntax.  (Note: Yes, I
> know that's a rather harsh and judgmental description.  I happen to firml=
y
> dislike Bean-style objects.)
>
> 2) Should I have a mental model that these fancy-pants properties are som=
e
> different third thingie on objects, distinct from traditional data member=
s
> and methods?
>
> Right now I'm not sure which mental model I'm supposed to use, and I get
> the sense that there's no clear consensus on that question yet. That, I
> think, is the key question, and will inform how things like Reflection
> should expose data about this new syntax.
>
> For instance, if model 2 is how I'm supposed to be thinking, then I'd
> expect I'd need a third reflection object for getting things off of an
> object/class, separate from traditional data members and methods.  Then
> it's consistently a third thingie.  If, however, I'm supposed to think of
> it as just a short-hand syntax for writing a bean, then I'd expect it to =
be
> presented to me as if I'd hand-written all of the stuff that this syntax =
is
> emulating.  Vis, methods show up as methods, and anything I'd be able to
> read/write directly without going through an intermediary method should
> show up as a property just as it does now.
>
> Note: I'm speaking here of the mental model of the user, which does not
> necessarily have any relationship to the implementation details.  If I'm
> "supposed" to think of it as a third thingie, it doesn't matter that it m=
ay
> be implemented internally as syntactic sugar.  It should be presented to =
me
> as a third thingie, consistently, with the engine internal implementation
> details completely irrelevant.  (Which means they can be changed later if
> needs be.)
>
> I don't know which mental model is intended, nor which one would be
> better, but that is, I believe, the question that should inform the rest =
of
> these discussions.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f46d042de65700bdb704cd424164--