Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:37863 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 13807 invoked from network); 25 May 2008 16:49:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 May 2008 16:49:22 -0000 Authentication-Results: pb1.pair.com header.from=helly@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=helly@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender) X-PHP-List-Original-Sender: helly@php.net X-Host-Fingerprint: 85.214.94.56 aixcept.net Linux 2.6 Received: from [85.214.94.56] ([85.214.94.56:33701] helo=h1149922.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 37/0C-21001-19899384 for ; Sun, 25 May 2008 12:49:22 -0400 Received: from MBOERGER-ZRH.corp.google.com (228-188.78-83.cust.bluewin.ch [83.78.188.228]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by h1149922.serverkompetenz.net (Postfix) with ESMTP id F423711EFE1; Sun, 25 May 2008 18:49:18 +0200 (CEST) Date: Sun, 25 May 2008 18:48:48 +0200 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <1343210891.20080525184848@marcus-boerger.de> To: Daniel Convissor CC: PHP Internals List , Sara Golemon In-Reply-To: <20080525143031.GA4309@panix.com> References: <20080405132733.GA6531@panix.com> <104525707.20080525105722@marcus-boerger.de> <20080525143031.GA4309@panix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Overloading Clarifications for Manual From: helly@php.net (Marcus Boerger) Hello Daniel, Sunday, May 25, 2008, 4:30:32 PM, you wrote: > Hi Marcus: > On Sun, May 25, 2008 at 10:57:22AM +0200, Marcus Boerger wrote: >> Saturday, April 5, 2008, 3:27:33 PM, you wrote: >> >> We experimented with visibility and ran into trouble. > ... >> So we in fact note the visibility but then ignore it. >> >> I think we either need to respect the visibility or issue an error if it >> is not public. Please file a but report. > Turns out, one already exists: http://bugs.php.net/bug.php?id=44769 >> > * The value of $name in __call() is case sensitive, but in the newly >> > added __callStatic() $name is lower case. Is this intentional? It seems >> > the two methods should have the same behavior. >> >> It isn't for function calls so this is the correct behavior. > I don't understand your response. Can you please clarify? Oh, actually it is my fault - I've read this part wrong. So infact __call is case sensitive. This is becasue the engine is indeed case sensitive up to the final lookup all over the place. We do that so that we can produce case sensitive error messages. So not doing a down case just enables the same behavior for the user. The other reason for making __call case sensitive is that an overloaded object might need the correct casing information. That said there is a bug in __callStatic which we need to report and assign to Sara. > --Dan > -- > T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y > data intensive web and database programming > http://www.AnalysisAndSolutions.com/ > 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 Best regards, Marcus