Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32815
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 85.10.196.195 cause and error)
In-Reply-To: <7C37FF3A0196094F95430BA95952032201611E@s1.mkj.lan>
References: <7C37FF3A0196094F95430BA95952032211B7C5@s1.mkj.lan> <cd5680a20710131322k110ee1e4q9194d8390df398f3@mail.gmail.com> <7C37FF3A0196094F95430BA95952032211B7C7@s1.mkj.lan> <72129346.20071014092922@marcus-boerger.de> <7C37FF3A0196094F95430BA95952032211B7CC@s1.mkj.lan> <19939840.20071014231353@marcus-boerger.de> <002f01c80f5b$d645d340$15b2a8c0@unterwegs> <7C37FF3A0196094F95430BA95952032211B7D2@s1.mkj.lan> <4714881F.1030302@cschneid.com> <7C37FF3A0196094F95430BA95952032201611B@s1.mkj.lan> <47149337.9000209@cschneid.com> <7C37FF3A0196094F95430BA95952032201611D@s1.mkj.lan> <C3712B89-CEAF-4328-B774-EA5DFB1147BB@pooteeweet.org> <7C37FF3A0196094F95430BA95952032201611E@s1.mkj.lan>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <D9094672-8078-4E0A-8026-CE417566B8DD@pooteeweet.org>
Cc:  <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Date: Tue, 16 Oct 2007 15:56:48 +0200
To: Hans Moog <hans.moog@mkj-computing.de>
X-backendmedia-com-MailScanner-Information: Please contact the ISP for more information
X-backendmedia-com-MailScanner: Found to be clean
X-backendmedia-com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=0.083, required 6, AWL -0.02, RDNS_DYNAMIC 0.10)
X-backendmedia-com-MailScanner-From: mls@pooteeweet.org
X-Spam-Status: No
Subject: Re: AW: AW: AW: [PHP-DEV] Method overloading by method signature
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 16.10.2007, at 15:09, Hans Moog wrote:

>
> When it comes to interoperation between systems and or developers,  
> it is always a
> good idea to define strict standards of how the communication  
> between libarys and components
> has to take place (since public methods are something like an  
> interface bewteen interoperating libraries and classes),
> to be sure that all components work together as expected. One of  
> the best approaches to
> explain the usage of the class to a foreign developer and to be  
> sure that your class is used
> correctly and help the foreign developer to understand how your  
> classes have to be used
> (beside documentation), is to typehint your parameters.
>

I do not agree that its always a good idea to make your communication  
strict when you are using a type less language. Are you implying that  
for some reason typeless-ness only becomes relevant in your user land  
code? I do agree that libraries tend to be a bit more "static" and  
therefore less in need of quickness in development, but I do not see  
this validating your core assumption that strictness is a good thing  
for libraries. PHP has always tended more towards keeping running  
when at all possible rather than throwing fatal errors. The advent of  
exceptions has changed part of this game already, but I do not think  
that the solution is to start turning every situation the developer  
hasnt thought off into fatal errors. Sometimes barely working is  
better than not working and I think this is a mantra on the web.

> But when you do so, you are no longer able to overload your methods  
> anymore. Because of this, I think
> this feature is EXTREMELY relevant to solving the web problem. Not  
> being able to overload methods anymore
> is a bad thing since overloaded methods allow to use a class in  
> much more situations than just being able to use it
> in one single way.
>
> You are not able to tell the developer to use integer OR string  
> values but NO arrays, booleans, Objects
> and so on when calling your method.
>
> You could mention it in the comment but when he misunderstands the  
> comment, php doesn't notify him about
> his error. When using type hinted parameters, php would do so.
>
> You are not able to provide strict api's out of the box right now.  
> You will always have to check the types of the
> passed parameters manually.

Your list of if's is quote long, which illustrates what kind of niche  
problem you are solving. The bulk of all libraries can live quite  
well without type hints. If you choose to use them, then accept their  
limitations and add manual overloading via separate functions that  
cover all reasonable permutations. Or implement this overloading the  
same way other people handle the lack of named parameters. The  
addition of type hinting was questionable enough, that they hardly  
warrant yet another addition just to make them even more useful in a  
niche case.

regards,
Lukas