Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:23321 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26248 invoked by uid 1010); 12 May 2006 21:33:20 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 26233 invoked from network); 12 May 2006 21:33:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 May 2006 21:33:20 -0000 X-PHP-List-Original-Sender: dante@vocalspace.com X-Host-Fingerprint: 69.56.193.72 fox02.stravio.com Linux 2.5 (sometimes 2.4) (4) Received: from ([69.56.193.72:58074] helo=fox02.stravio.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 8E/B4-19568-F1FF4644 for ; Fri, 12 May 2006 17:33:19 -0400 Received: from [127.0.0.1] (c-67-177-79-15.hsd1.tx.comcast.net [67.177.79.15]) by fox02.stravio.com (Postfix) with ESMTP id 0501226C2CE; Fri, 12 May 2006 16:33:15 -0500 (CDT) Message-ID: <4464FF11.6060204@vocalspace.com> Date: Fri, 12 May 2006 16:33:05 -0500 User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Andi Gutmans Cc: Jason Garber , itrebal@gmail.com, Hartmut Holzgraefe , Bastian Grupe , internals@lists.php.net References: <785810036.20060511193536@ionzoft.com> <4464AC64.5050706@gmail.com> <4464C6C9.40307@php.net> <4464C8AE.1050806@gmail.com> <4464CF54.7070802@php.net> <2e24b1e00605121216x6c873e0eo5efaf960f5e00a74@mail.gmail.com> <09347954.20060512164435@ionzoft.com> <7.0.1.0.2.20060512140631.02ac4d78@zend.com> In-Reply-To: <7.0.1.0.2.20060512140631.02ac4d78@zend.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] private, protected, readonly, public From: dante@vocalspace.com ("D. Dante Lorenso") Andi Gutmans wrote: > I can take any feature in PHP and add features :) Is that an offer ;-)? I've got a couple you can add, lol. Dante > > At 01:44 PM 5/12/2006, Jason Garber wrote: >> Hello, >> >> PHP implements many features, and skips many features. I think the >> rule of thumb needs to be that if a feature is implemented, finish >> it. >> >> For example, if you provide __get() and __set(), provide an >> efficient way of handling the normal use case. >> >> If you start triggering an E_NOTICE when an undefined variable is >> accessed, then provide an easy way to access variables that may or >> may not be set. >> >> If you provide a __tostring() method, then finish it so that is gets >> called when an object is cast to a string, concatenated with a >> string, as well as being output with echo, print. >> >> There are a lot of casual users of PHP. There are also the people >> out there who are buying the Zend products, buying the MySQL support >> contracts, using PHP at Yahoo! -- the people who have chosen to use >> PHP OVER Java/.NET/Perl, because it is a great language -- the >> people who need the completed features because they are running >> multi-million-dollar businesses on this platform. >> >> >> Take a step back and truly evaluate why someone in a demanding >> situation might want every bit of performance and readability that >> they can squeeze out of *existing* language features. >> >> I'm not talking about adding hundreds of new features, or turning >> PHP into the next java. It's about real business cases. >> >> It's not about what YOU WOULD NOT use, it's about what a lot of >> people need. >> >> -- >> Best regards, >> Jason Garber mailto:jason@ionzoft.com >> IonZoft, Inc. >> >> Friday, May 12, 2006, 3:16:27 PM, you wrote: >> >> igc> It seems to me this would be a great option to add. How >> difficult would it >> igc> be? Would it take significant editing of the source code? I >> don't see the >> igc> issue in adding it - seems like it would have plenty of places >> to be used. >> igc> Though, if it is added, the name 'readonly' seems a little >> misleading. It >> igc> gives off the idea of being able to set it, and not edit again, >> and not only >> igc> being able to edit it inside the class. >> >> igc> On 5/12/06, Hartmut Holzgraefe wrote: >> >> >> >> Bastian Grupe wrote: >> >> > Blame my recent use of Java here ;-) >> >> > >> >> > Well, I think the whole point of ppp is to having to use setters >> and >> >> > getters consistently. >> >> >> >> i'm going to blame your use of Java for this one, ppp is way older >> >> than the setter/getter fashion and as far as i remember the main >> >> reason to introduce the setter/getter pattern into java was to >> >> have a standard way for Java IDEs to provide access to Java Bean >> >> properties in property dialogs in their GUI design tools >> >> >> >> > I personally wouldn't like to be able to access some members >> which are >> >> > private, and not others. It just *feels* wrong. >> >> >> >> Think of it as a more fine grained permission system, like unix >> >> file attributes. Reading and writing a property value are two >> >> different operations and it makes sense to distinguish access >> >> rights not only by ownership but also by type of operation. >> >> >> >> > And I don't know whether or not less typing is really a good >> argument in >> >> > this situation (think unreadable code in shortcut-ish programming >> >> > languages). >> >> >> >> Less typing is not an argument by itself, else we'd all do APL >> >> >> >> But less typing is less error prone (and no, plese *don't* mention >> >> auto-completion here ;), it can be less readable, too, and in this >> >> special case it spreads information that should be in one place. >> >> Maintainability can become an issue, too. >> >> >> >> Take a look at typical PHP class implementations: they have >> >> all properties on top followed by the member functions. So to find >> >> out whether a private property is really provite or whether it has >> >> a getter or even a setter, too, i would have to browse the full >> >> class code. >> >> >> >> class example { >> >> private $foo; >> >> private $bar; >> >> [... more properties ...] >> >> >> >> function __construct() {...} >> >> function __destruct() {...} >> >> >> >> function getFoo() {...} >> >> >> >> [... more code ...] >> >> } >> >> >> >> So $foo is readonly here and $bar is really private. Or wait, >> >> maybe we have just overlooked getBar()? >> >> >> >> With >> >> >> >> readonly $foo; >> >> >> >> on the other hand you have all the information in one place. >> >> >> >> If you want to go the getter/setter path all the way then we >> >> wouldn't need all the ppp stuff anymore alltogether, we would >> >> just make everything private and have the getter and setter >> >> decide (using instanceof on $this etc.) the access rights. >> >> >> >> >> >> -- >> >> Hartmut Holzgraefe, Senior Support >> Engineer . >> >> MySQL AB, www.mysql.com >> >> >> >> Are you certified? http://www.mysql.com/training/certification >> >> >> >> -- >> >> PHP Internals - PHP Runtime Development Mailing List >> >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> >> >