Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54616
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+Y0-p9k=8xytDq4t_20ebgE_wv2Nnn4mUpPaYM-1UFBNkCfkg@mail.gmail.com>
References: <CAH-PCH5YvyBWfKomU0RaJw2E-GVqPXOV2TZMN9EURfQvYxu54w@mail.gmail.com>
	<alpine.DEB.2.02.1108141452460.4043@whisky>
	<CAF+90c-g8PLVvP2NYMbQcGCjNmPGN7tHdk5B8FpLp6JGik8tYQ@mail.gmail.com>
	<4E481136.3090508@sugarcrm.com>
	<4E483284.4010100@googlemail.com>
	<4E4838E1.3000006@sugarcrm.com>
	<4E48430D.6070409@googlemail.com>
	<4E486A50.4010700@sugarcrm.com>
	<4E48A22E.1040900@googlemail.com>
	<4E48AD3E.6010801@sugarcrm.com>
	<CA+Y0-p8JijO1Dhsqatp7yR+WR0v=V7rQHboPJmHXNFLWVWWGGw@mail.gmail.com>
	<4E48C126.50707@sugarcrm.com>
	<CA+Y0-p9k=8xytDq4t_20ebgE_wv2Nnn4mUpPaYM-1UFBNkCfkg@mail.gmail.com>
Date: Mon, 15 Aug 2011 09:54:06 +0200
Message-ID: <CAH-PCH4TiMyQOkVGWRRpnezCBeZfJdL2CfLkKec4hsaQ=s79uQ@mail.gmail.com>
To: Sebastian Krebs <krebs.seb@googlemail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload*
From: tyra3l@gmail.com (Ferenc Kovacs)

On Mon, Aug 15, 2011 at 9:15 AM, Sebastian Krebs
<krebs.seb@googlemail.com> wrote:
> 2011/8/15 Stas Malyshev <smalyshev@sugarcrm.com>
>
>> Hi!
>>
>>
>> On 8/14/11 11:21 PM, Sebastian Krebs wrote:
>>
>>> I already made an suggestion [1], that bypass this.
>>>
>>
>> That suggestion means you can not autoload namespaced function that
>> overrides global function. Major WTF.
>
>
> Imo overriding built-in functions is a WTF... Confusing others by changin=
g
> the behaviour of well-known functions just sounds scary.
>

Stas was referring to the fact that namespaces already provides this
kind of monkey-patching, of course this won't work language constructs
(which is a big wtf for most users in it's own way).

> However, when you really want to do this, than you can load your function=
s
> like before
>
>
>> Also leads to two autoload calls (one most probably resulting in exhaust=
ive
>> include path search) when autoloading a non-namespaced function. Pretty =
bad
>> idea IMO.

my idea was something similar what Sebastian suggested, to call the
autoloader twice, but now I think that the best way would be to:
1, we check that the function exists in the current namespace
2, call the autoload callbacks with the absolute name (foo\bar\baz).
3, we check that the function exists in the global namespace

this would of course mean that for every occasion when you forgot to
put the \ for your global function calls your autoloader gets called,
but that's a bad practice, and I really hope that the namespace
fallback will be deprecated/removed in future versions.
it had a nice promise: you can use namespaces without rewriting your
whole application, but with the current implementation, thats simply
not true_
- you have to put your namespace declaration into every file, included
files won't inherit that.
- you can't use the classname type constructors in namespaced code.

so this is a valid concern, but I still think that the people who
would use this feature could still live with either of the proposed
solutions.
I know that the bad decisions in the past won't count in this
argument, but the current "namespace resolution falls back to the
global namespace" is the one to blame for this shortcoming.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu