I'm in favor of all your points Clint and type hinting would be very valuable
to me. Also, I would favor if reflection does not reveal internals either. If I
am correct, that would require ReflectionClass to have
getPropertyAccessors()/getPropertyAccessor('Hours') method and a new
ReflectionPropertyAccessor class for property accessors.
My main point is regarding the read-only issue. I think that, given that the
problem only arises when inheriting from a class defining a property accessor,
a solution would be not to allow to extend accessor property functions (get(),
set(), isset() and unset()) that are not defined in the parent class.
Otherwise, an error should be raised. Something similar is already implemented
in PHP when overriding a parent method with a different signature. Here, we
would not allow to implement a different "signature" for property accessors in
the child class. So:
class Timing
{
/* … */
/* set() not defined, setting $Hours is not allowed, $Hours is thus
read-only, everybody should agree with this */
public $Hours {
get() { return $this->seconds / 3600; }
final isset() { return isset($this->seconds); }
unset() { unset($this->seconds); }
}
}
class SpecialTiming extends Timing
{
/** … */
public $Hours {
get() { return $this->seconds / 3600; } // <-- OK,
set(TypeHint $value) { $this->seconds = 3600 * $value; } // <--
ERROR, set() not defined in parent class
final isset() { return isset($this->seconds); } // <-- ERROR,
isset() is final in parent class.
/* unset inherited from parent class */
}
}
Am 11.10.2012 um 21:45 schrieb Clint Priest <cpri...@zerocue.com>:
> Rather than go to the trouble of finding a reasonable way to hold a vote on
> these issues, is there anyone against the following changes:
>
> 1) 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)
> 2) Change syntax to use public set($value) { }, public get(), etc. (and
> along with that means no more "magic" $value)
> 2a) If possible, allow for Type Hinting...
> 3) Eliminate automatically implemented get; set;, no automatic backing field
> creation will occur.
> 4) read-only / write-only keywords will be eliminated
> 5) Exceptions thrown from accessors will be made more appropriate (I will
> also check debug_backtrace information, etc)...
>
> If there isn't anyone against the above changes, I will make the changes to
> the RFC and re-present for final agreement...
>
> Or... do ya'll want to vote on the aforementioned changes?
>
>> -----Original Message-----
>> From: Clint Priest [mailto:cpri...@zerocue.com]
>> Sent: Wednesday, October 10, 2012 7:36 PM
>> To: internals@lists.php.net
>> Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
>>
>> Okay, I would like this to be the last time there are revisions to this RFC.
>>
>> To sum up the last few days of conversations, I have these down as points of
>> contention:
>>
>> 1. Accessor functions should not be present on the object and callable
>> directly, for example, $o->__getHours() should not be
>> allowed.
>> 2. Preferred syntax for accessors should be "public set($value) { ... }"
>> with no "magic" $value (with possible type hinting) 3.
>> Automatically implemented get; set; with auto-backing field should be
>> eliminated as this is not necessary for PHP and is confusing
>> most everyone.
>> 4. read-only / write-only keywords, keep them or get rid of them? There is
>> no directly suitable replacement but I believe a private
>> final set() { } will take care of it, even though it much more verbose.
>> 5. Error handling for thrown exceptions should be made more appropriate for
>> accessors 6. The "truth" of reflection. Should it reveal
>> details internal to how PHP works on the inside or should it reflect the way
>> PHP presents it as options?
>>
>> Did I miss anything?
>>
>>
>> I will come up with some way for people to vote on the issues at hand and we
>> can cast our votes and be done with it, then I will
>> finish the project and get it out the door.
>>
>> -Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
