[PHP-DEV [RFC] Property Accessors v1.2 View as Markdown

Yeah, if you check out the section in the RFC on static properties I give examples of both of these cases, I have not tested the use of static::$zz though come to think of it, I will put it on my todo list.

From: Jazzer Dane [mailto:tbprogrammer@gmail.com]
Sent: Friday, October 12, 2012 12:32 AM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

I like it.
I assume that, in regards to static properties, the static keyword works just as well as self and parent, correct?

Alright, here is the updated RFC as per discussions for the last few days:

https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

If you could read it over, make sure I have all of your concerns correctly addressed and we can leave this open for the two week waiting period while I make the final code changes.

-Clint

Hey Bernhard,

I see a few problems with the proposal:

1. If you're adding all of the ArrayAccess functions, what about all of the Iterator functions? How about other SPL aspects, like Countable, etc.

2. The use case can still be handled with an actual object which implements ArrayAccess and in a better practice scenario, unless I misunderstood what your code sample was implying. (if so, could you provide a complete, concrete example where it would be more advantageous to have these four additional accessor functions?)

3. Zero other languages that I am aware of implement anything more than get/set for accessors, the need for isset/unset is obvious for php because they are so heavily used. In fact, this document referenced in Dennis's original RFC shows 11 other languages with accessors, none of which have more than get/set.
   http://en.wikipedia.org/wiki/Property_%28programming%29

Lastly, it would probably delay this project another 6 months, perhaps it could be shelved for a version 2 of the accessors aspect?

-Clint

-----Original Message-----
From: Bernhard Schussek [mailto:bschussek@gmail.com]
Sent: Friday, October 12, 2012 3:07 AM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

Hi Clint,

I would like to urge you again to consider implementing the array access methods. Without that, this very neat feature becomes
essentially unusable for modelling one-to-many, many-to-one and many-to-many object relations, as I tried to explain in the previous
topic.

Objects and relations between them are the most primitive building block of OO design, so I regard this as highly important.

Thanks,
Bernhard

hi Lester,

Clint Priest wrote:

Alright, here is the updated RFC as per discussions for the last few days:

https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

If you could read it over, make sure I have all of your concerns correctly
addressed and we can leave this open for the two week waiting period while I
make the final code changes.

Now I remember why I did not like this wholesale ...

There is no easy way to identify that
$time->Hours = 12; is doing something other than a bog standard 'store 12 in
$Hours' while a simple $time->Hours(12); immediately makes it obvious that
there IS some processing involved. And period = $time->Hours(); flags that
the result is calculated from some other value in the class.

So IS this new layer of magic mirrors really necessary at all? Is it adding
to the complexity at the expense of the inherent readability of the code
later on?

I suppose the argument is that 'people expect it' but that is only because
they are not yet used to the better way of working that IS PHP ... just
because some people expect cryptic code should that be any reason to weigh
PHP down further with it?

Please keep the discussion sane without repeating the same arguments
over and over again. This RFC is about adding a new cleaner
getter/setter than the __get/__set we have now, which forces us to do
some more useless work for basic needs. The complexity you are talking
about already exist and you already mentioned this argument already,
we got it.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Good hint, Nikita.
I like the feature of automatic properies. For the problems with unauthorized access: What about signing automated generated "variables", so that they are only accessable through the property?

@Lester Caine: This properties do not break backward compatibility. If you do not want to use it, you do not need.
I like them because they offer an easy, short and well readable way to protected object or class variables.

Best regards
Christian Stoller

-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Friday, October 12, 2012 12:48 PM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

Alright, here is the updated RFC as per discussions for the last few days:

https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

If you could read it over, make sure I have all of your concerns correctly addressed and we can leave this open for the two week waiting period while I make the final code changes.

-Clint

I've been thinking a bit about the automatic properties again, and
noticed that I forgot to name one use case: Asymmetric accessor
visibility. Automatic properties may be useful in that context, so
that you can write "public $foo { get; protected set; }" (though they
don't necessarily need to be implemented as properties with auto
generated code, rather just properties with more detailed visibility
handling [a bit related to the stuff Amaury has been saying]).

Nikita

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. 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.

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; }
}

Again, without another "variable store" automatic properties goes out the door, can't really have one without the other.

Shall I hold off on this discussion point before proceeding?

-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Friday, October 12, 2012 5:48 AM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

Alright, here is the updated RFC as per discussions for the last few days:

https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

If you could read it over, make sure I have all of your concerns correctly addressed and we can leave this open for the two week
waiting period while I make the final code changes.

-Clint

