Re: [PHP-DEV] Simple Namespace Proposal
It is possible to use the same namespace in several PHP files. Does this mean that a project like Phorum could declare the same namespace at the top of all of our files and all the code in those files would exist in the same namespace? common.php: list.php: Or, would list.php have to import the Phorum namespace? Also, I don't see any mention of variables in namespaces. Will there be no effect on variables? -- Brian Moon Senior Developer -- http://dealnews.com/ It's good to be cheap =) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Hi Dmitry, it would be great to have namespaces in PHP6, as these always longer-getting classnames are somewhat annoying. I don't want to start a discussion about the separator (I think there was one before), but: > > 6) Calls to qualified functions are resolved at run-time. Call to > > "A::B::foo()" first tries to call function foo() from namespace "A::B", then > > it tries to find class "A::B (__autoload() it if necessary) and call its > > static function foo() If I am not mislead this ambiguity is due to the fact that :: is the namespace separator? If, so I'd rather suggest changing the separator, because one could alter the program's behaviour by adding a function foo() to a namespace thus making PHP call this function instead of the method. Besides, a lot of less experiences programmers would not be sure when which function/method is actually called. > > All class and function names inside are automatically prefixed with > > namespace name. Inside namespace, local name always takes precedence over > > global name. It is possible to use the same namespace in several PHP files. > > The namespace declaration statement must be the very first statement in > > file. I take it that when I include or conditionally include, the included file has its own namespace, if one is declared in that file. What if I do not declare a namespace in an include file? Does this file "inherit" the current namespace or are the contents added to the global namespace? > > point of definition down to the end of file. It is recommended however to > > place imports at the beginning of the file. Import statements have effect > > only on file where they are written. Could this result in name conflicts when including files that have their own import statements? > > 4) calls to unqualified functions that are not defined in current namespace > > are resolved in run-time. The call to function foo() inside namespace (A::B) > > first tries to find and call function from current namespace A::B::foo() and > > if it doesn't exist PHP tries to call internal function foo(). Note that > > using foo() in namespace you can call only internal PHP functions, however > > using ::foo() you are able to call any function from global namespace. Does this mean that a programmer could "override" an internal PHP function, possibly accidentally? Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
> > It is possible to use the same namespace in several PHP files.
>
> Does this mean that a project like Phorum could declare the same
> namespace at the top of all of our files and all the code in
> those files
> would exist in the same namespace?
Exactly.
> common.php:
> namespace Phorum;
>
> $PHORUM = get_settings();
>
> function phorum_build_url(){
> return $url;
> }
> ?>
>
> list.php:
> namespace Phorum;
>
> $url - phorum_build_url();
>
> ?>
>
>
> Or, would list.php have to import the Phorum namespace?
>
> Also, I don't see any mention of variables in namespaces.
> Will there be
> no effect on variables?
Nor variables naither constants.
They are defined in run-time.
Dmitry.
>
> --
>
> Brian Moon
> Senior Developer
> --
> http://dealnews.com/
> It's good to be cheap =)
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Does this mean that a project like Phorum could declare the same
namespace at the top of all of our files and all the code in those files
would exist in the same namespace?
Theoretically, yes, that's the idea. Practically there could be some
problems with variable names - right now the patch does not resolve
names, so if you do $name = "func", $name("foo"); it might not work,
you'd need to use __NAMESPACE__ currently. I'm not sure how much of a
trouble it is.
Or, would list.php have to import the Phorum namespace?
no, no import is necessary for same-namespace references.
Also, I don't see any mention of variables in namespaces. Will there be
no effect on variables?
No namespace variables, right. For grouping variables you have arrays
and classes, should be good enough ;)
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
I take it that when I include or conditionally include, the included file has its own namespace, if one is declared in that file. What if I do not declare a namespace in an include file? Does this file "inherit" the current namespace or are the contents added to the global namespace? No, namespaces are per-file. No namespace means global namespace. Non-local namespaces can be very problematic for bytecode caches since it would not be possible to know "true" names of the classes per-file and actually same file could generate very different names. Could this result in name conflicts when including files that have their own import statements? Note that import defines local (per-file) name transformation. I.e. if you do import Zend::Some::Class as Myclass, it means in this file, once you say Myclass, you actually mean Zend::Some::Class. But it should not have any effects on other files. Does this mean that a programmer could "override" an internal PHP function, possibly accidentally? Yes, it would be possible to "override" internal functions in namespace. I don't think it's too much of a problem - tools can deal with it. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Hi Dmitry, thanks for your clarifications. I like your concept very much, as a PHP user, however, I am a little concerned about some ambiguities your concept introduces. I feel this might be a source of error for many programmers, especially less experienced ones. > In any case you won't use classes and namespaces with the same full names. IMHO this should be a fatal error, at least a warning (something like "potential ambiguity between funtion foo() in namespace a and abstract method foo() in class a". Otherwise adding to an existing program could inadvertedly alter its behaviour. > Right. You can have namespace UTF8 and function strlen() in it. This kind of "overriding" would make an interesting feature! However, if a programmer creates - by coincidence - a method with the name of an built-in PHP function, he alters the program's behaviour; from another point of view, this is something that should be forbidden, as I think it could be a source of hard-to-find errors. Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On 7/5/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote: Hi Dmitry, thanks for your clarifications. I like your concept very much, as a PHP user, however, I am a little concerned about some ambiguities your concept introduces. I feel this might be a source of error for many programmers, especially less experienced ones. Well about time people start learning no ? With good explanations (manual (wink)) I think even the starter could understand this concept. If they could also step on some other concept at the same time that'll give them both more experience and code quality. > In any case you won't use classes and namespaces with the same full names. IMHO this should be a fatal error, at least a warning (something like "potential ambiguity between funtion foo() in namespace a and abstract method foo() in class a". Otherwise adding to an existing program could inadvertedly alter its behaviour. > Right. You can have namespace UTF8 and function strlen() in it. This kind of "overriding" would make an interesting feature! However, if a programmer creates - by coincidence - a method with the name of an built-in PHP function, he alters the program's behaviour; from another point of view, this is something that should be forbidden, as I think it could be a source of hard-to-find errors. I would probably be in favor of throwing a notice or a warning when someone modifies a built-in function (or even throw an exception) and that way as soon as you do such thing you would know right away that you modified something and you would know where the modification happened which would make things much easier for people developing and debugging applications. Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
I think the following example is much better, however I am not sure it's a
right direction. Namespaces are intended to declare names that can conflict
with names from other namespaces (including global namespace), do I am not
sure that we need special keyword for internal functions.
We'll think little bit more. Anyway thank you for feedback and idea.
Thanks. Dmitry.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of David Coallier
> Sent: Thursday, July 05, 2007 5:35 PM
> To: Stefan Priebsch
> Cc: Dmitry Stogov; PHP internals
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
> On 7/5/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> > David Coallier schrieb:
> > > I would probably be in favor of throwing a notice or a
> warning when
> > > someone modifies a built-in function (or even throw an exception)
> > > and that way as soon as you do such thing you would know
> right away
> > > that you modified something and you would know where the
> > > modification happened which would make things much easier
> for people
> > > developing and debugging applications.
> >
> > The problem is that this kind of overloading makes a nice
> feature as
> > well. This is runied by throwing an exception, and cautious
> developers
> > will at least get nervous when they see a notice.
> >
> > I could imagine that by adding something like "overrides foo()" or
> > "overloads foo()" to a function/method declaration the
> developer could
> > make clear that he willingly overrides a built-in function, and if
> > this is missing, an exception is being thrown. This may be a little
> > over the top, however.
> >
>
> Yep I see what you mean.. could even be something like:
>
> namespace UTF8;
>
> overrides {
> strlen();
> strcmp();
> }
>
> function strlen($string)
> {
> return strlen($string) + 666; // This is just an example ! } ...
>
>
> I kinda like the overrides part, however I wonder if people
> will actually use it.. Oh well.. my two cents are now gone.
>
>
> > Kind regards,
> >
> > Stefan
> >
> > --
> > >e-novative> - We make IT work for you.
> >
> > e-novative GmbH - HR: Amtsgericht München HRB 139407
> > Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
> >
> > http://www.e-novative.de
> >
>
>
>
> --
> David Coallier,
> Founder & Software Architect,
> Agora Production (http://agoraproduction.com)
> 51.42.06.70.18
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
David Coallier schrieb: > I would probably be in favor of throwing a notice or a warning when > someone modifies a built-in function (or even throw an exception) and > that way as soon as you do such thing you would know right away that > you modified something and you would know where the modification > happened which would make things much easier for people developing and > debugging applications. The problem is that this kind of overloading makes a nice feature as well. This is runied by throwing an exception, and cautious developers will at least get nervous when they see a notice. I could imagine that by adding something like "overrides foo()" or "overloads foo()" to a function/method declaration the developer could make clear that he willingly overrides a built-in function, and if this is missing, an exception is being thrown. This may be a little over the top, however. Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On 7/5/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
David Coallier schrieb:
> I would probably be in favor of throwing a notice or a warning when
> someone modifies a built-in function (or even throw an exception) and
> that way as soon as you do such thing you would know right away that
> you modified something and you would know where the modification
> happened which would make things much easier for people developing and
> debugging applications.
The problem is that this kind of overloading makes a nice feature as
well. This is runied by throwing an exception, and cautious developers
will at least get nervous when they see a notice.
I could imagine that by adding something like "overrides foo()" or
"overloads foo()" to a function/method declaration the developer could
make clear that he willingly overrides a built-in function, and if this
is missing, an exception is being thrown. This may be a little over the
top, however.
Yep I see what you mean.. could even be something like:
namespace UTF8;
overrides {
strlen();
strcmp();
}
function strlen($string)
{
return strlen($string) + 666; // This is just an example !
}
...
I kinda like the overrides part, however I wonder if people will
actually use it..
Oh well.. my two cents are now gone.
Kind regards,
Stefan
--
>e-novative> - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
As a PHP user also frustrated with lack and namespaces and having lurked here for a while I know there was a prior proposal and many countless, lengthy discussions on separators and all. Have the prior proposals been invalidated? --Tony - Original Message From: Stefan Priebsch <[EMAIL PROTECTED]> To: David Coallier <[EMAIL PROTECTED]> Cc: Dmitry Stogov <[EMAIL PROTECTED]>; PHP internals Sent: Thursday, July 5, 2007 8:26:25 AM Subject: Re: [PHP-DEV] Simple Namespace Proposal David Coallier schrieb: > I would probably be in favor of throwing a notice or a warning when > someone modifies a built-in function (or even throw an exception) and > that way as soon as you do such thing you would know right away that > you modified something and you would know where the modification > happened which would make things much easier for people developing and > debugging applications. The problem is that this kind of overloading makes a nice feature as well. This is runied by throwing an exception, and cautious developers will at least get nervous when they see a notice. I could imagine that by adding something like "overrides foo()" or "overloads foo()" to a function/method declaration the developer could make clear that he willingly overrides a built-in function, and if this is missing, an exception is being thrown. This may be a little over the top, however. Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Dmitry Stogov wrote: I think the following example is much better, however I am not sure it's a right direction. Namespaces are intended to declare names that can conflict with names from other namespaces (including global namespace), do I am not sure that we need special keyword for internal functions. We'll think little bit more. Anyway thank you for feedback and idea. I could live with this. Would this only override built-in functions or any function in the global scope. Or, rather, would you have to do this for all functions in the global scope? If so, I see a new problem. =) If I write my project using name spaces, and have all my functions inside the Phorum namespace and some other project does not use namespaces and has the same function name, my project now throws errors if I do not use overloaded. -- Brian Moon Senior Developer -- http://dealnews.com/ It's good to be cheap =) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
Names in namespace will never conflict with user names in global namespace.
Dmitry.
> -Original Message-
> From: Brian Moon [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 05, 2007 7:24 PM
> To: Dmitry Stogov
> Cc: 'David Coallier'; 'Stefan Priebsch'; 'PHP internals';
> Stanislav Malyshev
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
> Dmitry Stogov wrote:
> > I think the following example is much better, however I am not sure
> > it's a right direction. Namespaces are intended to declare
> names that
> > can conflict with names from other namespaces (including global
> > namespace), do I am not sure that we need special keyword
> for internal
> > functions.
> >
> > We'll think little bit more. Anyway thank you for feedback and idea.
> >
> > > namespace UTF8;
> >
> > overloaded class Exception {
> > }
> >
> > overloaded function strlen() {
> > }
> > ?>
>
> I could live with this. Would this only override built-in
> functions or
> any function in the global scope. Or, rather, would you have
> to do this
> for all functions in the global scope? If so, I see a new
> problem. =)
> If I write my project using name spaces, and have all my functions
> inside the Phorum namespace and some other project does not use
> namespaces and has the same function name, my project now
> throws errors
> if I do not use overloaded.
>
> --
>
> Brian Moon
> Senior Developer
> --
> http://dealnews.com/
> It's good to be cheap =)
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
As a PHP user also frustrated with lack and namespaces and having lurked here for a while I know there was a prior proposal and many countless, lengthy discussions on separators and all. Have the prior proposals been invalidated? I think most prior proposals tried to do too much and got into various complications because of that. As for separators, I still didn't see any idea that made departing from established :: worthwhile. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
I think the following example is much better, however I am not sure it's a right direction. Namespaces are intended to declare names that can conflict with names from other namespaces (including global namespace), do I am not sure that we need special keyword for internal functions. This is something that is bothering me too - should we distinguish between internal functions and just php global functions? If not - we should be aware that when we define namespaced function, global function may not be existing yet. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
I would probably be in favor of throwing a notice or a warning when someone modifies a built-in function (or even throw an exception) and What's the use of having feature that produces an error when used? Anyway, it won't help you since you could have global function defined later than namespaced function. We could change resolution rule to look for global names first, but it's not that clear to me it's what we really want - for example, it would not allow one to use Exception class in namespaces - since there's already such global class. I think having namespaced entity with the same name as global entity may be both desired and undesired in different contexts, and there's an easy way to deal with it unambiguously - just use ::name for global names. Also we suppose that people are in control of their namespaces - i.e. that you know what classes/functions your namespace contains. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
> > > Right. You can have namespace UTF8 and function strlen() in it. > > > > This kind of "overriding" would make an interesting feature! However, if > > a programmer creates - by coincidence - a method with the name of an > > built-in PHP function, he alters the program's behaviour; from another > > point of view, this is something that should be forbidden, as I think it > > could be a source of hard-to-find errors. I would be in favour of allowing built-in function names to be used. One of the great things about namespaces is that I can use "foo" for a function and never have to worry about needing to re-write parts of my application because someone added a built-in function called "foo" to a later version of PHP. > I would probably be in favor of throwing a notice or a warning when > someone modifies a built-in function (or even throw an exception) and > that way as soon as you do such thing you would know right away that > you modified something and you would know where the modification > happened which would make things much easier for people developing and > debugging applications. Throwing exceptions is a bad idea. Developers will simply "overload" every function just in case new versions of PHP introduce a function with the same name. Personally I would scrap the "overload" keyword and use a setting in php.ini to control logging this kind of notice. You really only care about these messages during development and having it in the php.ini makes it easy to disable. Additionally, I think many newer programmers will get confused about when/why they should be using "overload" resulting in overuse. Rich -- Rich Buggy [EMAIL PROTECTED] http://www.buggy.id.au/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
I love this. Let's ship it.
-Andrei
On Jul 5, 2007, at 6:49 AM, Dmitry Stogov wrote:
I think the following example is much better, however I am not sure
it's a
right direction. Namespaces are intended to declare names that can
conflict
with names from other namespaces (including global namespace), do I
am not
sure that we need special keyword for internal functions.
We'll think little bit more. Anyway thank you for feedback and idea.
Thanks. Dmitry.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Coallier
Sent: Thursday, July 05, 2007 5:35 PM
To: Stefan Priebsch
Cc: Dmitry Stogov; PHP internals
Subject: Re: [PHP-DEV] Simple Namespace Proposal
On 7/5/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
David Coallier schrieb:
I would probably be in favor of throwing a notice or a
warning when
someone modifies a built-in function (or even throw an exception)
and that way as soon as you do such thing you would know
right away
that you modified something and you would know where the
modification happened which would make things much easier
for people
developing and debugging applications.
The problem is that this kind of overloading makes a nice
feature as
well. This is runied by throwing an exception, and cautious
developers
will at least get nervous when they see a notice.
I could imagine that by adding something like "overrides foo()" or
"overloads foo()" to a function/method declaration the
developer could
make clear that he willingly overrides a built-in function, and if
this is missing, an exception is being thrown. This may be a little
over the top, however.
Yep I see what you mean.. could even be something like:
namespace UTF8;
overrides {
strlen();
strcmp();
}
function strlen($string)
{
return strlen($string) + 666; // This is just an example ! } ...
I kinda like the overrides part, however I wonder if people
will actually use it.. Oh well.. my two cents are now gone.
Kind regards,
Stefan
--
e-novative> - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On 04/07/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote: Nor variables naither constants. They are defined in run-time. This seems to me like a bit of drawback. Would it be possible to add compile-time constants, then (like const FOO = 1; outside a class)? Creating a class inside a namespace for constants doesn't seem clean to me. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
PHP itself (without classes) hasn't compile-time constants (and variables). You can define constants only in run-time using define(). This is the reason why this proposal don't try to use constants and variables in namespaces. So ithis approach is absolutely consistent. BTW you can "import" not only namespace but also class from namespace. -Original Message- > From: Stefan Walk [mailto:[EMAIL PROTECTED] > Sent: Friday, July 06, 2007 10:26 PM > To: Dmitry Stogov > Cc: Brian Moon; internals@lists.php.net > Subject: Re: [PHP-DEV] Simple Namespace Proposal > > > On 04/07/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote: > > Nor variables naither constants. > > They are defined in run-time. > > This seems to me like a bit of drawback. Would it be possible > to add compile-time constants, then (like const FOO = 1; > outside a class)? Creating a class inside a namespace for > constants doesn't seem clean to me. > > Regards, > Stefan > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On 7/6/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
PHP itself (without classes) hasn't compile-time constants (and variables).
You can define constants only in run-time using define(). This is the reason
why this proposal don't try to use constants and variables in namespaces. So
ithis approach is absolutely consistent.
BTW you can "import" not only namespace but also class from namespace.
-Original Message-
> From: Stefan Walk [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 06, 2007 10:26 PM
> To: Dmitry Stogov
> Cc: Brian Moon; internals@lists.php.net
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
> On 04/07/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> > Nor variables naither constants.
> > They are defined in run-time.
>
> This seems to me like a bit of drawback. Would it be possible
> to add compile-time constants, then (like const FOO = 1;
> outside a class)? Creating a class inside a namespace for
> constants doesn't seem clean to me.
>
> Regards,
> Stefan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
One thing I'm wondering (might have missed it on the list but we
discussed that a little bit on irc..)
Do we have to have a namespace per file or could we have our braces ? :)
namespace A::B
{
class BooYa
{
const C = 'Foo';
}
}
--- Then..
import A::B::BooYa;
echo BooYa::C;
That way we can put more than one namespace within a file or such...
just point me if I am replying to an existing question or re-asking :)
Thanks,
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
namespace A::B
{
class BooYa
{
const C = 'Foo';
}
}
--- Then..
import A::B::BooYa;
echo BooYa::C;
Well, we could have braces but...
That way we can put more than one namespace within a file or such...
That is exactly what I don't want to have, since then you can't see in
the file which name means what - you'd have to trace it back to
including namespace to see what is the real name of the class.
Also if we do braces next thing would be asked to do namespace {
namespace {} } and we don't want that either :) We try to keep it really
simple.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
One file may contain only one namespace and nothing else.
Several files may have the same namespace.
Dmitry.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of David Coallier
> Sent: Saturday, July 07, 2007 12:12 AM
> To: Dmitry Stogov
> Cc: Stefan Walk; Brian Moon; internals@lists.php.net
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
> On 7/6/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> > PHP itself (without classes) hasn't compile-time constants (and
> > variables). You can define constants only in run-time using
> define().
> > This is the reason why this proposal don't try to use constants and
> > variables in namespaces. So ithis approach is absolutely consistent.
> >
> > BTW you can "import" not only namespace but also class from
> namespace.
> >
> > > namespace A::B;
> >
> > class Foo {
> > const C = 5;
> > }
> >
> > > import A::B::Foo;
> > echo Foo::C;
> >
> > I would like to start with this "simple" proposal and may
> be extend it
> > with constants and variables in the future.
> >
> > Thanks. Dmitry.
> >
> > > -----Original Message-
> > > From: Stefan Walk [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, July 06, 2007 10:26 PM
> > > To: Dmitry Stogov
> > > Cc: Brian Moon; internals@lists.php.net
> > > Subject: Re: [PHP-DEV] Simple Namespace Proposal
> > >
> > >
> > > On 04/07/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> > > > Nor variables naither constants.
> > > > They are defined in run-time.
> > >
> > > This seems to me like a bit of drawback. Would it be
> possible to add
> > > compile-time constants, then (like const FOO = 1; outside
> a class)?
> > > Creating a class inside a namespace for constants doesn't
> seem clean
> > > to me.
> > >
> > > Regards,
> > > Stefan
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
> One thing I'm wondering (might have missed it on the list but
> we discussed that a little bit on irc..)
>
> Do we have to have a namespace per file or could we have our
> braces ? :)
>
> namespace A::B
> {
> class BooYa
> {
> const C = 'Foo';
> }
> }
>
> --- Then..
>
> import A::B::BooYa;
> echo BooYa::C;
>
>
>
> That way we can put more than one namespace within a file or
> such... just point me if I am replying to an existing
> question or re-asking :)
>
> Thanks,
>
> --
> David Coallier,
> Founder & Software Architect,
> Agora Production (http://agoraproduction.com)
> 51.42.06.70.18
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Lets not say what i didnt say...did anyone ask for
class a (
class b (
)
)
i believe not.. the point was to keep the same coding standards if i
may say so than classes, interfaces, abstracts, etc. simply for
consistency and normalization..
ps sorry for brackets its from my mobile phone
On 7/6/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> namespace A::B
> {
>class BooYa
>{
>const C = 'Foo';
>}
> }
>
> --- Then..
>
> import A::B::BooYa;
> echo BooYa::C;
Well, we could have braces but...
> That way we can put more than one namespace within a file or such...
That is exactly what I don't want to have, since then you can't see in
the file which name means what - you'd have to trace it back to
including namespace to see what is the real name of the class.
Also if we do braces next thing would be asked to do namespace {
namespace {} } and we don't want that either :) We try to keep it really
simple.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Hi Dmitry, Allowing only one namespace per file is a clean concept which I like very much. I have a use case for putting multiple namespaces into one file, though. OOP-PHP applications are usually one class per file with conditional loading. This does not play well with caching. I am working on gluing together all files of a project into one large source file on deployment (a phing task will do this) so it can be opcode cached as one large application binary. I will then compare the performance of both apporaches, but I have a feeling that the "single binary" approach will be faster. As APC will be part of PHP6, I think this approach could improve general performance of PHP applications and easw deployment. Allowing only one namespace per file will obviously kill this approach. So if there is there a chance of allowing a namespace in braces, it would be great if you could make this possible. Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Stefan Priebsch schrieb: > I am working on gluing together all files of a project into one large > source file on deployment Why not "expand" namespaces during these step? The resulting file would then have either only one namespace or no namespace at all. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Sebastian Bergmann schrieb: > Why not "expand" namespaces during these step? The resulting file would > then have either only one namespace or no namespace at all. A good idea, but (much) more work of course, since it requires parsing and rewriting every file. And I am not sure, if this really works out when it comes to dynamically creating class and function names. Is there a chance to add a PHP function that returns a "fully qualified" name for a given name (thus letting the engine do the expansion, which would ensure that correct rules are used)? Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Stefan Priebsch schrieb: > Is there a chance to add a PHP function that returns a "fully > qualified" name for a given name (thus letting the engine do the > expansion, which would ensure that correct rules are used)? This is part of the functionality that needs to be, IMHO, added to the Reflection API, yes. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Stefan Priebsch wrote: > Hi Dmitry, > > Allowing only one namespace per file is a clean concept which I like > very much. I have a use case for putting multiple namespaces into one > file, though. > > OOP-PHP applications are usually one class per file with conditional > loading. This does not play well with caching. I am working on gluing > together all files of a project into one large source file on deployment > (a phing task will do this) so it can be opcode cached as one large > application binary. I will then compare the performance of both > apporaches, but I have a feeling that the "single binary" approach will > be faster. As APC will be part of PHP6, I think this approach could > improve general performance of PHP applications and easw deployment. Note that what you are saving by combining the files into one is just a single stat syscall per file. And that can be alleviated by setting apc.stat=0 in your config. That of course means you need to restart your server or flush your cache whenever you want to update the files. In apc.stat=0 mode you gain nothing by merging all the files. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Hi Ramus, Rasmus Lerdorf schrieb: > Note that what you are saving by combining the files into one is just a > single stat syscall per file. And that can be alleviated by setting > apc.stat=0 in your config. That of course means you need to restart > your server or flush your cache whenever you want to update the files. > In apc.stat=0 mode you gain nothing by merging all the files. Hmmm, in earlier posts of yours (BTW, there was quite some confusion about those, I believe) you mentioned that/how cache-unfriendly conditional includes (i.e. autoload) were. Are we talking about new APC development here or did I misread your earlier comments on caching? Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On Saturday 07 July 2007, Stefan Priebsch wrote: > Hi Dmitry, > > Allowing only one namespace per file is a clean concept which I like > very much. I have a use case for putting multiple namespaces into one > file, though. > > OOP-PHP applications are usually one class per file with conditional > loading. This does not play well with caching. I am working on gluing > together all files of a project into one large source file on deployment > (a phing task will do this) so it can be opcode cached as one large > application binary. I will then compare the performance of both > apporaches, but I have a feeling that the "single binary" approach will > be faster. As APC will be part of PHP6, I think this approach could > improve general performance of PHP applications and easw deployment. > > Allowing only one namespace per file will obviously kill this approach. > So if there is there a chance of allowing a namespace in braces, it > would be great if you could make this possible. > > Kind regards, > > Stefan I would also prefer a braces-based namespace approach. Namespace organization and file organization do not always match 1:1, especially if you're doing function-based programming rather than OO. Being able to put 2 namespaces in one file would add a great deal of flexibility, stat-count aside. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
+1 for braces around namespace definition. Personally I'm not really convinced that imposing a coding standard we see as clean/more acceptable is really useful in that case. On 7/7/07, Larry Garfield <[EMAIL PROTECTED]> wrote: On Saturday 07 July 2007, Stefan Priebsch wrote: > Hi Dmitry, > > Allowing only one namespace per file is a clean concept which I like > very much. I have a use case for putting multiple namespaces into one > file, though. > > OOP-PHP applications are usually one class per file with conditional > loading. This does not play well with caching. I am working on gluing > together all files of a project into one large source file on deployment > (a phing task will do this) so it can be opcode cached as one large > application binary. I will then compare the performance of both > apporaches, but I have a feeling that the "single binary" approach will > be faster. As APC will be part of PHP6, I think this approach could > improve general performance of PHP applications and easw deployment. > > Allowing only one namespace per file will obviously kill this approach. > So if there is there a chance of allowing a namespace in braces, it > would be great if you could make this possible. > > Kind regards, > > Stefan I would also prefer a braces-based namespace approach. Namespace organization and file organization do not always match 1:1, especially if you're doing function-based programming rather than OO. Being able to put 2 namespaces in one file would add a great deal of flexibility, stat-count aside. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Nicolas Bérard-Nault ([EMAIL PROTECTED]) Étudiant D.E.C. Sciences, Lettres & Arts Cégep de Sherbrooke Homepage: http://nicobn.googlepages.com
Re: [PHP-DEV] Simple Namespace Proposal
Stefan Priebsch wrote:
> Hi Ramus,
>
> Rasmus Lerdorf schrieb:
>> Note that what you are saving by combining the files into one is just a
>> single stat syscall per file. And that can be alleviated by setting
>> apc.stat=0 in your config. That of course means you need to restart
>> your server or flush your cache whenever you want to update the files.
>> In apc.stat=0 mode you gain nothing by merging all the files.
>
> Hmmm, in earlier posts of yours (BTW, there was quite some confusion
> about those, I believe) you mentioned that/how cache-unfriendly
> conditional includes (i.e. autoload) were. Are we talking about new APC
> development here or did I misread your earlier comments on caching?
That's a completely separate subject. Any time a class or function is
conditionally defined, it cannot be cached and the opcodes to create the
class or function must be run on each request because we need the
execution context to determine whether or not the class or function
should exist. This has absolutely nothing to do with whether or not
they are in an include file. You can get a conditional function simply
by doing:
if($foo) {
function bar() { }
}
Or you may get it by conditionally including the file that defines it.
Note that the opcodes are still cached, it just means that the executor
has a bit more work to do on each request.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
> Note that what you are saving by combining the files into one is just a > single stat syscall per file. And that can be alleviated by setting > apc.stat=0 in your config. That of course means you need to restart > your server or flush your cache whenever you want to update the files. > In apc.stat=0 mode you gain nothing by merging all the files. > > -Rasmus This was our belief as well but we have been experimenting with file combining and have seen as much a 2x speed improvement over using includes even with apc.stat=0. I need to spend some time investigating this more but from some initial profiling the most significant difference is that when all functions are in a single file execution goes through ZEND_DO_FCALL_SPEC_CONST_HANDLER. When functions are in included files execution seems to go through ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER and ZEND_INIT_FCALL_BY_NAME_SPEC_CONTS_HANDLER. The latter function spends a good amount of time in zend_str_tolower_dup and overall we spend more time in memory allocation. I'm not too familiar with zend internals and do not yet undersand the logic here but today there is an actual benefit to inlining files when working with a large enough code base. -lucas -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Nicolas Bérard-Nault schrieb: > +1 for braces around namespace definition. -0 on that, because there is no clear "standard" with regard to how other programming languages solve this. Java does not require braces with its "package" construct [1] and C# does for its "namespace" construct [2]. -- [1] http://java.sun.com/docs/books/jls/third_edition/html/packages.html [2] http://www.jaggersoft.com/csharp_standard/8.12.htm -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
It seems that in contrast with a lot of people on this list, I don't preach a "standard" way of doing things. What I do believe is that, in the end, it is the programmer's choice. I for one won't use namespaces that much if I can't have more than one in the same file. Using an inductive logic, I guess we can say a lot of PHP developers would like to have the choice, too. I believe we should stop trying to find a "solution" to a problem that should not be solved by us in the first place. Let it be my choice, however right or wrong it may seem, to obey the standard which seems fit to me, thank you. P.S.: This opinion only applies to this particular case. Generally speaking, I'm all for a loosely defined "PHP way". On 7/8/07, Sebastian Bergmann <[EMAIL PROTECTED]> wrote: Nicolas Bérard-Nault schrieb: > +1 for braces around namespace definition. -0 on that, because there is no clear "standard" with regard to how other programming languages solve this. Java does not require braces with its "package" construct [1] and C# does for its "namespace" construct [2]. -- [1] http://java.sun.com/docs/books/jls/third_edition/html/packages.html [2] http://www.jaggersoft.com/csharp_standard/8.12.htm -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Nicolas Bérard-Nault ([EMAIL PROTECTED]) Étudiant D.E.C. Sciences, Lettres & Arts Cégep de Sherbrooke Homepage: http://nicobn.googlepages.com
Re: [PHP-DEV] Simple Namespace Proposal
Rasmus Lerdorf schrieb: > Stefan Priebsch wrote: Hi Rasmus, > Or you may get it by conditionally including the file that defines it. > Note that the opcodes are still cached, it just means that the executor > has a bit more work to do on each request. Thanks for clarifying this. Has anybody actually created a benchmark that allows to compare conditional/unconditional include with and without opcode cache? I'm working on some PHP benchmarks like this, and would really appreciate any pointer to existing work in this area. Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
Hi Stefan, Putting multiple namespaces in one file is really unusual case. It may be implemented, but I don't like to do it, because it may give more mess then advantage. Probably you'll have to create separate file for each namespace to make your idea work. BTW byte-code doesn't depend on namespaces and files to much so with modified APC you can cache multiple files at once. You can also use something like PHAR that is made especially for deployment. Thanks. Dmitry. > -Original Message- > From: Stefan Priebsch [mailto:[EMAIL PROTECTED] > Sent: Saturday, July 07, 2007 2:45 PM > To: Dmitry Stogov > Cc: 'David Coallier'; 'Stefan Walk'; 'Brian Moon'; > internals@lists.php.net > Subject: Re: [PHP-DEV] Simple Namespace Proposal > > > Hi Dmitry, > > Allowing only one namespace per file is a clean concept which > I like very much. I have a use case for putting multiple > namespaces into one file, though. > > OOP-PHP applications are usually one class per file with > conditional loading. This does not play well with caching. I > am working on gluing together all files of a project into one > large source file on deployment (a phing task will do this) > so it can be opcode cached as one large application binary. I > will then compare the performance of both apporaches, but I > have a feeling that the "single binary" approach will be > faster. As APC will be part of PHP6, I think this approach > could improve general performance of PHP applications and > easw deployment. > > Allowing only one namespace per file will obviously kill this > approach. So if there is there a chance of allowing a > namespace in braces, it would be great if you could make this > possible. > > Kind regards, > > Stefan > > -- > >e-novative> - We make IT work for you. > > e-novative GmbH - HR: Amtsgericht München HRB 139407 > Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch > > http://www.e-novative.de > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
> Is there a chance to add a PHP function that returns a "fully
> qualified" name for a given name (thus letting the engine do
> the expansion, which would ensure that correct rules are used)?
function namespace_name($name) {
return __NAMESPACE__ . "::" . $name;
}
Thanks. Dmitry.
> Kind regards,
>
> Stefan
>
>
> --
> >e-novative> - We make IT work for you.
>
> e-novative GmbH - HR: Amtsgericht München HRB 139407
> Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
>
> http://www.e-novative.de
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
Note that multiple files in namespace won't allow autoloading. Dmitry. > -Original Message- > From: Larry Garfield [mailto:[EMAIL PROTECTED] > Sent: Saturday, July 07, 2007 11:15 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Simple Namespace Proposal > > > On Saturday 07 July 2007, Stefan Priebsch wrote: > > Hi Dmitry, > > > > Allowing only one namespace per file is a clean concept > which I like > > very much. I have a use case for putting multiple > namespaces into one > > file, though. > > > > OOP-PHP applications are usually one class per file with > conditional > > loading. This does not play well with caching. I am working > on gluing > > together all files of a project into one large source file on > > deployment (a phing task will do this) so it can be opcode > cached as > > one large application binary. I will then compare the > performance of > > both apporaches, but I have a feeling that the "single binary" > > approach will be faster. As APC will be part of PHP6, I think this > > approach could improve general performance of PHP applications and > > easw deployment. > > > > Allowing only one namespace per file will obviously kill this > > approach. So if there is there a chance of allowing a namespace in > > braces, it would be great if you could make this possible. > > > > Kind regards, > > > > Stefan > > I would also prefer a braces-based namespace approach. > Namespace organization > and file organization do not always match 1:1, especially if > you're doing > function-based programming rather than OO. Being able to put > 2 namespaces in > one file would add a great deal of flexibility, stat-count aside. > > -- > Larry GarfieldAIM: LOLG42 > [EMAIL PROTECTED] ICQ: 6817012 > > "If nature has made any one thing less susceptible than all others of > exclusive property, it is the action of the thinking power > called an idea, > which an individual may exclusively possess as long as he keeps it to > himself; but the moment it is divulged, it forces itself into > the possession > of every one, and the receiver cannot dispossess himself of > it." -- Thomas > Jefferson > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
-1 for braces and multiple namespaces per file Braces will allow define something outside namespace and I like to avoid this possibility. In the following "correct" example function bar() is defined in global namespace. Dmitry. > -Original Message- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Bergmann > Sent: Sunday, July 08, 2007 10:13 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Simple Namespace Proposal > > > Nicolas Bérard-Nault schrieb: > > +1 for braces around namespace definition. > > -0 on that, because there is no clear "standard" with regard > to how other programming languages solve this. > > Java does not require braces with its "package" construct > [1] and C# does for its "namespace" construct [2]. > > -- > [1] > http://java.sun.com/docs/books/jls/third_edition/html/packages.html > [2] http://www.jaggersoft.com/csharp_standard/8.12.htm > > -- > Sebastian Bergmann > http://sebastian-bergmann.de/ > GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 > C514 B85B 5D69 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Lets not say what i didnt say...did anyone ask for class a ( class b ( ) ) There were such proposals. But nested classes bring the whole set of problems with them, and I don't really see a need for them. As we see, we can solve long names problems in much simpler, and I daresay, more elegant way. And other benefits of nested classes, IMHO, not worth the trouble. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
OOP-PHP applications are usually one class per file with conditional loading. This does not play well with caching. I am working on gluing Why wouldn't it play well with caching? (a phing task will do this) so it can be opcode cached as one large application binary. I will then compare the performance of both apporaches, but I have a feeling that the "single binary" approach will be faster. As APC will be part of PHP6, I think this approach could I don't think "one binary" approach makes sense for PHP. PHP application is usually composed of many files, some of them are library files not used at all, some are rarely used, etc. Also, this approach does not allow to change individual files without having all the system lose performance significantly. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Hi Dmitry,
I am merging together your various posts:
> Note that multiple files in namespace won't allow autoloading.
Can you please explain why that is so?
> function namespace_name($name) {
> return __NAMESPACE__ . "::" . $name;
>}
Thanks for posting this - I am not sure wether this would do the trick
in my case, though, since would need to calculate a fully-qualified name
from *outside* the current namespace. BUT:
> Putting multiple namespaces in one file is really unusual case.
> It may be implemented, but I don't like to do it, because it may give
> more mess then advantage.
Right. As I said before, I'd like to have this if it is not difficult to
do. Given the recent discussion with Rasmus about caching I think that y
original idea of glueing together files to improve performance will go
down the drain anyway. Bottom line: I'm with you.
Kind regards,
Stefan
--
>e-novative> - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Stanislav Malyshev schrieb: > Why wouldn't it play well with caching? My statement refered to a statment Rasmus had made somewhere else a while ago (conditional includes not playing well with caches) that got me confused. See Rasmus' clarifications in this thread. > I don't think "one binary" approach makes sense for PHP. PHP application > is usually composed of many files, some of them are library files not > used at all, some are rarely used, etc. Also, this approach does not > allow to change individual files without having all the system lose > performance significantly. I wouldn't want to make it a new standard, but I'd say there could be a use for it. You could deploy a PHP application like a statically linked binary without external dependencies. That means, for example, no problems when "wrong" versions of external libraries are loaded because of an unexpected include path etc. Also, it is easier to ensure the application's integrity, because users cannot easily change or swap out a single file. I was asking myself wether loading one large file - possibly from a cache - might be a lot faster than loading n files. This of course depends on how expensive disk access is compared to how large your "binary" gets. That's why I was planning to benchmark it. Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Yes, it would be. What's the problem with that?
I'm coming from the background of a plugin-based architecture where plugins
routinely add functions that would, conceptually, "exist" in a different
namespace.
That would require having both multiple namespaces per file and multiple files
per namespace. If we can't do that then we're back to using static classes
as if they were namespaces.
On Sunday 08 July 2007, Dmitry Stogov wrote:
> -1 for braces and multiple namespaces per file
>
> Braces will allow define something outside namespace and I like to avoid
> this possibility.
> In the following "correct" example function bar() is defined in global
> namespace.
>
> namespace A::B {
>
> function foo() {
> }
>
> }
>
> function bar() {
> }
> ?>
>
> Dmitry.
>
> > -Original Message-
> > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Bergmann
> > Sent: Sunday, July 08, 2007 10:13 AM
> > To: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Simple Namespace Proposal
> >
> > Nicolas Bérard-Nault schrieb:
> > > +1 for braces around namespace definition.
> >
> > -0 on that, because there is no clear "standard" with regard
> > to how other programming languages solve this.
> >
> > Java does not require braces with its "package" construct
> > [1] and C# does for its "namespace" construct [2].
> >
> > --
> > [1]
> > http://java.sun.com/docs/books/jls/third_edition/html/packages.html
> > [2] http://www.jaggersoft.com/csharp_standard/8.12.htm
> >
> > --
> > Sebastian Bergmann
> > http://sebastian-bergmann.de/
> > GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867
> > C514 B85B 5D69
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
I'm going to have to agree with Larry, here. If there's no *real* namespace
implementation in PHP6, there may as well not be one at all. Take a look around
at the countless other languages that already have this functionality. You're
gimping the language further if you implement namespaces without such core
functionality as this.
Regards,
Jeremy
-Original Message-
From: Larry Garfield [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 08, 2007 1:13 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Simple Namespace Proposal
Yes, it would be. What's the problem with that?
I'm coming from the background of a plugin-based architecture where plugins
routinely add functions that would, conceptually, "exist" in a different
namespace.
That would require having both multiple namespaces per file and multiple files
per namespace. If we can't do that then we're back to using static classes
as if they were namespaces.
On Sunday 08 July 2007, Dmitry Stogov wrote:
> -1 for braces and multiple namespaces per file
>
> Braces will allow define something outside namespace and I like to avoid
> this possibility.
> In the following "correct" example function bar() is defined in global
> namespace.
>
> namespace A::B {
>
> function foo() {
> }
>
> }
>
> function bar() {
> }
> ?>
>
> Dmitry.
>
> > -Original Message-
> > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Bergmann
> > Sent: Sunday, July 08, 2007 10:13 AM
> > To: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Simple Namespace Proposal
> >
> > Nicolas Bérard-Nault schrieb:
> > > +1 for braces around namespace definition.
> >
> > -0 on that, because there is no clear "standard" with regard
> > to how other programming languages solve this.
> >
> > Java does not require braces with its "package" construct
> > [1] and C# does for its "namespace" construct [2].
> >
> > --
> > [1]
> > http://java.sun.com/docs/books/jls/third_edition/html/packages.html
> > [2] http://www.jaggersoft.com/csharp_standard/8.12.htm
> >
> > --
> > Sebastian Bergmann
> > http://sebastian-bergmann.de/
> > GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867
> > C514 B85B 5D69
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On Sunday 08 July 2007, Stefan Priebsch wrote: > I was asking myself wether loading one large file - possibly from a > cache - might be a lot faster than loading n files. This of course > depends on how expensive disk access is compared to how large your > "binary" gets. That's why I was planning to benchmark it. > > Kind regards, > > Stefan Some incomplete data: I work mostly on Drupal, and in the next version we're splitting up the code base into a lot more smaller files that we can load conditionally. The benchmarks we've done so far indicate that without an opcode cache there's a huge benefit in speed from not loading/parsing code that we're not going to be using (there's a lot of it at this point) as well as a sizable reduction in RAM usage. With an opcode cache the speed difference is negligible, but I believe there's still a RAM savings per-process. More on that when we've completed the process. So it all depends on your caching configuration and use-case. Loading a ton of code that you never use is not good for performance. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
I'm going to have to agree with Larry, here. If there's no *real* namespace implementation in PHP6, there may as well not be one at This implementation, while being simple, is as real as it gets. There's nothing unreal in not having multiple namespaces per file. all. Take a look around at the countless other languages that already have this functionality. You're gimping the language further if you And take look around at languages that don't - such as Python. Or Perl, that though allows using package declaration in any block multiple times, almost always uses it the same way we do, and even when it doesn't it easily could. Or Java. I think we need to officially declare "If it's not my way PHP is not a real language" nonargument and automatically post monthly reminder of that. I'm sure there are better arguments for any position. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Simplicity is not always dumb, but it can be if it limits usability. It might be "my PHP way" to define the language as pragmatic and I may be wrong in assuming this. Nevertheless, we've demonstrated with great length that multiple namespaces per file / namespaces delimited by braces can and will be useful. I don't want it "my way" and I'm sure everybody not against braces wants it "their way", we want to be able to choose which way we'd like to use. Must we say please for that ? If it's the case: please ! ;-). Alright, I'm out of this discussion. On 7/8/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > I'm going to have to agree with Larry, here. If there's no *real* > namespace implementation in PHP6, there may as well not be one at This implementation, while being simple, is as real as it gets. There's nothing unreal in not having multiple namespaces per file. > all. Take a look around at the countless other languages that already > have this functionality. You're gimping the language further if you And take look around at languages that don't - such as Python. Or Perl, that though allows using package declaration in any block multiple times, almost always uses it the same way we do, and even when it doesn't it easily could. Or Java. I think we need to officially declare "If it's not my way PHP is not a real language" nonargument and automatically post monthly reminder of that. I'm sure there are better arguments for any position. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Nicolas Bérard-Nault ([EMAIL PROTECTED]) Étudiant D.E.C. Sciences, Lettres & Arts Cégep de Sherbrooke Homepage: http://nicobn.googlepages.com
RE: [PHP-DEV] Simple Namespace Proposal
> -Original Message-
> From: Stefan Priebsch [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 08, 2007 3:51 PM
> To: Dmitry Stogov
> Cc: 'Sebastian Bergmann'; internals@lists.php.net
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
> Hi Dmitry,
>
> I am merging together your various posts:
>
> > Note that multiple files in namespace won't allow autoloading.
> Can you please explain why that is so?
Now autoloading maps class name into file name, however if you have several
classes in one file, only one of them may be autoloaded(). The same with
namespaces.
Dmitry.
>
> > function namespace_name($name) {
> > return __NAMESPACE__ . "::" . $name;
> >}
> Thanks for posting this - I am not sure wether this would do
> the trick in my case, though, since would need to calculate a
> fully-qualified name from *outside* the current namespace. BUT:
>
>
> > Putting multiple namespaces in one file is really unusual
> case. It may
> > be implemented, but I don't like to do it, because it may give more
> > mess then advantage.
> Right. As I said before, I'd like to have this if it is not
> difficult to do. Given the recent discussion with Rasmus
> about caching I think that y original idea of glueing
> together files to improve performance will go down the drain
> anyway. Bottom line: I'm with you.
>
>
> Kind regards,
>
> Stefan
>
> --
> >e-novative> - We make IT work for you.
>
> e-novative GmbH - HR: Amtsgericht München HRB 139407
> Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
>
> http://www.e-novative.de
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
On Sun, July 8, 2007 2:58 am, Dmitry Stogov wrote:
> -1 for braces and multiple namespaces per file
>
> Braces will allow define something outside namespace and I like to
> avoid
> this possibility.
> In the following "correct" example function bar() is defined in global
> namespace.
>
> namespace A::B {
>
> function foo() {
> }
>
> }
>
> function bar() {
> }
> ?>
+1 for braces.
This, to me, is not an unreasonable code layout, other than the
ridiculous function name.
If you want to document "namespaces will never be nested" from the
get-go, that would be fine, of course.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
+1 for braces. That's what I would like to avoid. Because if you need namespaces, then you want to segment your naming space. If you in the same time pollute the global space with non-namespaced function names, the whole namespace business is kind of meaningless. Or you want your library not polluting global space, or you don't. That's not the question of usage frequency - if you don't use one function and frequently use another, put them in different files for starters. And there's nothing preventing one from frequently using namespaced function - that's exactly why namespaces are proposed, to make frequent use of long names easier. That's why import exists. If you want to document "namespaces will never be nested" from the get-go, that would be fine, of course. I see no reason to nest namespaces - since there's no relation between Foo::bar and Foo::bar::Baz as namespaces - they are different strings. Nesting is needed only when there is a relation, and I think that's just unnecessary complication, not worth the trouble. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Dmitry, >>> Note that multiple files in namespace won't allow autoloading. >> Can you please explain why that is so? > > Now autoloading maps class name into file name, however if you have several > classes in one file, only one of them may be autoloaded(). The same with > namespaces. Did you confuse "multiple files in namespace" and "multiple namespaces in a file" in your original post? If yes, I'm with you, otherwise: Wasn't the original idea of your namespace implementation to simplify those long PEARified class names, kind of, by substituting a namespace for that name prefix? So I can write an autoloader that maps a namespace+class name to a file name. Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Stanislav Malyshev schrieb:
>> function super_common_function_every_namespace_in_my_project_uses(){
>> }
>>
>> namespace A::B {
> That's what I would like to avoid. Because if you need namespaces, then
> you want to segment your naming space. If you in the same time pollute
> the global space with non-namespaced function names, the whole namespace
> business is kind of meaningless. Or you want your library not polluting
> global space, or you don't.
Will there be an exception [as in: special case, not as in: new
Exception()] for an __autoload function?
Kind regards,
Stefan
--
>e-novative> - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
> -Original Message- > From: Stefan Priebsch [mailto:[EMAIL PROTECTED] > Sent: Monday, July 09, 2007 6:17 PM > To: Dmitry Stogov > Cc: 'Sebastian Bergmann'; internals@lists.php.net > Subject: Re: [PHP-DEV] Simple Namespace Proposal > > > Dmitry, > > >>> Note that multiple files in namespace won't allow autoloading. > >> Can you please explain why that is so? > > > > Now autoloading maps class name into file name, however if you have > > several classes in one file, only one of them may be > autoloaded(). The > > same with namespaces. > > Did you confuse "multiple files in namespace" and "multiple > namespaces in a file" in your original post? Yes :) Dmitry. > If yes, I'm with > you, otherwise: Wasn't the original idea of your namespace > implementation to simplify those long PEARified class names, > kind of, by substituting a namespace for that name prefix? So > I can write an autoloader that maps a > namespace+class name to a file name. > > Kind regards, > > Stefan > > > -- > >e-novative> - We make IT work for you. > > e-novative GmbH - HR: Amtsgericht München HRB 139407 > Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch > > http://www.e-novative.de > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
I agree, FWIW.
-Andrei
On Jul 9, 2007, at 12:49 AM, Stanislav Malyshev wrote:
+1 for braces.
function super_common_function_every_namespace_in_my_project_uses
(){
}
namespace A::B {
function foo() {
//arcana of A::B stuff
}
}
?>
That's what I would like to avoid. Because if you need namespaces,
then you want to segment your naming space. If you in the same time
pollute the global space with non-namespaced function names, the
whole namespace business is kind of meaningless. Or you want your
library not polluting global space, or you don't.
That's not the question of usage frequency - if you don't use one
function and frequently use another, put them in different files
for starters. And there's nothing preventing one from frequently
using namespaced function - that's exactly why namespaces are
proposed, to make frequent use of long names easier. That's why
import exists.
If you want to document "namespaces will never be nested" from the
get-go, that would be fine, of course.
I see no reason to nest namespaces - since there's no relation
between Foo::bar and Foo::bar::Baz as namespaces - they are
different strings. Nesting is needed only when there is a relation,
and I think that's just unnecessary complication, not worth the
trouble.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Will there be an exception [as in: special case, not as in: new Exception()] for an __autoload function? __autoload is actually not that great an idea, as it appears now. spl_autoload_register works much better for complicated libraries. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On Wed, 4 Jul 2007, Dmitry Stogov wrote: > The namespace declaration statement must be the very first statement in > file. I thought that was reserved in PHP 6 for the "pragma(encoding=UTF-8);" statement? Which of the two needs to be first, and which second? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
That's why I proposed (privately) to Dmitry to use declare() for namespace declaration. -Andrei On Jul 9, 2007, at 11:13 AM, Derick Rethans wrote: On Wed, 4 Jul 2007, Dmitry Stogov wrote: The namespace declaration statement must be the very first statement in file. I thought that was reserved in PHP 6 for the "pragma(encoding=UTF-8);" statement? Which of the two needs to be first, and which second? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
On Sun, 8 Jul 2007, Dmitry Stogov wrote: > Note that multiple files in namespace won't allow autoloading. That got me confused a bit. I was wondering whether the following would work (with autoload): In file "a/b.php": in file "a/c.php": In file "a/d.php": in file "a/e.php": in "index.php": regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
declare(encoding=...) may be used befor or right after namespace declaration. Dmitry. > -Original Message- > From: Derick Rethans [mailto:[EMAIL PROTECTED] > Sent: Monday, July 09, 2007 10:13 PM > To: Dmitry Stogov > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Simple Namespace Proposal > > > On Wed, 4 Jul 2007, Dmitry Stogov wrote: > > > The namespace declaration statement must be the very first > statement > > in file. > > I thought that was reserved in PHP 6 for the > "pragma(encoding=UTF-8);" > statement? Which of the two needs to be first, and which second? > > regards, > Derick > > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On Mon, 9 Jul 2007 20:13:23 +0200 (CEST), Derick Rethans <[EMAIL PROTECTED]> wrote: > On Wed, 4 Jul 2007, Dmitry Stogov wrote: > >> The namespace declaration statement must be the very first statement in >> file. > > I thought that was reserved in PHP 6 for the "pragma(encoding=UTF-8);" > statement? Which of the two needs to be first, and which second? And what of header(); ? > > regards, > Derick > > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php / Service provided by hitOmeter.NET internet messaging! . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
header() doesn't have to be the first statement in a file at all. It has to be called before any data is sent. On 7/9/07, chris# <[EMAIL PROTECTED]> wrote: On Mon, 9 Jul 2007 20:13:23 +0200 (CEST), Derick Rethans <[EMAIL PROTECTED]> wrote: > On Wed, 4 Jul 2007, Dmitry Stogov wrote: > >> The namespace declaration statement must be the very first statement in >> file. > > I thought that was reserved in PHP 6 for the "pragma(encoding=UTF-8);" > statement? Which of the two needs to be first, and which second? And what of header(); ? > > regards, > Derick > > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php / Service provided by hitOmeter.NET internet messaging! . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Nicolas Bérard-Nault ([EMAIL PROTECTED]) Étudiant D.E.C. Sciences, Lettres & Arts Cégep de Sherbrooke Homepage: http://nicobn.googlepages.com
Re: [PHP-DEV] Simple Namespace Proposal
Stanislav Malyshev schrieb: >> Will there be an exception [as in: special case, not as in: new >> Exception()] for an __autoload function? > > __autoload is actually not that great an idea, as it appears now. > spl_autoload_register works much better for complicated libraries. I know, and I use spl_autoload_register. But then I would blatantly suggest to remove __autoload() in PHP6 and force SPL to be compiled into PHP. Kind regards, Stefan Priebsch -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
I know, and I use spl_autoload_register. But then I would blatantly suggest to remove __autoload() in PHP6 and force SPL to be compiled into PHP. I wouldn't go as far as removing it, but definitely would go as far as not recommending to use it if writing a library or application that includes independent modules (such as libraries). If you application is homogeneous and non-modular, then using it may be ok. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On Mon, 9 Jul 2007 16:40:09 -0400, "Nicolas Bérard-Nault" <[EMAIL PROTECTED]> wrote: > header() doesn't have to be the first statement in a file at all. It has to > be called before any data is sent. Thanks for the response. Just wanted to see if there were any potential collisions here. Thanks again. > > On 7/9/07, chris# <[EMAIL PROTECTED]> wrote: >> >> >> >> >> On Mon, 9 Jul 2007 20:13:23 +0200 (CEST), Derick Rethans > <[EMAIL PROTECTED]> >> wrote: >> > On Wed, 4 Jul 2007, Dmitry Stogov wrote: >> > >> >> The namespace declaration statement must be the very first statement > in >> >> file. >> > >> > I thought that was reserved in PHP 6 for the "pragma(encoding=UTF-8);" >> > statement? Which of the two needs to be first, and which second? >> And what of header(); ? >> > >> > regards, >> > Derick >> > >> > -- >> > Derick Rethans >> > http://derickrethans.nl | http://ez.no | http://xdebug.org >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> / >> Service provided by hitOmeter.NET internet messaging! >> . >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > / Service provided by hitOmeter.NET internet messaging! . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On Mon, 9 Jul 2007 16:40:09 -0400, "Nicolas Bérard-Nault" <[EMAIL PROTECTED]> wrote: > header() doesn't have to be the first statement in a file at all. It has to > be called before any data is sent. Thanks for the response. Just wanted to see if there were any potential collisions here. Thanks again. > > On 7/9/07, chris# <[EMAIL PROTECTED]> wrote: >> >> >> >> >> On Mon, 9 Jul 2007 20:13:23 +0200 (CEST), Derick Rethans > <[EMAIL PROTECTED]> >> wrote: >> > On Wed, 4 Jul 2007, Dmitry Stogov wrote: >> > >> >> The namespace declaration statement must be the very first statement > in >> >> file. >> > >> > I thought that was reserved in PHP 6 for the "pragma(encoding=UTF-8);" >> > statement? Which of the two needs to be first, and which second? >> And what of header(); ? >> > >> > regards, >> > Derick >> > >> > -- >> > Derick Rethans >> > http://derickrethans.nl | http://ez.no | http://xdebug.org >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> / >> Service provided by hitOmeter.NET internet messaging! >> . >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > / Service provided by hitOmeter.NET internet messaging! . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On 10.07.2007, at 00:06, Stanislav Malyshev wrote: I know, and I use spl_autoload_register. But then I would blatantly suggest to remove __autoload() in PHP6 and force SPL to be compiled into PHP. I wouldn't go as far as removing it, but definitely would go as far as not recommending to use it if writing a library or application that includes independent modules (such as libraries). If you application is homogeneous and non-modular, then using it may be ok. Well if we are speaking of best practices, the sensible thing for libs to do is to provide a function/method users can call inside their own __autoload() implementation. This way users are free to make their __autoload() work as they please/require. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
Hi Derick,
Your example will work fine.
I made a mistake in my sentence. I meant not "multiple files in namespace"
but "multiple namespaces in file".
Proposed concept allows multiple files in namespace but not multiple
namespaces in file.
Thanks. Dmitry.
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 09, 2007 10:38 PM
> To: Dmitry Stogov
> Cc: 'Larry Garfield'; internals@lists.php.net
> Subject: RE: [PHP-DEV] Simple Namespace Proposal
>
>
> On Sun, 8 Jul 2007, Dmitry Stogov wrote:
>
> > Note that multiple files in namespace won't allow autoloading.
>
> That got me confused a bit. I was wondering whether the
> following would
> work (with autoload):
>
>
> In file "a/b.php":
>
> namespace a;
> class b { }
> ?>
>
> in file "a/c.php":
>
> namespace a;
> class c { }
> ?>
>
> In file "a/d.php":
>
> namespace a;
> class d { }
> ?>
>
> in file "a/e.php":
>
> namespace a;
> class e { }
> ?>
>
>
>
> in "index.php":
>
> function __autoload( $className )
> {
> include str_replace( "::", "/", $className ) . ".php";
> }
>
> $b = new a::b;
> $c = new a::c;
>
> import a;
>
> $d = new d;
> $e = new e;
>
> ?>
>
>
> regards,
> Derick
>
> --
> Derick Rethans
> http://derickrethans.nl | http://ez.no | http://xdebug.org
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
header() is a regular function, you can call it from anywhere (e.q. as top-level statement), butof course you cannot use it before namespace declaration. Dmitry. > -Original Message- > From: chris# [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 10, 2007 12:35 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Simple Namespace Proposal > > > > > > On Mon, 9 Jul 2007 20:13:23 +0200 (CEST), Derick Rethans > <[EMAIL PROTECTED]> wrote: > > On Wed, 4 Jul 2007, Dmitry Stogov wrote: > > > >> The namespace declaration statement must be the very first > statement > >> in file. > > > > I thought that was reserved in PHP 6 for the > "pragma(encoding=UTF-8);" > > statement? Which of the two needs to be first, and which second? > And what of header(); ? > > > > regards, > > Derick > > > > -- > > Derick Rethans > > http://derickrethans.nl | http://ez.no | http://xdebug.org > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > / > Service provided by hitOmeter.NET internet messaging! > . > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On Mon, July 9, 2007 2:49 am, Stanislav Malyshev wrote:
>> +1 for braces.
>>
>> > function
>> super_common_function_every_namespace_in_my_project_uses(){
>> }
>>
>> namespace A::B {
>> function foo() {
>> //arcana of A::B stuff
>> }
>> }
>> ?>
>
> That's what I would like to avoid. Because if you need namespaces,
> then
> you want to segment your naming space. If you in the same time pollute
> the global space with non-namespaced function names, the whole
> namespace
> business is kind of meaningless. Or you want your library not
> polluting
> global space, or you don't.
But some functions ARE so super-common, across the board, that I just
plain don't want them buried in some namespace...
I don't think I'm the only one on this...
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On Mon, July 9, 2007 4:58 pm, Stefan Priebsch wrote: > I know, and I use spl_autoload_register. But then I would blatantly > suggest to remove __autoload() in PHP6 and force SPL to be compiled > into > PHP. Deprecate in 6, remove in 7 might be a better strategy... Otherwise you'll hear: "Oh, I can't move to 6, it doesn't have autoload" And for those of us who never use autoload OR SPL, could you please not force SPL into core? If I need SPL autoload thingie, I'll put it in there. I don't need it. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On 7/11/07, Richard Lynch <[EMAIL PROTECTED]> wrote: On Mon, July 9, 2007 4:58 pm, Stefan Priebsch wrote: > I know, and I use spl_autoload_register. But then I would blatantly > suggest to remove __autoload() in PHP6 and force SPL to be compiled > into > PHP. Deprecate in 6, remove in 7 might be a better strategy... Otherwise you'll hear: "Oh, I can't move to 6, it doesn't have autoload" And for those of us who never use autoload OR SPL, could you please not force SPL into core? If I need SPL autoload thingie, I'll put it in there. I don't need it. Many people need it, anyone doing any *real* OOP will need to use SPL. If you don't use that *SPL autload thingie - which is spl_autoload_register, how can you know you'll need it ? If you haven't used it, you don't know how good it can be. I could explain the benefits of SPL but there's already a list/thread that has gone on and on and on and a bunch of people that have made their choice already so I will not comment here. If you want to do functional programming then go ahead, if you want to do OOP, then do real OOP, not sub-oop or some php4-oop. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On Wed, July 11, 2007 7:57 pm, David Coallier wrote: > If you want to do functional programming then go ahead, if you want to > do OOP, then do real OOP, not sub-oop or some php4-oop. Many users, for many tasks, have absolutely zero need to do any OOP at all. And bloating their PHP for OOP they don't need with no way to un-bloat it annoys them. For me personally, if I want to do *real* OOP, I wouldn't use PHP at all and would use Common Lisp. And, no, I'm not joking. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On Wed, 2007-07-11 at 20:57 -0400, David Coallier wrote: > > If you want to do functional programming then go ahead, if you want to > do OOP, then do real OOP, not sub-oop or some php4-oop. Pray tell... what exactly is "real OOP"? This sounds like it might be something extremely subjective and pointless to the discussion. OOP is OOP regardless of what features may exist or may be used by the person using Objects in their Programming Orientation. Cheers, Rob. -- ... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
But some functions ARE so super-common, across the board, that I just plain don't want them buried in some namespace... Sure, why not put them into separate file then? I understand we're forcing some structure here, but I think actually it's good - and many other languages have it either by design or de-facto. And in fact we started doing it in php 5 with autoloading and classname->filename paradigm. So I'd like to keep namespace wrapped, and utility functions living separately. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Richard Lynch schrieb: > And for those of us who never use autoload OR SPL, could you please > not force SPL into core? >From a regular PHP developer's perspective, SPL is part of the core (read: it is guaranteed that it is always there). The manual says so, and it has been said in most, if not all SPL-related presentations. So people have started using SPL, iterators, autoload, or the pre-defined exceptions. You might not use it personally, but I bet that sooner or later components and libraries you use will pick up on it, if they haven't already. AFAIK, PDO offers iterator-based access. Does PDO work without SPL? IMHO, you have to set a standard set of PHP features that everybody can rely on. By still allowing stuff to be disabled, you start adding more incertainty to the whole thing. If it can be disabled, somebody will disable it one day, get into trouble, file a bug report, and be told "you need to always enable SPL". Isn't that a waste of time, energy and resources? Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
> -Original Message-
> From: Richard Lynch [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 12, 2007 4:45 AM
> To: Stanislav Malyshev
> Cc: Dmitry Stogov; 'Sebastian Bergmann'; internals@lists.php.net
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
> On Mon, July 9, 2007 2:49 am, Stanislav Malyshev wrote:
> >> +1 for braces.
> >>
> >> >> function
> >> super_common_function_every_namespace_in_my_project_uses(){
> >> }
> >>
> >> namespace A::B {
> >> function foo() {
> >> //arcana of A::B stuff
> >> }
> >> }
> >> ?>
> >
> > That's what I would like to avoid. Because if you need namespaces,
> > then you want to segment your naming space. If you in the same time
> > pollute the global space with non-namespaced function
> names, the whole
> > namespace
> > business is kind of meaningless. Or you want your library not
> > polluting
> > global space, or you don't.
>
> But some functions ARE so super-common, across the board,
> that I just plain don't want them buried in some namespace...
>
> I don't think I'm the only one on this...
If you like some function to be in global namespace then don't put it into
namespace file.
Put it into separate file without namespace declaration.
Thanks. Dmitry.
> --
> Some people have a "gift" link here.
> Know what I want?
> I want you to buy a CD from some indie artist.
> http://cdbaby.com/browse/from/lynch
> Yeah, I get a buck. So?
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On Thu, 2007-07-12 at 09:30 +0200, Stefan Priebsch wrote: > From a regular PHP developer's perspective, SPL is part of the core > (read: it is guaranteed that it is always there). The manual says so, > and it has been said in most, if not all SPL-related presentations. If manual says that then the manual needs to be fixed. I myself disable it when I don't need it. But it is enabled by default, so if you don't use --disable-all and don't enable it explicitly then it is there. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On Wed, 11 Jul 2007 21:31:34 -0700 [EMAIL PROTECTED] (Stanislav Malyshev) wrote: > I understand we're forcing some structure here, but I think > actually it's good - and many other languages have it either > by design or de-facto. Personally, I'm of the opinion that file structure should be an application concern, not a language concern. I'd also venture that many of the languages that enforce a file structure do so because they include a packaging system; PHP doesn't. > And in fact we started doing it in php 5 with autoloading and > classname->filename paradigm. Not really. There's nothing to stop someone from lumping multiple classes into a single file AND using an autoloader, provided they have a scheme for locating the specific file containing any given class. (There's also nothing stopping them from skipping the autoloader alltogether.) Similarly, allowing multiple namespaces per file does not limit the developer in any way. Not allowing them does. I always thought a language should be designed to empower it's developers, not get in their way. -- Andrew Minerd Software Architect The Selling Source, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Similarly, allowing multiple namespaces per file does not limit the developer in any way. Not allowing them does. I always thought a language should be designed to empower it's developers, not get in their way. My opinion is that sometimes language *should* "get in the way" - if the developer is trying to do a wrong thing. Doing things right should be easy, doing things wrong should be hard. I agree that this means we should choose some definitions for right and wrong, and not everybody would necessarily agree, but I think the benefit of the clearer program structure exceeds the disadvantage of not being able to do some tricks. That's one of the reasons why PHP doesn't have some things that other languages might have, such as nested classes, multiple inheritance or closures. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On 7/12/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > Similarly, allowing multiple namespaces per file does not limit the > developer in any way. Not allowing them does. I always thought a > language should be designed to empower it's developers, not get in > their way. My opinion is that sometimes language *should* "get in the way" - if the developer is trying to do a wrong thing. Doing things right should be easy, doing things wrong should be hard. I agree that this means we should choose some definitions for right and wrong, and not everybody would necessarily agree, but I think the benefit of the clearer program structure exceeds the disadvantage of not being able to do some tricks. That's one of the reasons why PHP doesn't have some things that other languages might have, such as nested classes, multiple inheritance or closures. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Since everyone has different opinions, we could throw off a vote and see what the voice of the community ends up in (A tie? :O) -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
As someone that has long clamoured for namespaces in PHP, I have to say
that this proposal by Dmitry is exactly what I & others have been hoping
for in PHP. Thanks, Dmitry, for creating this patch. I'm sure there
are going to be some peculiarities that need to be sorted out, but I
can't wait until we can start writing code to use this! I am confidentl
that this is something that will be embraced by the OOP PHP community as
soon as it is available.
Hans
Andrei Zmievski wrote:
> I love this. Let's ship it.
>
> -Andrei
>
>
> On Jul 5, 2007, at 6:49 AM, Dmitry Stogov wrote:
>
>> I think the following example is much better, however I am not sure
>> it's a
>> right direction. Namespaces are intended to declare names that can
>> conflict
>> with names from other namespaces (including global namespace), do I am
>> not
>> sure that we need special keyword for internal functions.
>>
>> We'll think little bit more. Anyway thank you for feedback and idea.
>>
>> > namespace UTF8;
>>
>> overloaded class Exception {
>> }
>>
>> overloaded function strlen() {
>> }
>> ?>
>>
>> Thanks. Dmitry.
>>
>>> -Original Message-
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] On Behalf Of David Coallier
>>> Sent: Thursday, July 05, 2007 5:35 PM
>>> To: Stefan Priebsch
>>> Cc: Dmitry Stogov; PHP internals
>>> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>>>
>>>
>>> On 7/5/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
>>>> David Coallier schrieb:
>>>>> I would probably be in favor of throwing a notice or a
>>> warning when
>>>>> someone modifies a built-in function (or even throw an exception)
>>>>> and that way as soon as you do such thing you would know
>>> right away
>>>>> that you modified something and you would know where the
>>>>> modification happened which would make things much easier
>>> for people
>>>>> developing and debugging applications.
>>>>
>>>> The problem is that this kind of overloading makes a nice
>>> feature as
>>>> well. This is runied by throwing an exception, and cautious
>>> developers
>>>> will at least get nervous when they see a notice.
>>>>
>>>> I could imagine that by adding something like "overrides foo()" or
>>>> "overloads foo()" to a function/method declaration the
>>> developer could
>>>> make clear that he willingly overrides a built-in function, and if
>>>> this is missing, an exception is being thrown. This may be a little
>>>> over the top, however.
>>>>
>>>
>>> Yep I see what you mean.. could even be something like:
>>>
>>> namespace UTF8;
>>>
>>> overrides {
>>> strlen();
>>> strcmp();
>>> }
>>>
>>> function strlen($string)
>>> {
>>> return strlen($string) + 666; // This is just an example ! } ...
>>>
>>>
>>> I kinda like the overrides part, however I wonder if people
>>> will actually use it.. Oh well.. my two cents are now gone.
>>>
>>>
>>>> Kind regards,
>>>>
>>>> Stefan
>>>>
>>>> --
>>>>> e-novative> - We make IT work for you.
>>>>
>>>> e-novative GmbH - HR: Amtsgericht München HRB 139407
>>>> Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
>>>>
>>>> http://www.e-novative.de
>>>>
>>>
>>>
>>>
>>> --
>>> David Coallier,
>>> Founder & Software Architect,
>>> Agora Production (http://agoraproduction.com)
>>> 51.42.06.70.18
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
The patch is already committed to the HEAD.
Dmitry.
> -Original Message-
> From: Hans Lellelid [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 15, 2007 4:37 AM
> Cc: Dmitry Stogov; 'PHP internals'
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
> As someone that has long clamoured for namespaces in PHP, I
> have to say that this proposal by Dmitry is exactly what I &
> others have been hoping for in PHP. Thanks, Dmitry, for
> creating this patch. I'm sure there are going to be some
> peculiarities that need to be sorted out, but I can't wait
> until we can start writing code to use this! I am confidentl
> that this is something that will be embraced by the OOP PHP
> community as soon as it is available.
>
> Hans
>
> Andrei Zmievski wrote:
> > I love this. Let's ship it.
> >
> > -Andrei
> >
> >
> > On Jul 5, 2007, at 6:49 AM, Dmitry Stogov wrote:
> >
> >> I think the following example is much better, however I am
> not sure
> >> it's a right direction. Namespaces are intended to declare
> names that
> >> can conflict
> >> with names from other namespaces (including global
> namespace), do I am
> >> not
> >> sure that we need special keyword for internal functions.
> >>
> >> We'll think little bit more. Anyway thank you for feedback
> and idea.
> >>
> >> >> namespace UTF8;
> >>
> >> overloaded class Exception {
> >> }
> >>
> >> overloaded function strlen() {
> >> }
> >> ?>
> >>
> >> Thanks. Dmitry.
> >>
> >>> -Original Message-
> >>> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> >>> Behalf Of David Coallier
> >>> Sent: Thursday, July 05, 2007 5:35 PM
> >>> To: Stefan Priebsch
> >>> Cc: Dmitry Stogov; PHP internals
> >>> Subject: Re: [PHP-DEV] Simple Namespace Proposal
> >>>
> >>>
> >>> On 7/5/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> >>>> David Coallier schrieb:
> >>>>> I would probably be in favor of throwing a notice or a
> >>> warning when
> >>>>> someone modifies a built-in function (or even throw an
> exception)
> >>>>> and that way as soon as you do such thing you would know
> >>> right away
> >>>>> that you modified something and you would know where the
> >>>>> modification happened which would make things much easier
> >>> for people
> >>>>> developing and debugging applications.
> >>>>
> >>>> The problem is that this kind of overloading makes a nice
> >>> feature as
> >>>> well. This is runied by throwing an exception, and cautious
> >>> developers
> >>>> will at least get nervous when they see a notice.
> >>>>
> >>>> I could imagine that by adding something like "overrides
> foo()" or
> >>>> "overloads foo()" to a function/method declaration the
> >>> developer could
> >>>> make clear that he willingly overrides a built-in
> function, and if
> >>>> this is missing, an exception is being thrown. This may
> be a little
> >>>> over the top, however.
> >>>>
> >>>
> >>> Yep I see what you mean.. could even be something like:
> >>>
> >>> namespace UTF8;
> >>>
> >>> overrides {
> >>> strlen();
> >>> strcmp();
> >>> }
> >>>
> >>> function strlen($string)
> >>> {
> >>> return strlen($string) + 666; // This is just an
> example ! } ...
> >>>
> >>>
> >>> I kinda like the overrides part, however I wonder if people will
> >>> actually use it.. Oh well.. my two cents are now gone.
> >>>
> >>>
> >>>> Kind regards,
> >>>>
> >>>> Stefan
> >>>>
> >>>> --
> >>>>> e-novative> - We make IT work for you.
> >>>>
> >>>> e-novative GmbH - HR: Amtsgericht München HRB 139407
> >>>> Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
> >>>>
> >>>> http://www.e-novative.de
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> David Coallier,
> >>> Founder & Software Architect,
> >>> Agora Production (http://agoraproduction.com)
> >>> 51.42.06.70.18
> >>>
> >>> --
> >>> PHP Internals - PHP Runtime Development Mailing List
> >>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Good stuff
On 7/15/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
The patch is already committed to the HEAD.
Dmitry.
> -Original Message-
> From: Hans Lellelid [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 15, 2007 4:37 AM
> Cc: Dmitry Stogov; 'PHP internals'
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
> As someone that has long clamoured for namespaces in PHP, I
> have to say that this proposal by Dmitry is exactly what I &
> others have been hoping for in PHP. Thanks, Dmitry, for
> creating this patch. I'm sure there are going to be some
> peculiarities that need to be sorted out, but I can't wait
> until we can start writing code to use this! I am confidentl
> that this is something that will be embraced by the OOP PHP
> community as soon as it is available.
>
> Hans
>
> Andrei Zmievski wrote:
> > I love this. Let's ship it.
> >
> > -Andrei
> >
> >
> > On Jul 5, 2007, at 6:49 AM, Dmitry Stogov wrote:
> >
> >> I think the following example is much better, however I am
> not sure
> >> it's a right direction. Namespaces are intended to declare
> names that
> >> can conflict
> >> with names from other namespaces (including global
> namespace), do I am
> >> not
> >> sure that we need special keyword for internal functions.
> >>
> >> We'll think little bit more. Anyway thank you for feedback
> and idea.
> >>
> >> >> namespace UTF8;
> >>
> >> overloaded class Exception {
> >> }
> >>
> >> overloaded function strlen() {
> >> }
> >> ?>
> >>
> >> Thanks. Dmitry.
> >>
> >>> -Original Message-
> >>> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> >>> Behalf Of David Coallier
> >>> Sent: Thursday, July 05, 2007 5:35 PM
> >>> To: Stefan Priebsch
> >>> Cc: Dmitry Stogov; PHP internals
> >>> Subject: Re: [PHP-DEV] Simple Namespace Proposal
> >>>
> >>>
> >>> On 7/5/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> >>>> David Coallier schrieb:
> >>>>> I would probably be in favor of throwing a notice or a
> >>> warning when
> >>>>> someone modifies a built-in function (or even throw an
> exception)
> >>>>> and that way as soon as you do such thing you would know
> >>> right away
> >>>>> that you modified something and you would know where the
> >>>>> modification happened which would make things much easier
> >>> for people
> >>>>> developing and debugging applications.
> >>>>
> >>>> The problem is that this kind of overloading makes a nice
> >>> feature as
> >>>> well. This is runied by throwing an exception, and cautious
> >>> developers
> >>>> will at least get nervous when they see a notice.
> >>>>
> >>>> I could imagine that by adding something like "overrides
> foo()" or
> >>>> "overloads foo()" to a function/method declaration the
> >>> developer could
> >>>> make clear that he willingly overrides a built-in
> function, and if
> >>>> this is missing, an exception is being thrown. This may
> be a little
> >>>> over the top, however.
> >>>>
> >>>
> >>> Yep I see what you mean.. could even be something like:
> >>>
> >>> namespace UTF8;
> >>>
> >>> overrides {
> >>> strlen();
> >>> strcmp();
> >>> }
> >>>
> >>> function strlen($string)
> >>> {
> >>> return strlen($string) + 666; // This is just an
> example ! } ...
> >>>
> >>>
> >>> I kinda like the overrides part, however I wonder if people will
> >>> actually use it.. Oh well.. my two cents are now gone.
> >>>
> >>>
> >>>> Kind regards,
> >>>>
> >>>> Stefan
> >>>>
> >>>> --
> >>>>> e-novative> - We make IT work for you.
> >>>>
> >>>> e-novative GmbH - HR: Amtsgericht München HRB 139407
> >>>> Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
> >>>>
> >>>> http://www.e-novative.de
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> David Coallier,
> >>> Founder & Software Architect,
> >>> Agora Production (http://agoraproduction.com)
> >>> 51.42.06.70.18
> >>>
> >>> --
> >>> PHP Internals - PHP Runtime Development Mailing List
> >>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
Hi, I read whole discussion and I'd like to share my opinion. > Similarly, allowing multiple namespaces per file does not limit the > developer in any way. Not allowing them does. I always thought a > language should be designed to empower it's developers, not get in > their way. My opinion is that sometimes language *should* "get in the way" - if the developer is trying to do a wrong thing. Doing things right should be easy, doing things wrong should be hard. I agree that this means we should choose some definitions for right and wrong, and not everybody would necessarily agree, but I think the benefit of the clearer program structure exceeds the disadvantage of not being able to do some tricks. That's one of the reasons why PHP doesn't have some things that other languages might have, such as nested classes, multiple inheritance or closures. I agree with Andrew Minerd. Language shouldn't get in developers way. If its too hard to implement then let it be. Most developers can live with that I guess. However if the only reason for this is so called "clearer program structure" then I don't think this limit is reasonable. There's no such thing as absolutely "wrong thing to do". The thing that is "wrong thing to do" in one situation may be a "good thing to do" in other. One size *does not* fit all. The other thing that bothers me is namespaces nesting. It was said that namespaces nesting is not supported. Then I'm missing a point in having namespace named "A::B". Lets say I have three files: a.php: b.php: index.php: If this works then we have a nested namespace here. The only thing that's missing is [commented] foo() call in A::B::bar() to be correctly resolve to A::foo() as now it would resolve to built-in function foo() if I understand it correctly. Now if this does not work then whats the point in having namespace "A::B" instead of "A_B"? IMHO this brings more confusion then clearness. Regards, Giedrius -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Dmitry Stogov wrote: The patch is already committed to the HEAD. Dmitry. There seem to be some problems with importing across files. The tests currently in CVS are all in single files so it's not immediately obvious. When a namespace is declared in one file and imported in another, classes must be addressed absolutely either in the import or when used, and functions must be addressed absolutely when used, irrespective of imports. I've attached some phpt files to test this, but here's a simple illustration: foo.php: bar.php: Arpad --TEST-- 034: Namespace import function across files --FILE-- --TEST-- 035: Namespace import function alias across files --FILE-- --TEST-- 033: Namespace import across files --FILE-- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Arpad Ray wrote:
> I've attached some phpt files to test this, but here's a simple
> illustration:
>
> foo.php:
> namespace foo;
> function foobar() { }
> class Foobaz { }
> ?>
>
> bar.php:
> import foo;
> foobar(); // error
> new Foobaz; // error
> foo::foobar(); // ok
> new foo::Foobaz; // ok
>
> import foo::foobar;
> import foo::Foobaz;
> foobar(); // error
> new Foobaz; // ok
>
> import foo::foobar as foobar2;
> foobar2(); // error
> ?>
Is this what other languages try to solve with:
import foo::*;
(untested, I don't know if this is implemented) ?
Maybe ..,
- - Markus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGmklP1nS0RcInK9ARAiv1AKC8JuXe3fVBy1VGv3chqjMImKKbJgCgn5NW
/V3kGzqXYC08d8yJ6nbpYv0=
=5sq0
-END PGP SIGNATURE-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
I've attached some phpt files to test this, but here's a simple illustration: foo.php: bar.php: That's how it's supposed to work. Import foo is a no-op. import foo::foobar; import foo::Foobaz; foobar(); // error new Foobaz; // ok Well, this one might be an error - I think direct import of functions might be OK. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Is this what other languages try to solve with: import foo::*; (untested, I don't know if this is implemented) ? No, not implemented and probably won't be. It isn't necessary for solving the long names problem and in fact brings the whole same problem back again by putting all the names back into global namespace. If you have one-level space, it's nothing wrong with writing foo::bar. The import ensures you never have to write more than two ::'s (space::class::function), but we didn't try to get it down to one :: because it's too much trouble. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
The other thing that bothers me is namespaces nesting. It was said that namespaces nesting is not supported. Then I'm missing a point in having namespace named "A::B". The same reason some people write $a = f($z, $t) and some write $parsed_template = template_parser($template, $data_values) :) Lets say I have three files: a.php: b.php: index.php: import A is a no-op. You do import A::B and then you can do B::bar. import N means "something that is named N can now be referred only by it's 'last name' last(N), last name being last segment of the long name". If you have short names, you don't need namespaces, but if you have names like PEAR::DB::Record::Type::Modifier::Exception, you probably do :) Now if this does not work then whats the point in having namespace "A::B" instead of "A_B"? IMHO this brings more confusion then clearness. The point is you can a) omit namespace prefix inside namespace and b) use just B (or C if you wish) instead of A::B outside, once you did import. As I said, with long names it makes sense, with short ones you are OK without it. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On 7/16/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> The other thing that bothers me is namespaces nesting. It was said
> that namespaces
> nesting is not supported. Then I'm missing a point in having namespace
> named "A::B".
The same reason some people write $a = f($z, $t) and some write
$parsed_template = template_parser($template, $data_values) :)
I wasn't talking about a short/long names :-)
I was talking about a separator inside a namespace name.
> Lets say I have three files:
>
> a.php:
> namespace A;
>
> function foo()
> {
> }
> ?>
>
> b.php:
> namespace A::B;
>
> function bar()
> {
>//foo();
> }
> ?>
>
> index.php:
> require 'a.php';
> require 'b.php';
>
> import A;
> foo(); // should call A::foo(), right?
> B::bar(); // will this call A::B::bar()?
> ?>
import A is a no-op. You do import A::B and then you can do B::bar.
import N means "something that is named N can now be referred only by
it's 'last name' last(N), last name being last segment of the long
name". If you have short names, you don't need namespaces, but if you
have names like PEAR::DB::Record::Type::Modifier::Exception, you
probably do :)
> Now if this does not work then whats the point in having namespace
> "A::B" instead of "A_B"? IMHO this brings more confusion then
> clearness.
The point is you can a) omit namespace prefix inside namespace and b)
use just B (or C if you wish) instead of A::B outside, once you did
import. As I said, with long names it makes sense, with short ones you
are OK without it.
a) I was talking about namespace name "A_B" not class/function name.
b) So as far as I understand "import" doesn't actually *import* names
from specified
namespace to the current one but just renames long namespace name to a
shorter one. And if I get it right the separator in the namespace name
is allowed
and required only to express default name when importing without "as".
Am I right?
Regards,
Giedrius
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
As usual, consider Hans' opinion identical to mine ;) Nice job, can't
wait for it being out in the wild.
David
Am 15.07.2007 um 02:37 schrieb Hans Lellelid:
As someone that has long clamoured for namespaces in PHP, I have to
say
that this proposal by Dmitry is exactly what I & others have been
hoping
for in PHP. Thanks, Dmitry, for creating this patch. I'm sure there
are going to be some peculiarities that need to be sorted out, but I
can't wait until we can start writing code to use this! I am
confidentl
that this is something that will be embraced by the OOP PHP
community as
soon as it is available.
Hans
Andrei Zmievski wrote:
I love this. Let's ship it.
-Andrei
On Jul 5, 2007, at 6:49 AM, Dmitry Stogov wrote:
I think the following example is much better, however I am not sure
it's a
right direction. Namespaces are intended to declare names that can
conflict
with names from other namespaces (including global namespace), do
I am
not
sure that we need special keyword for internal functions.
We'll think little bit more. Anyway thank you for feedback and idea.
Thanks. Dmitry.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Coallier
Sent: Thursday, July 05, 2007 5:35 PM
To: Stefan Priebsch
Cc: Dmitry Stogov; PHP internals
Subject: Re: [PHP-DEV] Simple Namespace Proposal
On 7/5/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
David Coallier schrieb:
I would probably be in favor of throwing a notice or a
warning when
someone modifies a built-in function (or even throw an exception)
and that way as soon as you do such thing you would know
right away
that you modified something and you would know where the
modification happened which would make things much easier
for people
developing and debugging applications.
The problem is that this kind of overloading makes a nice
feature as
well. This is runied by throwing an exception, and cautious
developers
will at least get nervous when they see a notice.
I could imagine that by adding something like "overrides foo()" or
"overloads foo()" to a function/method declaration the
developer could
make clear that he willingly overrides a built-in function, and if
this is missing, an exception is being thrown. This may be a
little
over the top, however.
Yep I see what you mean.. could even be something like:
namespace UTF8;
overrides {
strlen();
strcmp();
}
function strlen($string)
{
return strlen($string) + 666; // This is just an
example ! } ...
I kinda like the overrides part, however I wonder if people
will actually use it.. Oh well.. my two cents are now gone.
Kind regards,
Stefan
--
e-novative> - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
a) I was talking about namespace name "A_B" not class/function name. _ is legal identifier character, so it would not be a good idea to use it as a separator. :: on the other side is natural scope separator in many languages. But I'm rather reluctant to start the "my separator is better than yours" thread for the 42th time :) b) So as far as I understand "import" doesn't actually *import* names from specified namespace to the current one but just renames long namespace name to a shorter one. And if I get it right the separator in the namespace name is allowed and required only to express default name when importing without "as". Am I right? Not exactly. It does import, but not names just one name - the very same name it has as an argument. The :: is used to join components of the name. Note that you can also do: import Foo::XML as myXML; $a = new myXML::Data::Document(); if you wish so. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
On 7/16/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > a) I was talking about namespace name "A_B" not class/function name. _ is legal identifier character, so it would not be a good idea to use it as a separator. :: on the other side is natural scope separator in many languages. But I'm rather reluctant to start the "my separator is better than yours" thread for the 42th time :) Me neither :-) :: is perfectly good for me. I just missed the point of having it more then once if it's only purpose is to separate default short name part from whole name. > b) So as far as I understand "import" doesn't actually *import* names > from specified > namespace to the current one but just renames long namespace name to a > shorter one. And if I get it right the separator in the namespace name > is allowed > and required only to express default name when importing without "as". > Am I right? Not exactly. It does import, but not names just one name - the very same name it has as an argument. The :: is used to join components of the name. Note that you can also do: import Foo::XML as myXML; $a = new myXML::Data::Document(); Now that explains a lot :-) If I get it right I can have namespaces A::B::C and A::B::D then create an alias for A::B with "import A::B" and use B::C::foo() and B::D::foo() in that file. Thats nice. Looks like namespace nesting though it isn't :-) Regards, Giedrius -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Sorry for posting it so late, but I would like to clarify the things
in my head. I hope a final post with compiled definitions and final
decisions is useful for other people interested in this new
functionality.
1 - The official namespace support will not use curly braces? Never or
can be in the future?
IMHO, I am +1 in this subject. A quick explanation why I am a brace's
fan. How do you declare a class?
wrote:
As usual, consider Hans' opinion identical to mine ;) Nice job, can't
wait for it being out in the wild.
David
Am 15.07.2007 um 02:37 schrieb Hans Lellelid:
> As someone that has long clamoured for namespaces in PHP, I have to
> say
> that this proposal by Dmitry is exactly what I & others have been
> hoping
> for in PHP. Thanks, Dmitry, for creating this patch. I'm sure there
> are going to be some peculiarities that need to be sorted out, but I
> can't wait until we can start writing code to use this! I am
> confidentl
> that this is something that will be embraced by the OOP PHP
> community as
> soon as it is available.
>
> Hans
>
> Andrei Zmievski wrote:
>> I love this. Let's ship it.
>>
>> -Andrei
>>
>>
>> On Jul 5, 2007, at 6:49 AM, Dmitry Stogov wrote:
>>
>>> I think the following example is much better, however I am not sure
>>> it's a
>>> right direction. Namespaces are intended to declare names that can
>>> conflict
>>> with names from other namespaces (including global namespace), do
>>> I am
>>> not
>>> sure that we need special keyword for internal functions.
>>>
>>> We'll think little bit more. Anyway thank you for feedback and idea.
>>>
>>> >> namespace UTF8;
>>>
>>> overloaded class Exception {
>>> }
>>>
>>> overloaded function strlen() {
>>> }
>>> ?>
>>>
>>> Thanks. Dmitry.
>>>
>>>> -Original Message-
>>>> From: [EMAIL PROTECTED]
>>>> [mailto:[EMAIL PROTECTED] On Behalf Of David Coallier
>>>> Sent: Thursday, July 05, 2007 5:35 PM
>>>> To: Stefan Priebsch
>>>> Cc: Dmitry Stogov; PHP internals
>>>> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>>>>
>>>>
>>>> On 7/5/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
>>>>> David Coallier schrieb:
>>>>>> I would probably be in favor of throwing a notice or a
>>>> warning when
>>>>>> someone modifies a built-in function (or even throw an exception)
>>>>>> and that way as soon as you do such thing you would know
>>>> right away
>>>>>> that you modified something and you would know where the
>>>>>> modification happened which would make things much easier
>>>> for people
>>>>>> developing and debugging applications.
>>>>>
>>>>> The problem is that this kind of overloading makes a nice
>>>> feature as
>>>>> well. This is runied by throwing an exception, and cautious
>>>> developers
>>>>> will at least get nervous when they see a notice.
>>>>>
>>>>> I could imagine that by adding something like "overrides foo()" or
>>>>> "overloads foo()" to a function/method declaration the
>>>> developer could
>>>>> make clear that he willingly overrides a built-in function, and if
>>>>> this is missing, an exception is being thrown. This may be a
>>>>> little
>>>>> over the top, however.
>>>>>
>>>>
>>>> Yep I see what you mean.. could even be something like:
>>>>
>>>> namespace UTF8;
>>>>
>>>> overrides {
>>>> strlen();
>>>> strcmp();
>>>> }
>>>>
>>>> function strlen($string)
>>>> {
>>>> return strlen($string) + 666; // This is just an
>>>> example ! } ...
>>>>
>>>>
>>>> I kinda like the overrides part, however I wonder if people
>>>> will actually use it.. Oh well.. my two cents are now gone.
>>>>
>>>>
>>>>> Kind regards,
>>>>>
>>>>> Stefan
>>>>>
>>>>> --
>>>>>> e-novative> - We make IT work for you.
>>>>>
>>>>> e-novative GmbH - HR: Amtsgericht München HRB 139407
>>>>> Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
>>>>>
>>>>> http://www.e-novative.de
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> David Coallier,
>>>> Founder & Software Architect,
>>>> Agora Production (http://agoraproduction.com)
>>>> 51.42.06.70.18
>>>>
>>>> --
>>>> PHP Internals - PHP Runtime Development Mailing List
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: [EMAIL PROTECTED]
URL: http://blog.bisna.com
São Carlos - SP/Brazil
RE: [PHP-DEV] Simple Namespace Proposal
> 3 - How will PHP behavior on a situation that you have a naming conflict?
>
> Something like...
>
> class Bar { ... }
>
> namespace Foo {
> class Bar { ... }
> }
>
> import Foo;
>
> $b = new Bar();
Well, PHP's namespaces don't behave like every other language I've ever used
that supports namespaces. So, the code snippet you used here wouldn't work,
anyway.
Jeremy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
1 - The official namespace support will not use curly braces? Never or
can be in the future?
Nobody knows what will be is the future. As of now, the autors do not
see a compelling reason to support more than once namespace per file.
I suggest to get things standard-ized. If a class uses braces,
functions uses braces, why not use braces for namespaces...?
The same reason why file don't use braces, filenames don't have braces,
directories don't have braces, etc. Namespaces are different. Not
everything should look exactly alike - we are not LISP.
I'll give you an example... PHP Doctrine package has a lot of files,
hundreds... there is a way to compile it in a single file, to save
some memory usage for including these files. Including a single file
Putting all code together in the same file rarely saves any significant
amount of memory and leads to a very messy code. Of course, it's your
application and your decision, but I don't see any reason to promote
such style on the language level. Anyway, if you can do with everything
in single file, I think having single namespace won't hurt.
2 - Overwrite will be implemented?
Something like: overwrite function strlen( ... ) { ... }
What it's supposed to do?
For 100th time, import Foo is a no-op. I'm thinking about prohibiting it
at all... If you do import Foo::bar you'll get an error if Bar is
already defined.
4 - Will namespaces support anything else than functions and classes
(like constants, for example)?
Not likely, since there's no such thing as free-form constant. Though,
in fact, we might add one (i.e. const X = 'foo' which is define('X',
'foo')) ... But, if you need a constant, why not put it into a class?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
> For 100th time, import Foo is a no-op. I'm thinking about prohibiting it > at all... If you do import Foo::bar you'll get an error if Bar is already > defined. I'm still trying to figure out why you think this is an acceptable implementation of namespaces. This isn't namespaces at all. This is barely an acceptable method of shortening classnames. What are we, as developers, supposed to do on a namespace that has a particularly large number of available classes? Import them all individually? So, I now need to go from having a file that includes necessary libraries to a file that needs to import them all? That's REAL intelligent design, right there. --- Jeremy Privett Software Developer Peak8 Solutions -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
