Guys, I think we are over-engineering and over-complicating here. Reminds me of all the ugly workarounds in C++.
If this is really what you need then just declare it private/protected and create accessor methods (getters/setters). I don't think it makes sense to introduce additional complexities both to the grammar and the visibility logic for something very few people are going to get their heads around... Andi > -----Original Message----- > From: Sebastian Schneider [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 13, 2008 4:13 AM > To: Marcus Boerger > Cc: Felipe Pena; internals@lists.php.net > Subject: Re: [PHP-DEV] final keyword > > Hey you guys, > > but the construct > private : public $bar = 'foo'; > addresses actually another - fairly similar - issue. > > whereas I believe it's sufficient just extending the const > or final keyword, which introduces not a new "language construct" and > thus affects really nothing but issue. > > Your syntax would be kind of helpful when addressing security related > codes, which need to encapsulate variables. > Anyway, it would be better to use getters/setters to abstract from the > actual implementation, where you can "react" more precise on the read > request (not knowing you called the method, however). > > Cheerio, > Sebastian > > > Marcus Boerger schrieb: > > Hello Felipe, > > > > I do not like readonly, instead I would prefer a version where read > and > > write have separate visibility. And actually your idea seems to > prevent a > > second write to the value, using NULL as for detection means. Now > what > > happens is that a) a property that has a default value will become a > const, > > yet with some trickery (array conversion, ArrayObject) allowing to be > > ignored. And b) when set to NULL you can do another write until you > do a non > > NULL write. All that said, here is my idea again: > > > > class Foo { > > private : public $bar = "baz"; > > > > This does: > > a) not introduce a new keyword > > b) have write access private and read access public > > c) is compatible with all we have right now > > d) could be limited to public on the read side > > (ze2-readable_properties-20060514d.diff.txt). > > > > I even had a patch in may 2006 (ze2-readable_properties- > 20060516.diff.txt) > > that implements the new visibility promulgate (which i thought of as > a funny > > solution to public read). > > > > marcus > > > > Wednesday, February 13, 2008, 11:18:17 AM, you wrote: > > > >> Em Qua, 2008-02-13 às 10:59 +0100, Sebastian Schneider escreveu: > >>> By the way, when declared final the value couldn't be changed, > anyways - > >>> however it MUST be read-only. > >> I made a ***simple*** (or wrong!) patch months ago for read-only > >> property as you described. > > > >> http://felipe.ath.cx/diff/readonly.patch > > > >> e.g. > >> class foo { > >> private readonly $foo = array(1, 2, 3); > >> } > > > >> But i agree with early discussions, and with Marcus' implementation: > >> http://marc.info/?l=php-internals&w=2&r=1&s=readonly&q=b > > > > > > > > > > Best regards, > > Marcus > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