I've been thinking a bit about the automatic properties again, and noticed that I forgot to name one use case: Asymmetric accessor
visibility. Automatic properties may be useful in that context, so that you can write "public $foo { get; protected set; }" (though they
don't necessarily need to be implemented as properties with auto generated code, rather just properties with more detailed visibility
handling [a bit related to the stuff Amaury has been saying]).

Nikita

I must have missed taking that part out of the RFC, they would not be needed any more with those keywords being removed.

-----Original Message-----
From: Levi Morrison [mailto:morrison.levi@gmail.com]
Sent: Friday, October 12, 2012 9:45 AM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

Alright, here is the updated RFC as per discussions for the last few days:

https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

If you could read it over, make sure I have all of your concerns correctly addressed and we can leave this open for the two week
waiting period while I make the final code changes.

-Clint

I'm not sure if that RFC is up to date; are ZEND_ACC_READONLY and ZEND_ACC_WRITEONLY still there? Are there still 79 test cases?
I'd like to see wider coverage if you can think of more things to tests.
Ideally every conditional statement has a test.

I used to be very against this RFC but I admit the details have improved a lot with the ability to type hint and the removal of read and
write only keywords.

Levi Morrison

Can we discuss the removal of automatic get; set; again? For me that was
the best feature of the whole RFC, essentially allowing to define a
property with getter/setter in 1 LOC. Allowing future overriding of that
getter/Setter if the application required it.

This is absolutely essential for database backed recods which will have
tons of those property accessors. Now if i apply PSR coding styles to
accessors, then i end up with 11 LOC for accessors defining a property, a
property accessor and get/set functions, compared to 10 LOC with usual
getter/setters.

Not sure I quite understand you. What prevents you from just using a
normal public property?

public $property;

Accessors give you the ability to add alternative behavior for the
property lateron (this is actually the main use I personally see in
this RFC: Not actually using it, but having the possibility of using
it).

The only place (which I see off the top of my head) where property /
automatic property makes a difference is interfaces. In the current
implementation interfaces can only define properties with accessors.
So:

interface Foo {
    // this is okay
    public $abc { get; set; }

    // this is invalid
    public $abc;
}

And similarly you can't implement the public $abc { get; set; }
definition from the interface using a plain property.

I think that properties should be definable in interfaces, or at a
normal property "public $abc;" should satisfy the interface "public
$abc { get; set; }" (I mean, it kinda does from a functional point of
view, right?)

Nikita

Alright, here is the updated RFC as per discussions for the last few days:

https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

If you could read it over, make sure I have all of your concerns correctly addressed and we can leave this open for the two week waiting period while I make the final code changes.

-Clint

So here comes my round of feedback on the current proposal.

But before getting to that: I have collected a bit of data how getter
and setter are currently used in Symfony and ZF:
https://gist.github.com/3884203 Mainly so I get a better overview of
the situation, but might be of interest for other people involved in
this discussion too.

So, my points on the proposal, in no particular order:

1. Typehints

---

