On Thu Dec 2 02:11 AM, Larry Garfield wrote:
>
> See, here's the fundamental problem we're running into. There's three
> different definitions of what a property is that we keep bouncing
> between, each of which will dictate both syntax and semantics:
>
> 1) Properties are a smart masking layer over class members, like a
> smarter __get/__set, designed to make it possible to swap out in place
> of class members at will. In this case, both the syntax and semantics
> of properties should mirror class members as close as possible.
>
> 2) Properties are a short-hand for getFoo()/setFoo() methods (which in
> the general sense should *not* be understood to always map to class
> members, as discussed), designed to make typing $o->getFoo() and $o-
> >setFoo() shorter/easier. In this case the syntax and semantics
> >should
> make that clear and not confuse the user with class-member-like syntax.
Right, for example:
$tp = new TimePeriod;
$tp->hours = 2;
foreach($tp as $prop => $val)
Would this be an empty loop? That seems to be what the RFC proposes (2)
"layer of syntactic sugar over a pair of methods".
If a property is to provide the (1) "illusion of a variable" (~class
member), IMHO it provides a clear benefit over the __get(), __set() methods.
In the spirit of (1):
class Audit_Entry {
public $info;
public $timeAdded { // illusion of a variable, removed 'public property'
to avoid confusion
get {
return $this->_timeAdded;
}
isset {
return isset($this->_timeAdded);
}
};
protected $_timeAdded; // Datetime
function __get($prop)
{
// virtual properties, these are not class members
}
}
In the spirit of (2), it seems like we would have two ways of doing the same
thing.
It would probably be a good idea to deprecate __get(), __set()... in favor
of the C# style
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
