Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:18479 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2387 invoked by uid 1010); 26 Aug 2005 18:08:08 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 2372 invoked from network); 26 Aug 2005 18:08:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Aug 2005 18:08:07 -0000 X-Host-Fingerprint: 65.19.190.98 procata.com Linux 2.4/2.6 Received: from ([65.19.190.98:59476] helo=procata.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 5D/83-28235-78A5F034 for ; Fri, 26 Aug 2005 14:08:07 -0400 Received: from 65.111.204.63 ([65.111.204.63]) by procata.com for ; Fri, 26 Aug 2005 11:07:55 -0700 In-Reply-To: References: <430DBD80.6090804@cschneid.com> <430DC0DC.4060506@emini.dk> <6.2.3.4.2.20050825182507.064da170@localhost> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-ID: Content-Transfer-Encoding: quoted-printable Cc: Frederik Holljen , Andi Gutmans , PHP Developers Mailing List Date: Fri, 26 Aug 2005 14:08:21 -0400 To: Derick Rethans X-Mailer: Apple Mail (2.622) Subject: Re: [PHP-DEV] Property Overloading RFC From: jeff@procata.com (Jeff Moore) On Aug 26, 2005, at 5:55 AM, Derick Rethans wrote: > I'm just arguing that the current way that setters and getters are > implemented is broken. Instead of keeping a broken behavior I would =20= > like > to see it fixed. Derick, It is not broken its incomplete. PHP doesn't really have an =20 implementation of getters and setters. The __get and __set are really =20= just "property not defined" hooks, not getters and setters (accessor =20 methods). If you take a look at a dynamic language that does does define a =20 standard for getters and setters, Key Value Coding in Objective C, you =20= will see what I mean. KVC defines a (complicated) search path for =20 looking up a property: 1. Search the receiver=92s class for an accessor method whose name =20 matches the pattern -get, -, or -is, in that order. 2. If no accessor is found, and the receiver=92s class method =20 accessInstanceVariablesDirectly returns YES, the receiver is searched =20= for an instance variable whose name matches the pattern _, =20 _is, , or is, in that order. 3. If no appropriate accessor or instance variable is found, =20 valueForUndefinedKey: is invoked for the receiver, and the value is =20 returned. ObjectiveC's valueForUndefinedKey is the same as PHP's __get. What php =20= lacks is the stage in the process that looks for accessor methods. In =20= current PHP: 1. Search the object for an instance variable 2. If no instance variable is found, __get is invoked on the object and =20= the value returned. I think where you are running into trouble with the property keyword is =20= that it is targeting the wrong stage in the property name search =20 process. It simply does not make sense to declare properties in the =20 class for the "undefined property" (__get) stage of the search process. Right now, most people simulate accessor methods in user space using =20 __get and __set and if statements, case statements, introspection, =20 arrays, or a variety of other techniques. If you want to improve this process and bring it into the engine, then =20= the place to do it is the property name search path. This is where =20 declared properties with accessor methods should be handled. An =20 accessor method check could be added either before or after the check =20= for the instance variable. A new keyword isn't necessary here, a =20 simple naming convention could suffice as in ObjectiveC. Reflection =20 could be made aware of the naming conventions, etc. However, adding the stage before, as in ObjectiveC, seems unlikely to =20= gain much support here because of potential BC issues with method names =20= and performance concerns. (Although, some things will become faster, =20= some things will become slower.) Adding the stage after also seems unlikely to gain much support here =20 because it can be simulated fairly well right now in user space using =20= the current __get mechanisms. (Which is exactly what we do on the WACT =20= project.) I happen to think that a PHP standard for accessor methods would be a =20= good thing, but adding a stage to the search path is a hard sell. =20 Without adding a stage to the search path for property names, a =20 property keyword such as proposed makes little sense, the current =20 mechanisms are sufficient. I understand the problem you're trying to solve, support the need for a =20= solution, but don't think this proposal solves the problem. Ref: http://developer.apple.com/documentation/Cocoa/Conceptual/=20 KeyValueCoding/index.html=