On 9/5/13 3:32 AM, Pierre Joye wrote:
On Thu, Sep 5, 2013 at 11:34 AM, Nikita Popov wrote:
On Thu, Sep 5, 2013 at 10:51 AM, Pierre Joye wrote:
On Thu, Sep 5, 2013 at 10:23 AM, Sebastian Krebs
wrote:
That being said, there is always a point in a RFC discussion where
there is nothing left
On Thu, Sep 5, 2013 at 11:34 AM, Nikita Popov wrote:
> On Thu, Sep 5, 2013 at 10:51 AM, Pierre Joye wrote:
>>
>> On Thu, Sep 5, 2013 at 10:23 AM, Sebastian Krebs
>> wrote:
>>
>> >> > That being said, there is always a point in a RFC discussion where
>> >> > there is nothing left to discuss or ar
On Thu, Sep 5, 2013 at 10:51 AM, Pierre Joye wrote:
> On Thu, Sep 5, 2013 at 10:23 AM, Sebastian Krebs
> wrote:
>
> >> > That being said, there is always a point in a RFC discussion where
> >> > there is nothing left to discuss or argue about, we are so far with
> >> > this one.
> >>
> >>
> >> W
On Thu, Sep 5, 2013 at 10:23 AM, Sebastian Krebs wrote:
>> > That being said, there is always a point in a RFC discussion where
>> > there is nothing left to discuss or argue about, we are so far with
>> > this one.
>>
>>
>> We've been at this point for a while; no new arguments have been raised
2013/9/3 Levi Morrison
> On Tue, Sep 3, 2013 at 10:54 AM, Pierre Joye wrote:
>
> > On Tue, Sep 3, 2013 at 6:04 PM, Levi Morrison
> > wrote:
> > >> In which case we have very different ideas about what good design
> > >> is and would never come to any agreement on that.
> > >
> > >
> > > This is
On Tue, Sep 3, 2013 at 6:04 PM, Levi Morrison wrote:
>> In which case we have very different ideas about what good design
>> is and would never come to any agreement on that.
>
>
> This is already evident in ALL of your recent "discussions" on this ML. Go
> and look: you are the most active partic
On Tue, Sep 3, 2013 at 10:54 AM, Pierre Joye wrote:
> On Tue, Sep 3, 2013 at 6:04 PM, Levi Morrison
> wrote:
> >> In which case we have very different ideas about what good design
> >> is and would never come to any agreement on that.
> >
> >
> > This is already evident in ALL of your recent "di
> In which case we have very different ideas about what good design
> is and would never come to any agreement on that.
This is already evident in ALL of your recent "discussions" on this ML. Go
and look: you are the most active participant in each topic and you are
bickering in each one. Could y
hi!
On Tue, Sep 3, 2013 at 12:17 AM, Stas Malyshev wrote:
> Hi!
>
At this point I would suggest to put the summary of the pros and cons
described (in a more or less exhaustive way) in the RFC and go for the
vote. Maybe double checks if there are any BC related issues that need
to be addressed as
Hi!
> So what your saying, if I understand you correctly, is that PHP was
> intentionally designed to be non-deterministic? And it was designed that
> way to save a single character?
It is deterministic, there are rules for it, described in
http://us1.php.net/manual/en/language.namespaces.fallbac
Stas,
On Mon, Sep 2, 2013 at 4:02 PM, Stas Malyshev wrote:
> Hi!
>
> > So the only case this effects is that you can't autoload a function from
> > the same namespace that you're currently in without explicitly using
> > that function.
> >
> > That's not such a huge issue.
>
> I think it is such
Hi!
> The function names might look like this:
> - spl_register_autoloader -> autoloader for everything
Given we already have spl_autoload_register that'd be pretty confusing.
Also, we usually name functions in increasing order of specificity (i.e.
spl_autoload_call/spl_autoload_spl_autoload_func
Hi!
> So the only case this effects is that you can't autoload a function from
> the same namespace that you're currently in without explicitly using
> that function.
>
> That's not such a huge issue.
I think it is such a huge issue, because this means this functionality
can not be used for rel
Nicolas,
namespace foo {
>> something(); // autoloaded as "something"
>> }
>>
>
> That makes sense *for me* for many reasons, but IMHO that's too confusing
> for a wider adoption.
> Because this doesn't work for function foo\strlen, the only reasonable way
> to work with such an autoloader wo
Stas,
> namespace foo {
> > use function biz\buz;
> > use foo\bar;
> >
> > something(); // autoloaded as "something"
>
> Wait, so it wouldn't work like class autoloader, using fully qualified
> name? And autoloader would not then have any information about
> namespaces, so you'd have t
>
> namespace foo {
> something(); // autoloaded as "something"
> }
>
That makes sense *for me* for many reasons, but IMHO that's too confusing
for a wider adoption.
Because this doesn't work for function foo\strlen, the only reasonable way
to work with such an autoloader would be to avoid us
Hi!
> namespace foo {
> use function biz\buz;
> use foo\bar;
>
> something(); // autoloaded as "something"
Wait, so it wouldn't work like class autoloader, using fully qualified
name? And autoloader would not then have any information about
namespaces, so you'd have to specify explic
Nicolas,
On Sun, Sep 1, 2013 at 11:27 AM, Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
> My previous message didn't push the point I wanted raise: don't we have a
> major problem related to at-run-time namespace resolution for functions and
> constants?
>
> Take this code: namespace foo
My previous message didn't push the point I wanted raise: don't we have a
major problem related to at-run-time namespace resolution for functions and
constants?
Take this code: namespace foo { strlen("bar"); }
Will you trigger an autoload for foo\strlen?
I believe not because that would hurt perf
On Sun, Sep 1, 2013 at 1:11 AM, Anthony Ferrara wrote:
> All,
>
> There has been a lot of discussion unto the merit of this feature. That's
> fine.
>
> What I'd really like to know before proposing this is what can be improved
> in this RFC.
>
> For example: someone (Stas) brought up that it was w
All,
There has been a lot of discussion unto the merit of this feature. That's
fine.
What I'd really like to know before proposing this is what can be improved
in this RFC.
For example: someone (Stas) brought up that it was weird that all three
types (Class, Function, Constant) are served by a s
On Sun, Sep 1, 2013 at 12:36 AM, Vartolomei Nicolae
wrote:
>> personally Ithink it would be nice if we could provide a way for
>> const/function autoloading.
> So you will create files for constants? One file with a single line defining
> a constant?
>
> Did I understood something wrong?
>
> kin
Python packages often place convenience functions (e.g., factory methods) in
__init__.py files. There's nothing wrong with that. It would be great to be
able to do something similar in PHP. Sure beats creating classes called Util.
Thanks,
Michael
On Aug 31, 2013, at 2:57 PM, Vartolomei Nicolae
> > The lack of logic is: Why is it actually missing?
> Why humans don’t have one leg more, on head?
>
> I really want to look at an example for this. Looks like you are the only
> one who needs this.
>
> Oh, is OOP that bad for you? Also constant autoloading looks so bad, I
> want to see an exampl
24 matches
Mail list logo
