On Mon, Jul 18, 2016 at 9:55 AM, Nikita Popov wrote:
>
> A relaxed variant would only invoke the autoloader once for each
> call, assuming that a function that is not loadable at one time will never
> become loadable (which is of course a significant restriction). The former
> variant would be pr
On 18/07/2016 16:04, Michał Brzuchalski wrote:
I was thinking on passing some context information into autoload about
context, eg.: class | funtion. Wouldn't it be satisfiable information
for autoloader?
IMHO it would be the easiest way to satisfy autoloader to find
proprietary implementation.
18 lip 2016 15:58 "Rowan Collins" napisał(a):
>
> On 18/07/2016 01:50, Stanislav Malyshev wrote:
>>
>> Hi!
>>
>>> How about an alternative approach where a function inside a namespace
>>> can be autoloaded using the existing callback, by using a reserved
>>> namespace segment? So to autoload funct
On 18/07/2016 01:50, Stanislav Malyshev wrote:
Hi!
How about an alternative approach where a function inside a namespace
can be autoloaded using the existing callback, by using a reserved
namespace segment? So to autoload function "foo\bar()", the engine would
construct a string like "__functio
On Mon, Jul 18, 2016 at 4:53 AM, Nikita Popov wrote:
>
> Option B: foo() in namespace Bar will
> a) Check if Bar\foo() exists
> b) Otherwise check if foo() exists
> c) Otherwise try to load 'Bar\foo'
> d) Otherwise try to load 'foo'
> e) If all fails, throw.
>
> This avoids the autoloading overhe
Hi!
> How about an alternative approach where a function inside a namespace
> can be autoloaded using the existing callback, by using a reserved
> namespace segment? So to autoload function "foo\bar()", the engine would
> construct a string like "__function\foo\bar" or "foo\__function\bar",
> and
>> I think a better option is to try to solve this in 8 by unifying how
>> functions and classes (and interfaces and traits) work in namespaces.
>> Ideally the lookup behavior should be the same and all that differs
>> are the symbol tables being looked in.
>
>
> Are you suggesting that we require
On Mon, Jul 18, 2016 at 1:28 AM, Levi Morrison wrote:
> > I don't think this is realistic.
>
> I'll come back to this one in a moment.
>
> > As such:
> >
> > Option B: foo() in namespace Bar will
> > a) Check if Bar\foo() exists
> > b) Otherwise check if foo() exists
> > c) Otherwise try to load
> I don't think this is realistic.
I'll come back to this one in a moment.
> As such:
>
> Option B: foo() in namespace Bar will
> a) Check if Bar\foo() exists
> b) Otherwise check if foo() exists
> c) Otherwise try to load 'Bar\foo'
> d) Otherwise try to load 'foo'
> e) If all fails, throw.
>
> T
On Sun, Jul 17, 2016 at 8:21 PM, Rowan Collins
wrote:
> Hi All,
>
> In the discussion of escaping mechanisms, it's once again come up that
> functions lack autoloading, and thus are hard to work with in larger code
> bases.
>
> Previous solutions to this, most notably Anthony Ferrara's very thoro
Hi All,
In the discussion of escaping mechanisms, it's once again come up that
functions lack autoloading, and thus are hard to work with in larger
code bases.
Previous solutions to this, most notably Anthony Ferrara's very thorough
RFC [1], have looked at adding new modes for the existing a
11 matches
Mail list logo
