Re: final keyword
| From: | Sebastian Schneider | Date: | Wed, 13 Feb 2008 12:13:18 +0000 |
| Subject: | Re: final keyword | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-35445@lists.php.net to get a copy of this message | ||
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.patche.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=bBest regards, Marcus