On 9/5/13 3:32 AM, Pierre Joye wrote:
On Thu, Sep 5, 2013 at 11:34 AM, Nikita Popov nikita@gmail.com wrote:
On Thu, Sep 5, 2013 at 10:51 AM, Pierre Joye pierre@gmail.com wrote:
On Thu, Sep 5, 2013 at 10:23 AM, Sebastian Krebs krebs@gmail.com
wrote:
That being said, there is
2013/9/3 Levi Morrison morrison.l...@gmail.com
On Tue, Sep 3, 2013 at 10:54 AM, Pierre Joye pierre@gmail.com wrote:
On Tue, Sep 3, 2013 at 6:04 PM, Levi Morrison morrison.l...@gmail.com
wrote:
In which case we have very different ideas about what good design
is and would never
On Thu, Sep 5, 2013 at 10:23 AM, Sebastian Krebs krebs@gmail.com 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
On Thu, Sep 5, 2013 at 10:51 AM, Pierre Joye pierre@gmail.com wrote:
On Thu, Sep 5, 2013 at 10:23 AM, Sebastian Krebs krebs@gmail.com
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
On Thu, Sep 5, 2013 at 11:34 AM, Nikita Popov nikita@gmail.com wrote:
On Thu, Sep 5, 2013 at 10:51 AM, Pierre Joye pierre@gmail.com wrote:
On Thu, Sep 5, 2013 at 10:23 AM, Sebastian Krebs krebs@gmail.com
wrote:
That being said, there is always a point in a RFC discussion where
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 you
On Tue, Sep 3, 2013 at 10:54 AM, Pierre Joye pierre@gmail.com wrote:
On Tue, Sep 3, 2013 at 6:04 PM, Levi Morrison morrison.l...@gmail.com
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
On Tue, Sep 3, 2013 at 6:04 PM, Levi Morrison morrison.l...@gmail.com 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
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 explicit
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 using
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 to specify
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 would be to
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
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.
Stas,
On Mon, Sep 2, 2013 at 4:02 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
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
hi!
On Tue, Sep 3, 2013 at 12:17 AM, Stas Malyshev smalys...@sugarcrm.com 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
On Sat, Aug 31, 2013 at 11:57 PM, Vartolomei Nicolae
nvartolo...@gmail.comwrote:
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
On Sun, Sep 1, 2013 at 1:11 AM, Anthony Ferrara ircmax...@gmail.com 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
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
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 {
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,
2013/8/31 Vartolomei Nicolae nvartolo...@gmail.com
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
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
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 example of
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
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
On Sun, Sep 1, 2013 at 12:36 AM, Vartolomei Nicolae
nvartolo...@gmail.com 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
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
On Sun, Sep 1, 2013 at 12:36 AM, Vartolomei Nicolae
nvartolo...@gmail.comwrote:
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
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
31 matches
Mail list logo
