I'll agree with you in regards to your analysis of Clint's proposed syntax.
In terms of your questioning the idea around "read-only", this is how I
think about it:
Class A created property accessor $z that you can not set. Class B can
extend me just fine, but they can not alter that basic rule that I laid out
for my and all my children's property accessor $z: You can not set it.
This makes sense to me, and I feel like it is control that the developer
should have.
If we were to translate *final set NULL;* (or whatever implementation we
choose to use) to a more manual implementation, it may look something like
this:
public $property {
> final get() { ... }
> final set($value) { throw new Exception("You can't set $property. It is
> read only."); }
> }
>
On Sat, Oct 20, 2012 at 2:40 AM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> Hi!
>
> > get() { return $this->Hours; }
> > final set NULL;
>
> It looks like some unobvious piece of magic - what exactly "set NULL"
> means? There's no obvious parsing of this thing for somebody that
> doesn't already know what the magic means. I'd rather have people
> implement a method throwing exception manually than have this. It's
> unclear what is relationship between "set" (is it a variable? a
> constant? a method?) and "NULL" (what NULL here means? is it assignment
> of NULL to set? is it declaration of NULL with type "set"?) and it does
> not parse naturally with almost any background.
>
> Thinking about it for a while, the whole idea of "this class can never
> have this method implemented" looks a bit strange to me - I don't think
> I've ever encountered such concept in OOP. You can say "I implement it
> this way and you can't override it" but NULL does not suggest any
> natural implementation.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
