On 11/30/10 5:55 PM, presid...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