The last revision of the proposal added the ability to typehint the
set() accessor, so that's a good start. Still I would like to go a bit
further on this point. My data says that about 20-30% of all setters
are typehinted and it is highly probable that if we had scalar
typehints (as I'm sure we will have in the future) that number would
be even larger. In particular I would like to have an easy way to
typehint if I don't want to override any additional behavior.
Currently that would require me to write something along the lines of
this:

protected $_date;
public $date {
    get() { return $this->_date; }
    set(DateTime $date) { $this->_date = $date; }
}

This is a rather lot of boilerplate code just to add a typehint. With
automatic properties this might be reduced to this:

public $date {
    get();
    set(DateTime $date);
}

This is already a lot nicer, because I don't have to implement the
same getting and setting pattern again and again, but I still find
that it doesn't do a particularly good job at conveying its intention.
Rather, what that code really wants to say is just this:

public DateTime $date;

I think that it would be very beneficial to support this syntax,
because I think that a large part of the use of the accessor proposal
will just be type checking. But if we indeed want to syntax we should
reconsider the get {} set { $value; } syntax again, because as I
understand it the new get() {} set($value) {} syntax was mainly
introduced to deal with setter typehints. If we chose to allow
typehints before the property name, then that wouldn't be necessary
anymore.

2. Interfaces

---

I already mentioned this before, but I'll reiterate it here again:
Currently properties and properties with accessors are handled
different with regards to interfaces. In particular, if you have an
interface such as follows:

interface Extension {
    public $name { get; }
    // more stuff
}

then the following is not a valid implementation of the interface:

class FooExtension implements Extension {
    public $name = 'foo';
    // more stuff
}

This does not make sense to me: $foo->name is a gettable property, as
such it satisfies the interface. I don't see a reason why we would
need a hard distinction between properties and properties with
accessors here.

I have to agree here.

Interfaces are means to describe the capabilities of an object from
the outside. And from the outside, properties defined through
accessors are used like properties, not methods.

It would IMHO be better not to support accessors in interfaces until
properties are also (if ever) supported.

Best,

The converse is also true: An interface currently can not define a
"plain" property:

interface Foo {
    public $foo;
}

I would expect this interface definition to be the same as "public
$foo { get; set; }". But I'm not sure on this point, as one could
argue that it's just a redundant way to say the same thing.

3. Protected backing property

---

The RFC currently contains just a single code example, namely setting
a $Seconds property through an $Hours property, which is an example
where you want to override both accessors and there is a backing
property that already exists "naturally".

If you on the other hand you consider cases where you only want to
override either the set or the get behavior and there doesn't already
exist a backing property, you will end up with a code like this:

protected $_isEnabled;
public $isEnabled {
    get() { return $this->_isEnabled; }
    set($isEnabled) { $this->_isEnabled = (bool) $isEnabled; }
}

The above code really only adds a bool cast, but still it has to do
two things: Add a protected backing property and define a getter which
basically matches the default behavior. With automatic properties as
they are currently implemented you could write:

public $isEnabled {
    get();
    set($isEnabled) { $this->__isEnabled = (bool) $isEnabled; }
}

This is closer to what I actually want to do, but it relies on using
$this->__isEnabled, which is really just an implementation detail.

Instead, I would rather want to have access to the "underlying" property:

public $isEnabled {
    get();
    set($isEnabled) { $this->isEnabled = (bool) $isEnabled; }
}

I know that the wording is a bit vague; another way to put it, is that
the above inverts the current shadowing behavior:

In the current implementation, if there exists a "plain" property and
an "accessor" property with the same name, then the plain property
shadows the accessor property. As you say, this is to help
lazy-loading. I don't really buy the argument about lazy-loading,
because I don't think that the small perf difference between going
trough an accessor and accessing a plain property is really relevant
in that context (especially as lazy-loading would have required a
method otherwise).

What I'd rather see is the reverse behavior: An accessor property
shadows a plain property, so that the plain property is only
accessible from within the accessor methods. This would allow you to
write code like in the last example above and I think it would also
make automatic properties more meaningful (you could store the state
in a property with the same name; also nicely integrating with
serialization and debugging).

I know that you (Clint) want to create a hard distinction between
plain properties and accessor properties, but I think that making it
more smooth juts integrated better with PHP. I already noticed several
people who, after reading the RFC, tried to write code where they
access the property from within the accessor. It seems to me that
people think it should work. The current behavior where you can shadow
the accessor property by assigning a property of the same name seems
rather obscure to me.

This is the feedback I have for now. Looking forward to your thoughts
on the manner.
Nikita

--

--
Etienne Kneuss
http://www.colder.ch

One of the reasons the current syntax, as seen below, was chosen, is for
typehints - yes.

public $property {
get() { ... }
set{TypeHint $value) { ... }
}

The other reason it was chosen was to specifically get rid of the magic
$value that appeared out of thin air. If typehints become possible without
having to specify it in the set accessor, I'd still argue that the syntax
needs to stay as, in my opinion, it is the most cohesive and sensible
syntax that was proposed - even compared to:

public $property {
get { ... }
set { ... }
}

In terms of interfaces, Clint's reason for allowing accessors in interfaces
is moderately sensible: to remain cohesive with the already allowed __get
and __set magic methods that are usable in interfaces.* That's the
underlying issue.* If we want to require an object to be able to be
converted to a string, we can sensibly put __toString in the interface. But
what does forcefully implementing __get or __set do for the object? What
does it tell us about how we're able to use it? It relates to properties in
arguably such a manner that we(i.e. accessing the object's API) nor the
interface should care about. But that's an argument for another day.

So what do we do right now, then? If we allow it in interfaces, my main
worry is that people will put the accessor in an interface just because
they can't put a property, and they'd use the accessor as a normal, basic
property.

And finally, in terms of protected backing properties: It seems nice, but,
and I'm sure Clint will clarify on this, I'm not so sure that's really what
accessors are supposed to be used for. If people want a typehinted
property, then we should allow them to create a typehinted property rather
than forcing them to use accessors.

Alright, here is the updated RFC as per discussions for the last few
days:

https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

If you could read it over, make sure I have all of your concerns
correctly addressed and we can leave this open for the two week waiting
period while I make the final code changes.

-Clint

So here comes my round of feedback on the current proposal.

But before getting to that: I have collected a bit of data how getter
and setter are currently used in Symfony and ZF:
https://gist.github.com/3884203 Mainly so I get a better overview of
the situation, but might be of interest for other people involved in
this discussion too.

So, my points on the proposal, in no particular order:

1. Typehints

---

The last revision of the proposal added the ability to typehint the
set() accessor, so that's a good start. Still I would like to go a bit
further on this point. My data says that about 20-30% of all setters
are typehinted and it is highly probable that if we had scalar
typehints (as I'm sure we will have in the future) that number would
be even larger. In particular I would like to have an easy way to
typehint if I don't want to override any additional behavior.
Currently that would require me to write something along the lines of
this:

protected $_date;
public $date {
    get() { return $this->_date; }
    set(DateTime $date) { $this->_date = $date; }
}

This is a rather lot of boilerplate code just to add a typehint. With
automatic properties this might be reduced to this:

public $date {
    get();
    set(DateTime $date);
}

This is already a lot nicer, because I don't have to implement the
same getting and setting pattern again and again, but I still find
that it doesn't do a particularly good job at conveying its intention.
Rather, what that code really wants to say is just this:

public DateTime $date;

I think that it would be very beneficial to support this syntax,
because I think that a large part of the use of the accessor proposal
will just be type checking. But if we indeed want to syntax we should
reconsider the get {} set { $value; } syntax again, because as I
understand it the new get() {} set($value) {} syntax was mainly
introduced to deal with setter typehints. If we chose to allow
typehints before the property name, then that wouldn't be necessary
anymore.

2. Interfaces

---

I already mentioned this before, but I'll reiterate it here again:
Currently properties and properties with accessors are handled
different with regards to interfaces. In particular, if you have an
interface such as follows:

interface Extension {
    public $name { get; }
    // more stuff
}

then the following is not a valid implementation of the interface:

class FooExtension implements Extension {
    public $name = 'foo';
    // more stuff
}

This does not make sense to me: $foo->name is a gettable property, as
such it satisfies the interface. I don't see a reason why we would
need a hard distinction between properties and properties with
accessors here.

The converse is also true: An interface currently can not define a
"plain" property:

interface Foo {
    public $foo;
}

I would expect this interface definition to be the same as "public
$foo { get; set; }". But I'm not sure on this point, as one could
argue that it's just a redundant way to say the same thing.

3. Protected backing property

---

The RFC currently contains just a single code example, namely setting
a $Seconds property through an $Hours property, which is an example
where you want to override both accessors and there is a backing
property that already exists "naturally".

If you on the other hand you consider cases where you only want to
override either the set or the get behavior and there doesn't already
exist a backing property, you will end up with a code like this:

protected $_isEnabled;
public $isEnabled {
    get() { return $this->_isEnabled; }
    set($isEnabled) { $this->_isEnabled = (bool) $isEnabled; }
}

The above code really only adds a bool cast, but still it has to do
two things: Add a protected backing property and define a getter which
basically matches the default behavior. With automatic properties as
they are currently implemented you could write:

public $isEnabled {
    get();
    set($isEnabled) { $this->__isEnabled = (bool) $isEnabled; }
}

This is closer to what I actually want to do, but it relies on using
$this->__isEnabled, which is really just an implementation detail.

Instead, I would rather want to have access to the "underlying" property:

public $isEnabled {
    get();
    set($isEnabled) { $this->isEnabled = (bool) $isEnabled; }
}

I know that the wording is a bit vague; another way to put it, is that
the above inverts the current shadowing behavior:

In the current implementation, if there exists a "plain" property and
an "accessor" property with the same name, then the plain property
shadows the accessor property. As you say, this is to help
lazy-loading. I don't really buy the argument about lazy-loading,
because I don't think that the small perf difference between going
trough an accessor and accessing a plain property is really relevant
in that context (especially as lazy-loading would have required a
method otherwise).

What I'd rather see is the reverse behavior: An accessor property
shadows a plain property, so that the plain property is only
accessible from within the accessor methods. This would allow you to
write code like in the last example above and I think it would also
make automatic properties more meaningful (you could store the state
in a property with the same name; also nicely integrating with
serialization and debugging).

I know that you (Clint) want to create a hard distinction between
plain properties and accessor properties, but I think that making it
more smooth juts integrated better with PHP. I already noticed several
people who, after reading the RFC, tried to write code where they
access the property from within the accessor. It seems to me that
people think it should work. The current behavior where you can shadow
the accessor property by assigning a property of the same name seems
rather obscure to me.

This is the feedback I have for now. Looking forward to your thoughts
on the manner.
Nikita

#2: I agree with you here - this is problematic. isset/unset accessors that
invoke the isset/unset function should actually invoke the function rather
than being compared to null, as that isn't the same as isset.

#5: From what I understand, an extending class can not override an accessor
with a non-accessor.

#11: If you set an accessor's get or set to final private, you are not
able to extend and it are only able to invoke it from the current class. If
you don't invoke it, then it is virtually read or write only.

On Tue, Oct 16, 2012 at 2:12 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

My feedback on the RFC:

1. Accessors IMO should be regular PHP methods that PHP generates with
   two additional things:
   a. Their name is generated by PHP
   b. Their argument set is defined by the accessor pattern (i.e. same
   thing as __get/__set).
   We should keep the amount of magic and special cases to the minimum, the
   engine is complex enough as it is.
   This of course includes the full range of options available for the
   methods - final, reflection, call scenarios, etc.

2. isset is defined as:
   isset() { return $this->Hours != NULL; }
   This does not seem to be correct - != NULL does not work like isset now.
   Try this:
   class A { public $x = 0; }
   $a = new A;
   var_dump(isset($a->x));
   var_dump($a->x != NULL);
   This needs to be fixed - generated isset() should be defined to work
   exactly like regular isset and actually use the same code path. Argument
   to isset() call can be retrieved using accessor but it should not differ
   from isset() result in any possible way or situation (including error
   situations - e.g. notices, etc.)

3. How references and complex cases are handled? Didn't find anything
   about it, e.g. how it handles $foo->bar++, $foo->bar[] = 1,
   $foo->bar[123] = 4, etc. ($foo->bar being property with get/set defined
   of course)? How $foobar =& $foo->bar is handled? The sort() case
   mentions by-ref return but does not explicitly mention all other cases.
   These need to be covered explicitly in the RFC.

4. We have some LSP controls now in place to ensure non-LSP overrides
   generate E_STRICT. Will this be the case for properties too? Meaning,
   what happens if you add overriding protected getter to a property that
   was previously fully public - thus violating the LSP?

5. What happens if you override accessor property with plain old
   variable property? I.e.:

class A {
protected $secret {
get() { return "secret"; }
}
}

class B extends A {
public $secret = "not a secret anymore";
}

Also, what happens here if A extends B in the same scenario (this refers
to the #4 too).

6. Thinking more about isset/unset - why not make isset/unset always be
   the default unless overridden? I can't really see the case where you
   want echo $foo->bar to work but if(isset($foo->bar)) echo $foo->bar to
   not work. I think isset() and unset() should always use automatic
   implementations by default (fixed in accord with #2 of course).

7. "Error messaging" section is not clear. Some examples would help -
   what is being translated to what?

8. "Static accessors" section is not clear, namely this one:
   This yielded the possibility that a getter call was being made while it
   should not be allowed (if there was no getter defined) and so pass_two()
   was changed to look for these non-backpatched illegal static getter
   calls and a compile time error is produced.

When the code is compiled, the class definition (and, in fact, the name
of the class we're talking about) may not be available, so how can you
known if certain property of this class has getters defined?

Also, I'm not sure what is the thing about backpatching and converting
to function calls - I think it should work via engine handlers just as
the rest of the things work in the engine, is it not the case? If not,
it should be made the case.

9. This:
   Eliminate the ability for an accessor to be called via $o→__getHours(),
   the accessor functions will be completely unavailable for use except as
   property references ($o→Hours)

I think it a mistake. More magic and complication in the engine is not a
good thing and would require tons of special case checks in all places
where we deal with functions. I think it is wrong - if we create a
callable entity, it should be callable. __ in the name is the indication
enough that you're dealing with special method and you should tread
carefully, we should not go out of our way to mess up the engine to
prevent it.

10. I'm not sure what the point about debug_backtrace() is but again, we
    should not create more complicated magic there, it just should show what
    really is happening.

11. About read-only/write-only thing - I like not having the keywords,
    but it is still not clear how final produces read-only property - do I
    say something like "final set();" or how can I say "there's no set and
    never will be"?

I'm sorry if some points were already discussed - I scanned through the
multiple threads but may very well missed something in 100+ messages
that there are, in any case I feel most of the questions above must be
reflected in RFC explicitly.

Thanks,

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Hey Stas, a bunch of this has already been covered but I will attempt to answer each of these as is my current understanding of "the hives" decision... :P

1. Accessors IMO should be regular PHP methods that PHP generates with two additional things:
   a. Their name is generated by PHP
   b. Their argument set is defined by the accessor pattern (i.e. same thing as __get/__set).
   We should keep the amount of magic and special cases to the minimum, the engine is complex enough as it is.
   This of course includes the full range of options available for the methods - final, reflection, call scenarios, etc.

This is the way it is, though Nikita strongly disagrees that they should be "callable, visible" methods on the object and I agree with Nikita on this issue, I never did like the idea that __getHours() and __setHours() were methods of a class just because of an accessor definition, which is why I worked to have Reflection hide that fact. If I were to go about this again, they probably will not be methods of the class. Internally there is little requiring an op_array to be attached to a class in order to be executed.

2. isset is defined as:
   isset() { return $this->Hours != NULL; } This does not seem to be correct - != NULL does not work like isset now.
   Try this:
   class A { public $x = 0; }
   $a = new A;
   var_dump(isset($a->x));
   var_dump($a->x != NULL);
   This needs to be fixed - generated isset() should be defined to work exactly like regular isset and actually use the same code path.
   Argument to isset() call can be retrieved using accessor but it should not differ from isset() result in any possible way or situation
   (including error situations - e.g. notices, etc.)

The reason that = NULL and != NULL was chosen is because isset() and unset() are special states that are available only to a variable or property, since a get/set do not return a real property they cannot be used with isset/unset. Now that there has been discussion of an accessor being a real property shadowed by get/set, standard isset/unset could potentially be used against the underlying property.

3. How references and complex cases are handled? Didn't find anything about it, e.g. how it handles $foo->bar++, $foo->bar[] = 1,
   $foo->bar[123] = 4, etc. ($foo->bar being property with get/set defined of course)? How $foobar =& $foo->bar is handled? The sort()
   case mentions by-ref return but does not explicitly mention all other cases.
   These need to be covered explicitly in the RFC.

This is covered in the RFC, perhaps not clearly enough (let me know how I could expand on it further for clarity). To answer each of your questions, you can think of what would happen as if it were a function call. For example, if you did $foo->bar()[123] = 4 you would be modifying a return-by-val. If bar were instead defined as returning a reference, then it would indeed work as you expect above. $foobar = &$foo->bar would work as expected as long as the getter is returning a reference as well.

I, perhaps mistakenly, assumed that if return-by-ref and sort() worked properly, then all other "usages of references" should equally work the same, is that not right? If it's not right, why not?

4. We have some LSP controls now in place to ensure non-LSP overrides generate E_STRICT. Will this be the case for properties too?
   Meaning, what happens if you add overriding protected getter to a property that was previously fully public - thus violating the LSP?

Certainly, this basic object oriented functionality, of course it is upheld. This is one of the reasons I leveraged standard functions in the first place, because these issues were automatically handled by the existing core.

5. What happens if you override accessor property with plain old variable property? I.e.:

class A {
protected $secret {
get() { return "secret"; }
}
}

class B extends A {
public $secret = "not a secret anymore"; }

Also, what happens here if A extends B in the same scenario (this refers to the #4 too).

This is currently up in the air on the RFC side and is being referred to as which "shadows" which. The code currently has it that properties shadow accessors, Nikita suggested that should be inverted and I agree, so unless someone else thinks otherwise, accessors will probably shadow properties.

6. Thinking more about isset/unset - why not make isset/unset always be the default unless overridden? I can't really see the case
   where you want echo $foo->bar to work but if(isset($foo->bar)) echo $foo->bar to not work. I think isset() and unset() should always
   use automatic implementations by default (fixed in accord with #2 of course).

See response to #2 above, without a getter/setter returning a real property, isset/unset accessors were necessary because isset()/unset() cannot perform on a dynamic value. Consider this: unset($foo->bar()) or isset($foo->bar()). Since we are moving in the direction of accessors shadowing properties, I could see the default implementation of isset/unset actually be more like unset() { return unset($this->bar); } and isset() { return isset($this->bar); }

7. "Error messaging" section is not clear. Some examples would help - what is being translated to what?

I will expand on this section in the RFC, but this section is referring to the fact that if bar were an accessor without a set() and this were attempted:

$foo->bar = 4;

It would have errored with:
Fatal error: no function __setbar() exists on object $foo <-- That is not exactly the message returned by core, but you get the point

So the section on error messaging is referring to the fact that all errors involving accessors have been changed to make more sense, ie:
Fatal error: cannot set $foo->bar, no setter is defined.

8. "Static accessors" section is not clear, namely this one:
   This yielded the possibility that a getter call was being made while it should not be allowed (if there was no getter defined) and so
   pass_two() was changed to look for these non-backpatched illegal static getter calls and a compile time error is produced.

When the code is compiled, the class definition (and, in fact, the name of the class we're talking about) may not be available, so how
can you known if certain property of this class has getters defined?

Oh crap, you're referring to the idea that during compilation a class definition may exist below the point of "current compilation," right? I had not considered this case and you're right, this would break badly.

Also, I'm not sure what is the thing about backpatching and converting to function calls - I think it should work via engine handlers
just as the rest of the things work in the engine, is it not the case? If not, it should be made the case.

The static accessors was above my pay grade when I first tackled them, in comparison the object get/set was a piece of cake because it was already being handled by __get() and __set() but static properties are handled in an entirely different way. Because of the nearly completely undocumented code, I could not make heads nor tails of how it worked. I still do not know if I could make this work at the vm/opcode level during runtime but I'd be much more willing to give it a go now.

Most of my deep questions over the last year have gone unanswered and so I was left to my own devices to find a way to make it work.

9. This:
   Eliminate the ability for an accessor to be called via $o→__getHours(), the accessor functions will be completely unavailable for use
   except as property references ($o→Hours)

I think it a mistake. More magic and complication in the engine is not a good thing and would require tons of special case checks in
all places where we deal with functions. I think it is wrong - if we create a callable entity, it should be callable. __ in the name is the
indication enough that you're dealing with special method and you should tread carefully, we should not go out of our way to mess
up the engine to prevent it.

You and Nikita get your gloves on, makes it easier on me to go your direction but Nikita did not like this at all.

10. I'm not sure what the point about debug_backtrace() is but again, we should not create more complicated magic there, it just
    should show what really is happening.

This would refer to the fact that a debug backtrace would show that it's in a function called __getHours() (for example) which would only serve to confuse a php developer who doesn't know that a getter for $Hours is really a function named __getHours(). Therefore I will be patching the error so that it indicates something the php developer will understand, namely that the line is referring to a getter.

11. About read-only/write-only thing - I like not having the keywords, but it is still not clear how final produces read-only property -
    do I say something like "final set();" or how can I say "there's no set and never will be"?

I could not get this point across to anyone but gave up, private final set(); != read-only. With a non "read-only" keyword scenario, a "set" call would still be allowed and would show up as an access violation to outside observers and would be allowed from within the class. This is not what I wanted but I had enough other points of contention and I yielded on this.

I'm sorry if some points were already discussed - I scanned through the multiple threads but may very well missed something in
100+ messages that there are, in any case I feel most of the questions above must be reflected in RFC explicitly.

Thanks,

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Hey Amaury,

Good points all around, but one last thing to point out, interfaces only declare what must be supported by an implementer, properties have no "implementation", they just are. Whereas an accessor has an implementation. So when you see that an interface has an accessor, you can rely on the fact that anyone who implements that interface must implement an accessor of the given name.

From: amaury.bouchard@gmail.com [mailto:amaury.bouchard@gmail.com] On Behalf Of Amaury Bouchard
Sent: Sunday, October 14, 2012 3:23 AM
To: Clint Priest
Cc: Nikita Popov; Benjamin Eberlei; internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2

You are right, we can define __get() in an interface. So, in the end I will shut my mouth.

But still, it's not logical. An interface is a contract which defines the capacities of an object. If an interface defines the entry point swim(), we know that an object which implements this interface is able to swim. The goal is to define what is callable in an implementation (the basics of duck typing: if it can swim() and fly(), it's a flying fish).

In PHP, it was decided that interfaces may not include member variables. I guess it's a philosophical choice; you give orders to an object, knowing what it can do (thanks to the interface). And orders are given by calling methods, not by setting properties.

As I understand your explanation, you think it's normal to be able to define accessors in an interface, because it means there is some code behind. But from my point of view, the implementation (in the PHP interpreter) is not relevant; it's a design choice first.

Take a look at this code:
interface Fooable {
public $aaa { get; set; }
}
class Fooer implements Fooable {
public $aaa {
get { /* wathever ... / }
set { / ... you want */ }
}
}
class Bar {
public function do() {
$foo = new Fooer();
$foo->aaa = 3;
}
}

The Bar object doesn't care if $aaa is an attribute or an accessor. It is used the same way.
So, if we agree that this code is correct, I understand that something like "$foo->aaa" is a valid entry point to communicate with an object through an interface. TIt means that an API is not only defined by methods.
You can argue that an accessor is different from a property, but again, only Fooer knows that, Bar shouldn't have to deal with that.

Then, for me there is two logical choices:

• Forbid accessors in interfaces, as properties are already forbidden.
• Allow accessors in interfaces => allow properties too. But it is a complete redefinition of interfaces in PHP.

I saw the link you gave to me. Well, as I said before, there is a lot of good ideas in C#, but I think PHP is an opinionated language and we can do our own choices (see how namespaces work in a very different way from C++ namespaces, for example).

As you point out, __get() implies the choice has already be done. So I shut up now :-)

2012/10/14 Clint Priest <cpriest@zerocue.commailto:cpriest@zerocue.com>

-Clint

2012/10/13 Clint Priest <cpriest@zerocue.commailto:cpriest@zerocue.com>
Interfaces are used to define what methods must be present, properties are not allowed.

Yes, so no one should be correct, right?
I mean, yes the first declaration implies some code; but for the interface, it's still a property definition.

You're mixing concepts here, it's an accessor definition, not a property definition. property != accessor, an accessor just happens to look and act like a property (which is the point of accessors).

Interfaces define methods, not properties. Fine.
But is an accessor (as defined in the RFC) a method? Or should we consider that an accessor definition is valid inside an interface? I would say no, because it will be used as a property: outside of the object that implements the accessor, nobody know if it's an attribute or an accessor function.

It's the whole point of the RFC (apart from the asymetric visibility, but you know my point of view).

So, for me, this code should be incorrect:
interface Fooable {
public $abc { get; set; }
}

Because if an object implements the interface:
class Fooer implements Fooable {
public $abc {
get { /* what you want / }
set { / what you want too */ }
}
}

How this code will be used? Like that:
$foo = new Fooer();
$foo->abc = 3;
print($foo->abc);

Everybody will agree with me that $abc is used like a property, not as a method. So the language should enforce that.
There is a real issue here; this is not a fad from me.

An accessor is a method and an interface which defines an accessor is indicating that the accessor must be implemented by any using the interface.

See: http://msdn.microsoft.com/en-US/library/64syzecx(v=vs.80).aspx

Also, "used like a property" does not mean it is a property, it is a method call with the syntax of accessing a property, it is still a method call.

I believe __get() may be declared in an interface and if so, then accessors should be as well.

Hi!

You have already written seven mails all saying how much complexity
this would introduce. Could you maybe elaborate a bit on that? How
would it make anything more complex? I mean, the only really

Any code that deals with methods would now have to consider - is this
regular method or special "uncallable" method? Can I call it? Can I list
it in the list of class methods? This leads to weird situation where
current method may not be callable and may not be found by reflection on
$this. And all inheritance functions will have to consider them
separately from all other methods, etc. And interface implementation has
to be changed to account for existence of not-quite-methods. And so have
traits. Etc., etc.
Even conceptually, you need to be aware that there are methods of class
and then there are non-methods which look exactly like methods in almost
every aspect but aren't.

This adds complexity and inconsistency - for no benefit whatsoever (I do
not consider being not able to call __get* benefit since I see no use
case for this requirement).

I want to keep this simple - accessors are fine if they just produce a
set of methods, everybody knows what PHP methods are and how they work,
there would be just couple of more entries in function table, simple
enough and every other part of the engine knows how to take care of such
thing. But if they introduce a complexity of
methods-that-aren't-quite-methods and live in a limbo outside of class
table even though they work as methods, except in cases where they don't

• I'd really rather go back to old trusty __get then - at least it is
  clear how that works and you don't have to deal with special cases and
  exceptions on every turn.
  --
  Stanislav Malyshev, Software Architect
  SugarCRM: http://www.sugarcrm.com/
  (408)454-6900 ext. 227

This isn't the way isset() works, isset() will return true for a
variable with a value of 0

Exactly my point. Your code (with != NULL) will return false while real
isset() will return true.

Stas, please see this execution output, your arguments about isset()/unset() are just plain wrong:

[...]

1. isset() on a NULL value will return false
2. isset() may not be called on the result of a function call (which is what an accessor is)

I'm not exactly sure, but I think that all Stas is trying to say is
that it should be !== NULL instead of != NULL.

Nikita

I've been re-reading the last few days of posts to collect what is to be changed about the RFC on what has seemed to come to a consensus and my apologies Stas, I did not catch exactly what you meant by this statement:

Exactly my point. Your code (with != NULL) will return false while real isset() will return true.

But all that really needs to be changed is that the automatically implemented isset() code should use !== instead of !=, then it perfectly satisfies the exact way that isset/unset work.