Re: RFC: C-sharp style property get/set syntax for PHP

On 11/30/10 5:55 PM, president@basnetworks.net wrote:

This is a very well-written and well-thought through RFC, Dennis. Nicely done.

Thank you!

First of all, I have generally found the Bean-style getter/setter

approach to

be a sign of poor encapsulation to begin with. You shouldn't be mucking

with

internal elements of an object in the first place, period. More details on that here: http://www.garfieldtech.com/blog/property-visibility

Interesting post, although I can't say I agree with your views. Your post leaves me wondering how the user is expected to get or give data to a class (for example, if I'm not supposed to do $customer->name or $customer-getName(), how do I get the customers name?). Additionally, you are forgetting the real power of properties, which is the ability to generate a get value, and process a set value, because get/set are methods. Properties are hardly just an indirection layer around an underlying piece of data.

The idea of a ->getName() method for retrieving a person's name is fine. My point there is that any assumption that it corresponds to a ->name class member (as Bean definitions require) is invalid on its face. (The context there is a lengthy ongoing debate regarding the use of public vs. protected class members, with my basic point being that class members are an implementation detail and if you care about them in the first place then you have a bug. Yes, it's a deliberately stringent position.) What I'm seeing here is that whether properties are intended as an indirection layer for class members (eg, a more robust __get/__set) or not is a fuzzy question. On the one hand they are (since the goal of the syntax is to make it irrelevant to the caller which is happening), but on the other they're supposed to be something different that can do all kinds of on the fly behavior. I'm not going to say "pick one!" because both are valid use cases with significant benefit, but it is a point of potential confusion in both the discussion and eventual documentation.

Right, the property keyword ties together with the "function" keyword, and the semi-colon provides no real purpose to the author. I have however been told that the semi-colon is important from an internal perspective, and would ease the implementation.

Another reason that the function keyword should remain mandatory, IMO. :-) I cannot speak to the implementation details, but I do know that the semi-colon would horribly confuse a lot of people.

In C#, get and set methods of a property are compiled down to methods, and calls to a property are changed to calls to those methods. Therefore their performance in C# is exactly that of a method call. This is ideal, since properties are meant to be a replacement for the standard "getXYZ/setXYZ" design pattern.

I cannot speak to the implementation potential in PHP as I have never looked at the compiler's code.

- Which also brings up an interesting question: class Foo { public $a = 1; protected $b = 2; public property $a { get { return 3; } } public property $b { get { return 4; } } } $f = new Foo(); print $f->a . PHP_EOL; // Does this print 1 or 3? print $f->b . PHP_EOL; // Does this print 2 or 4, or error?

Both of those throw an error. Properties and variables share the same namespace, so you cannot define a property and variable with the same name.

Is this consistent with methods? Do those share a namespace, too? (I don't actually recall off the top of my head.)

This is what I would imagine seeing, and would compile: class Foo {

    private $_a = 1;
    protected $_b = 2;

    public property $a { get { return 3; } }
    public property $b { get { return 4; } }

} As you can see, there is no conflict or confusion this way.

True, although for the record I have always detested the underscore prefix on variables as a difficult to read hack. :-)

That's all I got for now. Once again, nice RFP but still needs some thinking.

Of course, that is why I am harnessing your collective brains!

BRAAAAAAAINS! --Larry Garfield