On Sep 9, 2008, at 6:22 PM, Stanislav Malyshev wrote:
if we cannot
We already have this serious flaw in our design. If we use "new Foo
()", and it's definition not included, it resolves differently
(namely, to fatal error) than if we had included the definition.
Also, with inheritanc
On 10.09.2008, at 03:22, Stanislav Malyshev wrote:
I disagree. The idea is that I get control over how I manage to
global namespace. As such its sensible that I want to use "mysql"
in my code instead of DB::mysql.
You may use it. You just won't get wildcard imports, because that
doesn't
On Tuesday 09 September 2008 8:22:37 pm Stanislav Malyshev wrote:
> > I think that PHP is not an OO language and as such there is no reason to
>
> Namespaces is an OO feature, however.
How is the concept of namespaces inherently linked to the use of explicitly
defined classes and instances? Re
Hi!
I disagree. The idea is that I get control over how I manage to global
namespace. As such its sensible that I want to use "mysql" in my code
instead of DB::mysql.
You may use it. You just won't get wildcard imports, because that
doesn't work conceptually.
Also when it comes to resoluti
Taking off my RM hat here. So my comments are those as joe smoe user,
who hasnt written namespaced code, but who has been reading all the
criticism people have posted (interestingly I have seen very few
people that are entirely happy .. of course people complain louder
than they praise .. s
On Monday 08 September 2008 1:45:35 pm Lukas Kahwe Smith wrote:
> On 08.09.2008, at 19:53, Dmitry Stogov wrote:
> > The main PHP namespaces ideas come from Java packages and Java classes
> > have to write these "use" statements in the same way. It's not the end
> > of the world. I believe that well
Hello Stanislav,
Monday, September 8, 2008, 9:23:09 PM, you wrote:
> Hi!
>> initial hard work of trying to do something new). Especially in this
>> sense I would recommend all people on this list to make sure they use
>> language that encourages people from coming out of the shadows on this
>
Hi!
And I'd ask - who wants to do new DB::mysql when they can just do mysql?
I do. Because this way I don't have to worry my mysql would clash with
someone other's mysql, and I can have all DB related stuff under one roof.
It can't clash if you don't "use" someone other's mysql namespace, o
Hi!
And I'd ask - who wants to do new DB::mysql when they can just do mysql?
I do. Because this way I don't have to worry my mysql would clash with
someone other's mysql, and I can have all DB related stuff under one roof.
The common usage of use is going to be to get the name as short a
Stanislav Malyshev wrote:
> Hi!
>
> I answered this exactly question about 100 times already. No, you just
> import DB and then do DB::Class1, DB::Class2 etc. up to DB::Class18.
> Does nobody ever read anything prior to starting discussing namespaces?
And I'd ask - who wants to do new DB::mysql w
As you said before - how is it any different from just being able to
call escape("foo") or display("foo"); It's a matter of taste. To me
that is not anymore of a meaningful name - just a different syntax and
not one your average wordpress user would know how to handle.
Well, if it's just a matt
Hi!
I suspect even ZF will run into some kind of import * functionality
being needed. Do you really want to tell a user they have to write 18
use statements before using say the DB component? Or for PEAR2? when a
I answered this exactly question about 100 times already. No, you just
import
Stanislav Malyshev wrote:
> Well, I can tell you what's bad for you but I can't stop you from doing
> that :) use * is bad for you, but if you insist on simulating it - well,
> ok, it's your code.
I suspect even ZF will run into some kind of import * functionality
being needed. Do you really wan
Stanislav Malyshev wrote:
> Hi!
>
>> Bottom line, being able to alias in functions the same way you can
>> classes would be useful. You could also shoot yourself in the foot.
>>
>> You can alias in classes. You can shoot yourself in the foot with that
>> as well.
>
> As I already noted in my re
Stanislav Malyshev schreef:
Hi!
Hi,
I'm not going to do this offlist with you,
guns are dangerous yet they are sold by the bucket load. either don't
sell guns or let people decide how to use them, don't sell'em then
dictate
that they can't pull the trigger.
I think it would really help i
Hi!
initial hard work of trying to do something new). Especially in this
sense I would recommend all people on this list to make sure they use
language that encourages people from coming out of the shadows on this
topic, rather than scaring them off.
I can only second that.
But on the other
Hi,
On Sep 8, 2008, at 8:45 PM, Lukas Kahwe Smith wrote:
On 08.09.2008, at 19:53, Dmitry Stogov wrote:
The main PHP namespaces ideas come from Java packages and Java
classes
have to write these "use" statements in the same way. It's not the
end
of the world. I believe that well-designed
Stanislav Malyshev schreef:
Hi!
for the same reason you would want it with classes?? because you can
do it with classes, no? and that seems acceptable to you, no? then
functions
should have the same privilege.
Functions and classes are rather different things. Class represents, as
you know
Stanislav Malyshev wrote:
>> If functions in namespaces won't have the same treatment or features as
>> classes why bother ;)
>
> Functions can't have the same features as classes, because then they'd
> be classes :)
That's not what I meant and you know it (sighs)
Bottom line, being able to al
On Mon, 2008-09-08 at 14:45 -0400, Robert Cummings wrote:
> On Mon, 2008-09-08 at 14:39 -0400, Elizabeth M Smith wrote:
> > Stanislav Malyshev wrote:
> > > Hi!
> > >
> > >> And what happens when you have two libraries and each has their own Date
> > >> implementation? How is that any different? If
On Mon, 2008-09-08 at 14:39 -0400, Elizabeth M Smith wrote:
> Stanislav Malyshev wrote:
> > Hi!
> >
> >> And what happens when you have two libraries and each has their own Date
> >> implementation? How is that any different? If you could alias in
> >> functions, you'd simply alias them in differe
On 08.09.2008, at 19:53, Dmitry Stogov wrote:
The main PHP namespaces ideas come from Java packages and Java classes
have to write these "use" statements in the same way. It's not the end
of the world. I believe that well-designed frameworks won't require a
lot of use statements in user-space c
Hi!
for the same reason you would want it with classes?? because you can
do it with classes, no? and that seems acceptable to you, no? then
functions
should have the same privilege.
Functions and classes are rather different things. Class represents, as
you know, group of data and behavior,
Stanislav Malyshev wrote:
> Hi!
>
>> And what happens when you have two libraries and each has their own Date
>> implementation? How is that any different? If you could alias in
>> functions, you'd simply alias them in differently - call one _() and one
>> new_gettext - that's the point of alias
Elizabeth M Smith schreef:
Stanislav Malyshev wrote:
Hi!
Personally I don't see the point of of having functions in namespaces if
you can't "use" them in a global scope.
You mean, if you can do foo() it has a point but if it's F::foo() it
doesn't? Then I think your point was purely cosmetical
Stanislav Malyshev schreef:
Hi!
This doesn't work at all
The closest you can do is
That's the right way to go. If you want functions in global space, put
them there. If not, then use namespace syntax. BTW, what is so bad in
F::myfunction that it makes it absolutely useless?
because it r
Stanislav Malyshev wrote:
> Hi!
>
>> For me they are ways to "package up" code without interfering with built
>> in PHP functions or other libraries I wish to use.
>
> Right, I agree.
>
>> I don't want to retrain myself or others to call all functions in my
>> code as though they were static met
Hi!
What is YOUR suggestion? Just tell us how hilarious it is to type "::"
and introduce all the other problems anyway.
Use short class name in 95% of the cases where it is unambiguous (i.e.
there's no class name in this namespace which collides with internal
class name). Use "use ::Foo" or
Stanislav Malyshev wrote:
> Hi!
>
>> Personally I don't see the point of of having functions in namespaces if
>> you can't "use" them in a global scope.
>
> You mean, if you can do foo() it has a point but if it's F::foo() it
> doesn't? Then I think your point was purely cosmetical from the start
Hi!
This doesn't work at all
The closest you can do is
That's the right way to go. If you want functions in global space, put
them there. If not, then use namespace syntax. BTW, what is so bad in
F::myfunction that it makes it absolutely useless?
which kind of defeats the purpose of hav
[some comments below]
Lukas Kahwe Smith wrote:
>
> On 08.09.2008, at 18:52, Stanislav Malyshev wrote:
>
>> Hi!
>>
>>> I think given the feedback from users, we really need to actually
>>> benchmark the performance slow down that Greg's proposed changes will
>>> bring. I also guess there are two
Stanislav Malyshev wrote:
> Hi!
>
>> I am mainly baseing myself on the feedback I got at:
>> http://pooteeweet.org/blog/1288
>
> OK, will read through it.
>
>> I think Liz summarized the gripes best (especially the second
>> paragraph is important to note):
>> "I've been using namespaces since t
Hi!
So I'd say, make it explicit and remove the vague moment.
Do I understand right that you advocate having to use ::Exception each
time you need the internal class?
As I said:
"I heard lots of objections how ugly it is to prepend everything with "::"
(not
that this is the only possibly
Hi!
I am mainly baseing myself on the feedback I got at:
http://pooteeweet.org/blog/1288
OK, will read through it.
I think Liz summarized the gripes best (especially the second paragraph
is important to note):
"I've been using namespaces since then went into 5.3. From my experience
function
Hi!
So I'd say, make it explicit and remove the vague moment.
Do I understand right that you advocate having to use ::Exception each
time you need the internal class?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED
Hi,
I suppose since I use autoload and classes I belong to the first group.
Thing is, we still do care about performance.
I currenly use underscores as some other programmers do, to "fake"
namespaced identifiers, and from my tests and this discussion so far I'm
convinced the namespaces as t
On 08.09.2008, at 18:52, Stanislav Malyshev wrote:
Hi!
I think given the feedback from users, we really need to actually
benchmark the performance slow down that Greg's proposed changes
will bring. I also guess there are two types of users out there:
Could you summarize the feedback?
I
Hi!
I think given the feedback from users, we really need to actually
benchmark the performance slow down that Greg's proposed changes will
bring. I also guess there are two types of users out there:
Could you summarize the feedback?
The slowdown is obvious - exhaustive autoloading search fo
Hello All,
There is no way around it given the feedback I am seeing about
namespace usage in the wild, to warm up this old post again.
This post and the additional commentary, especially about performance
by Stas can be found in the archives at:
http://marc.info/?l=php-internals&m=1215276686
Hi!
b.php:
Here in your proposal exhaustive autoload happens for all cases where
you do not actually override Exception in Foo.
throws a Foo::Exception and echoes "caught", demonstrating the
importance of load order as well.
You could do use Foo::Exception in b.php too, to solve it.
Stanislav Malyshev wrote:
Hi!
Of course its predictable. What Greg meant is "error prone". The
difference is if we want to by default lower the chance of programming
mistakes or ensure maximum performance with little effort for users
with autoload (and long include path lists).
I think sile
Oh sorry, I answered to wrong email :)
I meant "parent::" forwarding patch.
We will try to finalize it with Etienne today.
Thanks. Dmitry.
Lukas Kahwe Smith wrote:
On 22.07.2008, at 08:04, Dmitry Stogov wrote:
Please show me the patch before commit (the last patch I saw wasn't
good enough).
On 22.07.2008, at 08:04, Dmitry Stogov wrote:
Please show me the patch before commit (the last patch I saw wasn't
good enough).
err which patch?
i just suggested to go with the status quo for namespaces in alpha1.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runt
Hi,
Please show me the patch before commit (the last patch I saw wasn't good
enough).
Thanks. Dmitry.
Lukas Kahwe Smith wrote:
On 17.07.2008, at 20:03, Stanislav Malyshev wrote:
Hi!
Greg's argument seems sound to me. With the proposed change errors
are less likely and more transparent i
On 17.07.2008, at 20:03, Stanislav Malyshev wrote:
Hi!
Greg's argument seems sound to me. With the proposed change errors
are less likely and more transparent in case they happen (for
people using
No, they won't be transparent at all. If you use Exception and
forget to put "use ::Excep
Hello Lukas,
Thursday, July 17, 2008, 8:15:52 PM, you wrote:
> On 17.07.2008, at 20:03, Stanislav Malyshev wrote:
>>> autoload that is). At the same time people who care about
>>> performance can still work around this behavior (then again those
>>> that care about optimizations on this lev
Stanislav Malyshev escreveu:
Hi!
Of course its predictable. What Greg meant is "error prone". The
difference is if we want to by default lower the chance of programming
mistakes or ensure maximum performance with little effort for users
with autoload (and long include path lists).
I think s
Hi!
Of course its predictable. What Greg meant is "error prone". The
difference is if we want to by default lower the chance of programming
mistakes or ensure maximum performance with little effort for users with
autoload (and long include path lists).
I think silent performance disaster is
On 17.07.2008, at 19:57, Stanislav Malyshev wrote:
Hi!
In other words, with the current implementation, you can just do
"use Foo::Exception;" and it works, but if you *forget* to do the
use statement, you can get unpredictable behavior with no warning
until your
You get previctable beh
Hi!
There is nothing wrong with autoload. However it adds overhead so if you
want super duper high performance, you use explicit includes/requires
with absolute paths instead.
In most cases, it is not practical - code with autoload in 99.9% of
cases would be more robust, more maintainable an
On 17.07.2008, at 20:03, Stanislav Malyshev wrote:
autoload that is). At the same time people who care about
performance can still work around this behavior (then again those
that care about optimizations on this level probably do not use
autload to begin with).
What's wrong with autoloa
Hi!
Greg's argument seems sound to me. With the proposed change errors are
less likely and more transparent in case they happen (for people using
No, they won't be transparent at all. If you use Exception and forget to
put "use ::Exception" in each and every of your files, you get
exhaustiv
Hi!
In other words, with the current implementation, you can just do "use
Foo::Exception;" and it works, but if you *forget* to do the use
statement, you can get unpredictable behavior with no warning until your
You get previctable behavior in all cases, there's no randomness in the
engine.
On 11.07.2008, at 23:17, Greg Beaver wrote:
Stanislav Malyshev wrote:
Hi!
This fixes the logic problem, and re-introduces the performance
slowdown for internal classes. FORTUNATELY there is a simple
solution to this, which is to "use" all global classes:
The thing is since it'd work wi
Stanislav Malyshev wrote:
Hi!
This fixes the logic problem, and re-introduces the performance
slowdown for internal classes. FORTUNATELY there is a simple
solution to this, which is to "use" all global classes:
The thing is since it'd work without "use", most users would do it
that way and
Hi!
This fixes the logic problem, and re-introduces the performance slowdown
for internal classes. FORTUNATELY there is a simple solution to this,
which is to "use" all global classes:
The thing is since it'd work without "use", most users would do it that
way and have horrible code. But if
Lukas Kahwe Smith wrote:
Aloha,
Since Johannes has been stumped (and therefore not as visible as he
would have hoped) with work and 5.3 CVS is already filled brim with
awesome new features, I have been approached by several people wondering
how we can speed up the process. I have always said
57 matches
Mail list logo
