Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23563
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <446BBE40.7070803@akbkhome.com>
Date: Thu, 18 May 2006 08:22:24 +0800
User-Agent: Debian Thunderbird 1.0.7 (X11/20051017)
MIME-Version: 1.0
To: Jeff Moore <jeff@procata.com>
CC: "D. Dante Lorenso" <dante@vocalspace.com>, 
	Marcus Boerger <helly@php.net>,
	Jason Garber <jason@ionzoft.com>, 
	Christian Schneider <cschneid@cschneid.com>,
	internals@lists.php.net
References: <785810036.20060511193536@ionzoft.com> <44647B7A.2070301@php.net> <932738738.20060513112734@marcus-boerger.de> <837405862.20060513223403@ionzoft.com> <36828701.20060514110529@marcus-boerger.de> <31269879.20060514221212@marcus-boerger.de> <1327845846.20060514222154@marcus-boerger.de> <1562034641.20060516203354@marcus-boerger.de> <7.0.1.0.2.20060516235201.090f10a8@zend.com> <7.0.1.0.2.20060516142654.02c78380@zend.com> <596643859.20060516233753@marcus-boerger.de> <7.0.1.0.2.20060516144030.039abe98@zend.com> <1531743211.20060516234945@marcus-boerger.de> <1014418169.20060516181322@ionzoft.com> <1677590447.20060517002135@marcus-boerger.de> <446A5B52.9060001@cschneid.com> <27079878.20060516191743@ionzoft.com> <446A601A.8010205@vocalspace.com> <f37b7981bd663f536ab158423df934a7@procata.com>
In-Reply-To: <f37b7981bd663f536ab158423df934a7@procata.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] private, protected, readonly, public
From: alan@akbkhome.com (Alan Knowles)


Just to be complete ;)

D:

int hidden_name;
public int the_var_name() { return hidden_name; }
private void the_var_name(int s_value) { hidden_name = s_value; }

ref: http://www.digitalmars.com/d/archives/56.html

Regards
Alan


Jeff Moore wrote:

>
> On May 16, 2006, at 7:28 PM, D. Dante Lorenso wrote:
>
>> I'm not familiar with this OOP concept from any other language.   
>> Perhaps it exists, but if it doesn't, is there a reason why?
>
>
> Hello,
>
> Its hard to find a major OO language that does not have  
> property/accessor method support.
>
> C#:
> private int x;
> public int X { get { return x; } set { x = value; } }
>
> Ruby:
> def name, def name=(x) syntax plus attr_reader, attr_writer shortcuts
> http://www.rubycentral.com/book/tut_classes.html
>
> Delphi:
> Property Name : Type read Getter write Setter;
>
> Python:
> I'm not very familiar with python, but it appears to have accessor  
> method support:
> http://www.python.org/download/releases/2.2.3/descrintro/#property
>
> Visual Basic:
> Public Property Name() As String
>     Get
>         Return NameValue
>     End Get
>     Set(ByVal Value As String)
>         NameValue = Value
>     End Set
> End Property
>
> Objective C:
> Key Value Coding
> http://developer.apple.com/documentation/Cocoa/Conceptual/ 
> KeyValueCoding/KeyValueCoding.html
>
> Smalltalk:
> name
>     ^name
> name: aValue
>     name := aValue
>
> Java:
> Java doesn't have a specific language syntax, but it does have a  
> standard for declaring accessor methods.
> http://java.sun.com/products/javabeans/docs/spec.html
>
> C++:
> I'm not very familiar with C++ and I don't know what is standard,  
> but  tool builders such as Microsoft and Borland have had to add their 
> own  property syntax to C++.
>
> PHP:
>
> PHP doesn't really have accessor method support.  __get and __set are  
> property missing handlers, not accessor methods.  This leads to 
> several  problems:
>
> 1. __get/__set are too cumbersome for simple use cases.  (Hence this  
> thread)
> 2. __get/__set is slow.  (In the best case: about 10x slower than  
> simple property, 3x slower than an accessor method call)
> 3. properties defined with __get/__set can only be public
> 4. Reflection does not work with __get/__set
> 5. Source code analysis does not work with __get/__set (no phpdoc,  
> annotations, auto completion, etc.)
> 6. No support for static properties via __get/__set
> 7. __get/__set is error prone.  Mistakenly creating a simple property  
> of the same name disables the magic methods.
> 8. Some obscure design problems with inheritance not worth going into  
> here.
>
> The Pandora's box of complexity was opened when PHP got __get and  
> __set.  readonly or readable is just a bandaid that fixes one use 
> case  of one problem, but does it in a way that doesn't help fix any 
> of the  other problems in the future.
>
> There is nothing wrong with simple properties in PHP just the way 
> they  are now.  There is also nothing wrong with __get or __set.  They 
> work  well when you truly need virtual properties, such as for an 
> active  record or a proxy class.
>
> What PHP is missing is a way to associate individual accessor methods  
> with individual properties, just as you can in Java, C#, Ruby, 
> Delphi,  Python, Visual Basic, Objective C, Smalltalk, and sometimes 
> C++.  (To  the best of my knowledge.)  Read only is a special case of 
> this  capability.
>
> Best Regards,
>
> Jeff
>