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
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!
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
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
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
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
42 matches
Mail list logo
