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
On Sat, Aug 31, 2013 at 11:57 PM, Vartolomei Nicolae
wrote:
> On Saturday, August 31, 2013 at 9:03 PM, Sebastian Krebs wrote:
>
> > I already _have_ create files for functions of a namespace... Closed
> source.
> Can we take a look at them as an example? Maybe we can give you some advice
> how to
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?
>
>
yes,
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
> 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?
kindly,
nvartolomei
--
PHP Internals - PHP Runtime Development Mail
> > 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
On Saturday, August 31, 2013 at 9:03 PM, Sebastian Krebs wrote:
> I already _have_ create files for functions of a namespace... Closed source.
Can we take a look at them as an example? Maybe we can give you some advice
how to refactor this code :)
> Not everything can be found in the 5 most popul
2013/8/31 Vartolomei Nicolae
> So you say you will create a file for every function you want to support
> autoloading?
>
I already _have_ create files for functions of a namespace... Closed
source.
> As I already asked, tell us about realworld use case, for example where
> this could improve s
So you say you will create a file for every function you want to support
autoloading?
As I already asked, tell us about realworld use case, for example where this
could improve say big projects like Symfony or ZF.
There is no logic to add this functionality just because we can.
kindly,
nvartol
Luna Kid wrote:
[snip]
(I bet anyone a dead rat that *lots* of authors of simple
plugin-based designs (not needing real OOP stuff) would
welcome function autoloading. In fact, many of us, I'm sure,
had wondered cluelessly about how to do it with __autoload,
before wondering cluelessly about why wa
31 matches
Mail list logo
