Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54656
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.42 as permitted sender)
MIME-Version: 1.0
Sender: ekneuss@gmail.com
In-Reply-To: <4E4C3D7D.3040606@googlemail.com>
References: <CAH-PCH5YvyBWfKomU0RaJw2E-GVqPXOV2TZMN9EURfQvYxu54w@mail.gmail.com>
	<4E4C3D7D.3040606@googlemail.com>
Date: Thu, 18 Aug 2011 00:20:11 +0200
Message-ID: <CACQesk4ebuN9Tpz0hYVSerS+=w663vsuUbyn8q0Yvp5NDkxncg@mail.gmail.com>
To: Sebastian Krebs <krebs.seb@googlemail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload*
From: colder@php.net (Etienne Kneuss)

Hi,

On Thu, Aug 18, 2011 at 00:15, Sebastian Krebs <krebs.seb@googlemail.com> wrote:
> Hi,
>
> With this mail I don't want to talk to anyone directly, but I just want to
> summarize the situation as far as I understand.
>
>
> ---
> - Autoloading constants
> ---
> No problem here: When the loading procedure fails, it gets converted to a
> string like before. It may be a performance impact, but the code, that
> relies on this "feature" gets flooded with warnings anyway.
>
>
>
> ---
> - Autoloading functions
> ---
> If I understood it right the only problem is, that *someFunction()* may be
> in the global, as well as in the current namespace. This means, the
> developer write a function in a namespace, that already exists in the global
> scope, which remains to feel quite scary to me. Its way more confusing, that
> (e.g.) *strpos()* don't behave, like expected and learned for years now.
>
> It will affect only single namespaces, because if you want to call a
> function from another namespace you must prefix it with a qualified or
> full-qualified namespace anyway.
> And last but not least: Currently you must include the files containing the
> functions yourself. This means, that existing code is _not_ affected,
> because as long as no one removes the include-statements, it even not call
> any autoloading. But when the developers decides to remove them, they
> probably wants to use the autoloading, what means, that they (hopefully)
> understand, how it works.
>
> However, in my opinion the important part is to just make a decision the
> sooner, the better, as long as there are not too much creepy code out there
> (I don't know any and I can't imagine, that there is). Because functions
> with namespace are quite unhandy without autoloading and I don't think, that
> there is much use of it.
>
> So the 2 possible solutions:
>
> 1:
> - test namespace
> - test global
> - load namespace
> - load global
>
> 2:
> - test namespace
> - load namespace
> - test global
> - load global
>
>
Also:

4:

- test namespace
- test global
- load namespace

> Maybe
> 3:
> - test namespace
> - test global
> - load global
> - load namespace
> would be a solution too, but it seems a little bit curious, when I use
> namespaces, but it looks into the global scope first.
>
> Regards,
> Sebastian
>
> Am 06.08.2011 13:15, schrieb Ferenc Kovacs:
>>
>> Hi.
>>
>> I would like to introduce this RFC which would provide function
>> autoloading through the spl_autoload facility without userland BC
>> breakage.
>>
>> https://wiki.php.net/rfc/autofunc
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Etienne Kneuss
http://www.colder.ch