Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54575
Return-Path: <krebs.seb@googlemail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 64265 invoked from network); 14 Aug 2011 12:31:07 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 14 Aug 2011 12:31:07 -0000
Received: from [127.0.0.1] ([127.0.0.1:7276])
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ECSTREAM
	id 12/81-50938-A00C74E4 for <internals@lists.php.net>; Sun, 14 Aug 2011 08:31:06 -0400
Authentication-Results: pb1.pair.com smtp.mail=krebs.seb@googlemail.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=sebastian.krebs.berlin@googlemail.com; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.214.42 as permitted sender)
X-PHP-List-Original-Sender: krebs.seb@googlemail.com
X-Host-Fingerprint: 209.85.214.42 mail-bw0-f42.google.com  
Received: from [209.85.214.42] ([209.85.214.42:60366] helo=mail-bw0-f42.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 98/71-50938-C2AB74E4 for <internals@lists.php.net>; Sun, 14 Aug 2011 08:06:05 -0400
Received: by bkd19 with SMTP id 19so2604079bkd.29
        for <internals@lists.php.net>; Sun, 14 Aug 2011 05:06:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=gamma;
        h=sender:message-id:date:from:user-agent:mime-version:to:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        bh=jRddgOrgCQOlT+jBj2jEi+OF8b4RadoyGLJaqh5stdA=;
        b=SHVmFNvHcdPA4yzshjl80v96D7Yjb0uqXlAkyCdSeBOMziDeZqBipVgNcMYqQ5eBDK
         EKqp045QVqoSLso0UjIJdlayC/ZFiZOgj+w4dkMaHi+vf+od6pbVRPyRJ8urhhx2STNT
         XyyCrt7Rt2nUjFFnYZ+2RXKjEkLVL/pWMfw5w=
Received: by 10.205.23.208 with SMTP id rb16mr169323bkb.297.1313323561198;
        Sun, 14 Aug 2011 05:06:01 -0700 (PDT)
Received: from [192.168.24.2] (91-64-205-130-dynip.superkabel.de [91.64.205.130])
        by mx.google.com with ESMTPS id y2sm1268126bkd.19.2011.08.14.05.06.00
        (version=SSLv3 cipher=OTHER);
        Sun, 14 Aug 2011 05:06:00 -0700 (PDT)
Sender: Sebastian Krebs <sebastian.krebs.berlin@googlemail.com>
Message-ID: <4E47BA28.1090609@googlemail.com>
Date: Sun, 14 Aug 2011 14:06:00 +0200
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAH-PCH5YvyBWfKomU0RaJw2E-GVqPXOV2TZMN9EURfQvYxu54w@mail.gmail.com> <4E3D3275.9020903@rotorised.com> <CAH-PCH6L_vqg5La_wBOQAbv-=1mm2PAS9s04J342dWPmaT283w@mail.gmail.com> <CA+Y0-p_quLJ6Lh=jQwhBxBGxGk66wLQ=s2PM8ukEtDy7MKB7Pw@mail.gmail.com> <CAH-PCH4OjJm3_kiz9+j2nLUnuHWujD6Pfw-zkSfTMCbxcAB2NA@mail.gmail.com> <CAM4sM9EZmpXQ8pWTo4x+UemUbDctwc5eSBPamUhaoix7kC86xQ@mail.gmail.com>
In-Reply-To: <CAM4sM9EZmpXQ8pWTo4x+UemUbDctwc5eSBPamUhaoix7kC86xQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload*
From: krebs.seb@googlemail.com (Sebastian Krebs)



Am 12.08.2011 15:54, schrieb Jan Dolecek:
> Someone said that it won't be that easy, because functions are
> searched within a namespace first and when they don't exist there,
> then are called from global namespace.
>
> Example:
> <?php
> namespace example;
> echo substr('Test', 1, 1);
>
> When calling function substr, Zend engine first tries to find function
> example\substr. If such function doesn't exist, it tries just substr
> which is found and called. Thanks to this lookup, we don't need to
> escape all function calls with backslash prefix.
>
> <?php
> echo not_found(1);
> When trying to autoload a function, which one should be auto loaded?
> "example\not_found" or "not_found"?

Whats about "both"?

- Does <namespace>\<function> exists?
- Does \<function> exists?

Till here everything is like usual

- Try to load <namespace>\<function>. Does <namespace>\<function> exists?
- Try to load \<function>. Does \<function> exists?


I make two additional assumptions:

1. Like PSR-0 developers may get used to put their functions into 
namespaces, thus custom functions usually get loaded in the first 
"autoload-step"
2. I don't think anybody will use one-function-per-file, thus (lets say) 
every function from one namespace is loaded at once.


> Similar situation is with constants, because of BC a non-existing
> constant must result in string with the same value as constant's name.
> <?php
> var_dump(MY_CONSTANT); // string(11) "MY_CONSTANT"
>
> Some programmes rely on it (though it's not recommended) and calling
> autoloader everytime would add significant load to such apps.

In my opinion code, that _relies_ on this should be treated as 
"unstable" anyway. I don't think it's very useful to take care of bad 
habits and also I don't think it's useful to accept/decline 
features/enhancements, because there are convenience/fallback-features, 
that were _never_ recommended. Also it's even not a bc-break, because it 
works. And however: There is a very easy workaround:

| define('MY_CONSTANT', 'MY_CONSTANT');

;)

>
>
> Jan Dolecek
> juzna.cz@gmail.com
>
>
>
> On Fri, Aug 12, 2011 at 11:31 AM, Ferenc Kovacs<tyra3l@gmail.com>  wrote:
>> On Fri, Aug 12, 2011 at 12:12 PM, Sebastian Krebs
>> <krebs.seb@googlemail.com>  wrote:
>>> Hi,
>>>
>>> 2011/8/12 Ferenc Kovacs<tyra3l@gmail.com>
>>>
>>>> On Sat, Aug 6, 2011 at 2:24 PM, Ryan McCue<lists@rotorised.com>  wrote:
>>>>> Ferenc Kovacs wrote:
>>>>>> I would like to introduce this RFC which would provide function
>>>>>> autoloading through the spl_autoload facility without userland BC
>>>>>> breakage.
>>>>>
>>>>> Shouldn't the default type be T_CLASS|T_INTERFACE?
>>>>>
>>>>
>>>> sorry for the late reply.
>>>> judging from your reply and the conversion on irc with Etienne, I
>>>> think that the usage of the token constants are ambiguous(we have
>>>> different token constants for classes and interfaces as you mentioned
>>>> for example).
>>>> originally I chose this because this would be fully backward
>>>> compatible, but now I think that we should add new constants.
>>>> what do you think?
>>>>
>>>
>>>  From the users point of view I don't care. It's just another constant. Also
>>> constants like
>>>
>>> SPL_AUTOLOAD_CLASS
>>> SPL_AUTOLOAD_FUNCTION
>>> SPL_AUTOLOAD_CONSTANT
>>>
>>> seems to be more obvious, because it reflects, that it belongs to
>>> spl-autoload.
>>>
>>
>> imo from the users point of view your suggested constant names are
>> much better, plus the T_* constants are provided by the tokenizer
>> extension, which AFAK could be disabled compilation time, and by
>> itself would be a bad idea to couple the two extension.
>>
>> so +1 for your suggestion, I will update the RFC, and check out how
>> hard would be to create a patch.
>>
>> --
>> Ferenc Kovács
>> @Tyr43l - http://tyrael.hu
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>