Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:29844 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11291 invoked by uid 1010); 28 May 2007 15:33:41 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 11275 invoked from network); 28 May 2007 15:33:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 May 2007 15:33:41 -0000 Authentication-Results: pb1.pair.com smtp.mail=kingwez@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=kingwez@gmail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.166.181 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: kingwez@gmail.com X-Host-Fingerprint: 64.233.166.181 py-out-1112.google.com Linux 2.4/2.6 Received: from [64.233.166.181] ([64.233.166.181:13206] helo=py-out-1112.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 20/3E-47763-456FA564 for ; Mon, 28 May 2007 11:33:41 -0400 Received: by py-out-1112.google.com with SMTP id a25so2831894pyi for ; Mon, 28 May 2007 08:33:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Rk2JWVUr4PY2hj9o4ujUUpFoNfl9anMZ+ve6oAVUL2ct0NfAyXgAxtawwUI5VoV6RK6YBBavqE+lCzrhiEjqXj7a6j0yHBpYNoM9E2AJWJJ301XWLgx4gOI5DVnU/Xqx0xXycuOfISCj6JqCmzAfFQFflk5myXUr4PhhwdChmf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=duF7bfPMMJyXJPM9oUPo0TvKx3kzu6LNPLvfGyoeDQjYS81/oGcmRM5e5c8uu77dNetHNQZj9KE6lGuzn/GIkRQXuIFHE1pGFPzMjU12pky9e1+c9P+iVzzeFwKFudQLJBq9MprPK3TAz/88NZ9OtFNAZrS79MUpv95K/5x2CZc= Received: by 10.35.63.2 with SMTP id q2mr8388102pyk.1180366417686; Mon, 28 May 2007 08:33:37 -0700 (PDT) Received: by 10.35.108.15 with HTTP; Mon, 28 May 2007 08:33:37 -0700 (PDT) Message-ID: <4e89b4260705280833t34f8fa53k6ad6527d5a215275@mail.gmail.com> Date: Mon, 28 May 2007 11:33:37 -0400 To: "PHP internals" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: RFC: adding a callback for determining if a method is static From: kingwez@gmail.com ("Wez Furlong") Hello, This weekend I've been building an Objective-C runtime bridge for PHP. This is somewhat like the COM extension in that it is possible to dynamically interrogate the Objective-C runtime to determine all the interfaces (known as protocols) and classes and map those into PHP. (it's also possible to go the other way, but that's not relevant to my topic here). Now, Objective-C allows one to enumerate static methods defined on interfaces, but not in classes. Furthermore, there is something vaguely akin to our __call mechanism that allows classes and instances to magically handle methods without explicitly defining them in the class description. What I'd like to be able to do is this: $NSApp = NSApplication::sharedApplication(); but the sharedApplication() static method doesn't appear in the enumerated list of methods in the runtime, so I can't simply add it to my function table when I register the NSApplication class. So what I need to do is this to work around the issue: $NSApp = NSApplication::__staticInvoke('sharedApplication'); This can ask the runtime if "sharedApplication" is a static method and invoke it appropriately. This wouldn't be especially bad if it was only for one or two classes that were no often used, but it crops up a lot. I'd like to see an additional callback in the zend_class_entry that operates similarly to the existing get_method callback, but that takes the zend_class_entry instead of the object pointer as its parameter. That would enable more natural syntax for this application, and likely other bridging extensions too. Thoughts? --Wez.