Hi All,
I remember reading that both nested classes and namespaces would be
available in PHP5. I know that namespaces got canceled (much sadness...),
however, I *thought* that nested classes were still an option.
However, I am coming up dry looking for information on how to do this, and
the most recent references I am able to find to nested classes in PHP are
dated 2003. And they all say the same thing: sorry, can't do that.
So, it's not possible? Is that the end of the matter?
Any suggestions for attempting to implement namespaces in PHP5? Some sort
of hack or workaround?
Thanks for any thoughts.
-jb
26  29428 
On Thu, 20 Jan 2005 22:21:16 GMT, "Joshua Beall"
<jb****@donotspam.remove.me.heraldic.us> wrote: I remember reading that both nested classes and namespaces would be
available in PHP5. I know that namespaces got canceled (much sadness...),
however, I *thought* that nested classes were still an option.
No, they got the chop too. http://cvs.php.net/co.php/ZendEngine2/ChangeLog?r=1.622
Search for "nested class" on that page - there's an entry for zend.c stating
"Nested classes are gone."
--
Andy Hassall / <an**@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool
"Joshua Beall" <jb****@donotspam.remove.me.heraldic.us> wrote in message
news:w9WHd.2425$Hg6.2404@trnddc09... Hi All,
I remember reading that both nested classes and namespaces would be
available in PHP5. I know that namespaces got canceled (much sadness...),
however, I *thought* that nested classes were still an option.
However, I am coming up dry looking for information on how to do this, and
the most recent references I am able to find to nested classes in PHP are
dated 2003. And they all say the same thing: sorry, can't do that.
So, it's not possible? Is that the end of the matter?
Any suggestions for attempting to implement namespaces in PHP5? Some sort
of hack or workaround?
Thanks for any thoughts.
-jb
The workaround is to use an underscore.
What on earth is so special about a nested class? If you can include() a
class definition from within a class, then instantiate it, is that not good
enough?
--
Tony Marston http://www.tonymarston.net
"Joshua Beall" <jb****@donotspam.remove.me.heraldic.us> wrote in message
news:w9WHd.2425$Hg6.2404@trnddc09... Hi All,
I remember reading that both nested classes and namespaces would be
available in PHP5. I know that namespaces got canceled (much sadness...),
however, I *thought* that nested classes were still an option.
However, I am coming up dry looking for information on how to do this, and
the most recent references I am able to find to nested classes in PHP are
dated 2003. And they all say the same thing: sorry, can't do that.
So, it's not possible? Is that the end of the matter?
Any suggestions for attempting to implement namespaces in PHP5? Some sort
of hack or workaround?
Thanks for any thoughts.
-jb
Hi,
Using $_SESSION with a sub array would give you a a namespace.
With regard to obects within objects then it indicates a design problem.
Declaring an object within an object can be done, but the way to do it is
by defining an object as a class in itself and then allowing the container
class to have an array of objects.
Pseudo code
class (I am a invoice header class) {
class property (I am an array containing 0->n detail line objects)
}
class (I am an invoice detail line class) {
}
On Thu, 20 Jan 2005 22:21:16 +0000, Joshua Beall wrote: Hi All,
I remember reading that both nested classes and namespaces would be
available in PHP5. I know that namespaces got canceled (much sadness...),
however, I *thought* that nested classes were still an option.
However, I am coming up dry looking for information on how to do this, and
the most recent references I am able to find to nested classes in PHP are
dated 2003. And they all say the same thing: sorry, can't do that.
So, it's not possible? Is that the end of the matter?
Any suggestions for attempting to implement namespaces in PHP5? Some sort
of hack or workaround?
Thanks for any thoughts.
-jb
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message
news:cs*******************@news.demon.co.uk... What on earth is so special about a nested class? If you can include() a
class definition from within a class, then instantiate it, is that not
good enough?
--
Tony Marston
Sometimes you have a class that has no meaning/usefulness outside of it's
context in a parent class. Thus, it is polluting the global namespace with
information that will never be used (outside of that one specific class) to
define it in the global namespace.
Of course in most PHP apps this is not a problem because you don't have a
massive number of classes... but it would be nice to have nested classes or
namespaces.
-jb
"Joshua Beall" <jb****@donotspam.remove.me.heraldic.us> wrote in message
news:SO8Id.5740$J6.3455@trnddc02... "Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message
news:cs*******************@news.demon.co.uk... What on earth is so special about a nested class? If you can include() a
class definition from within a class, then instantiate it, is that not
good enough?
--
Tony Marston
Sometimes you have a class that has no meaning/usefulness outside of it's
context in a parent class. Thus, it is polluting the global namespace
with information that will never be used (outside of that one specific
class) to define it in the global namespace.
I disagree that this is any kind of an issue. You may have a single class
definition, but none of the properties or methods of that class will clash
with anything else, so there is no problem.
Of course in most PHP apps this is not a problem because you don't have a
massive number of classes...
It does not matter how many classes you have in your entire application.
Each HTTP request is for a single page, therefore you need only load those
classes which are sufficient to satisfy that single request.
but it would be nice to have nested classes or namespaces.
The benefit of nested classes is not worth the effort. It is the same for
namespaces. I have programmed in languages for the past 25+ years without
ever using namespaces, so their lack of appearance in PHP is not a problem
for me. Exactly what problem do they solve, if any?
--
Tony Marston http://www.tonymarston.net
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message
news:cs*******************@news.demon.co.uk... but it would be nice to have nested classes or namespaces.
The benefit of nested classes is not worth the effort. It is the same for
namespaces. I have programmed in languages for the past 25+ years without
ever using namespaces, so their lack of appearance in PHP is not a problem
for me. Exactly what problem do they solve, if any?
Problem? I'm not sure they solve any sort real problem... But they make it
neater for a human being to look at your code and see what things are
grouped together.
>"Chris Newey" <newey...@hotmail.com> Using $_SESSION with a sub array would give you a a namespace.
?
With regard to obects within objects then it indicates a design
problem. Declaring an object within an object can be done, but the way to do
it is by defining an object as a class in itself and then allowing the
container class to have an array of objects.
I'm new to this group (I work with PHP, but my background is mostly
C++, Java, etc.), and this is the first thread I read in this group,
and either the terminology used in "PHP land" is rather different from
what I'm used to (not that likely, we subscribe to "PHP Architect", as
well), or there seems to be some confusion of class and object, here.
OP asked for the possibility of defining a class within another class
(a nested class). If that nested class is only available to the
enclosing class, then there wouldn't be a need for a new syntax for
accessing it from the outside (as in "new outer::inner(...)").
Having a nested class doesn't mean nesting objects inside of each
other: that's a misunderstanding. It's simply an issue of scope: the
inner class might only be accessible to the enclosing class.
Secondly, this is not indicative of a design error, and to the contrary
may be good design, as, as OP said, it avoids polluting the global
namespace with classes that are only used locally. For example, if you
have a container class, then the iterator might be a nested class of
it, as the container is the only class needing to be able to
instantiate it.
Thirdly, if you really meant nesting objects, rather than nesting
classes, then do you really mean that having an object with instance
variables (nested objects) indicates a design error? That's nonsense.
Regards,
Terje
<ts*******@hotmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com... OP asked for the possibility of defining a class within another class
(a nested class). If that nested class is only available to the
enclosing class, then there wouldn't be a need for a new syntax for
accessing it from the outside (as in "new outer::inner(...)").
Glad there's somebody around here who doesn't think I'm nuts!
My background is C++ with a tiny bit of Java, too. Probably affects my
thinking on this matter.
<ts*******@hotmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com... Secondly, this is not indicative of a design error, and to the contrary
may be good design, as, as OP said, it avoids polluting the global
namespace with classes that are only used locally. For example, if you
have a container class, then the iterator might be a nested class of
it, as the container is the only class needing to be able to
instantiate it.
Namespace pollution is such a dumb metaphor. Do classes breath namespace?
No. Do functions drink namespace? No. How the hell do you pollute an
abstract construct? 476742387432. Woohoo! I just polluted the integer space
with a number that concerns no one. So sue me.
"Chung Leong" <ch***********@hotmail.com> wrote in message
news:05********************@comcast.com... <ts*******@hotmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com... Secondly, this is not indicative of a design error, and to the contrary
may be good design, as, as OP said, it avoids polluting the global
namespace with classes that are only used locally. For example, if you
have a container class, then the iterator might be a nested class of
it, as the container is the only class needing to be able to
instantiate it.
Namespace pollution is such a dumb metaphor. Do classes breath namespace?
No. Do functions drink namespace? No. How the hell do you pollute an
abstract construct?
It refers to filling a namespace with both desired and undesired names,
similar to how e.g. water may be polluted, by containing both desired and
undesired substances. Therefore "namespace pollution". It's not more
mystical than that. Did it help?
Regards,
Terje
"Terje Slettebø" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no... "Chung Leong" <ch***********@hotmail.com> wrote in message
news:05********************@comcast.com... <ts*******@hotmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com... > Secondly, this is not indicative of a design error, and to the contrary
> may be good design, as, as OP said, it avoids polluting the global
> namespace with classes that are only used locally. For example, if you
> have a container class, then the iterator might be a nested class of
> it, as the container is the only class needing to be able to
> instantiate it.
Namespace pollution is such a dumb metaphor. Do classes breath namespace?
No. Do functions drink namespace? No. How the hell do you pollute an
abstract construct?
It refers to filling a namespace with both desired and undesired names,
similar to how e.g. water may be polluted, by containing both desired and
undesired substances. Therefore "namespace pollution". It's not more
mystical than that. Did it help?
So the mere fact that all the standard PHP functions are *there* without
having to be specifically loaded implies that their function names are
polluting the global namespace? What a ridiculous idea!
I do not see what sort of a problem this "namespace pollution" causes,
therefore IMHO it does not need a solution.
--
Tony Marston http://www.tonymarston.net
Try this:
$className = 'MyClass';
$methodName = 'MyMethod'
$result = $$className::$methodName();
Tbe $className variable must be a $$ variable.
Regards,
Ramiro
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message
news:cs*******************@news.demon.co.uk...
"Terje Slettebø" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no... "Chung Leong" <ch***********@hotmail.com> wrote in message
Namespace pollution is such a dumb metaphor. Do classes breath
namespace? No. Do functions drink namespace? No. How the hell do you pollute an
abstract construct?
It refers to filling a namespace with both desired and undesired names,
similar to how e.g. water may be polluted, by containing both desired
and undesired substances. Therefore "namespace pollution". It's not more
mystical than that. Did it help?
So the mere fact that all the standard PHP functions are *there* without
having to be specifically loaded implies that their function names are
polluting the global namespace? What a ridiculous idea!
I do not see what sort of a problem this "namespace pollution" causes,
therefore IMHO it does not need a solution.
The point is that you may get name collisions, such as if you try to define
a function with the same name as an existing one. One way to avoid that risk
is to use prefixes, such as "mysql_...", which is used in newer libraries in
PHP, which essentially "simulates" namespaces. With namespaces, you might
use mysql::connect(), for example, instead, and the advantage over prefixes
is that if you're writing code in that namespace, you won't need to use the
prefix to access other members of the namespace. So you avoid name
collisions, and can use the shorter form within the namespace (or if you
declare something like "using namespace mysql;" first, outside the namespace
(as in C++)).
I understand that namespaces were considered, but dropped, during the
development of PHP5. I'll try to find that discussion in the internals list
archive.
Regards,
Terje
"Terje Slettebø" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no...
The point is that you may get name collisions, such as if you try to
define a function with the same name as an existing one. One way to avoid that
risk is to use prefixes, such as "mysql_...", which is used in newer libraries
in PHP, which essentially "simulates" namespaces. With namespaces, you might
use mysql::connect(), for example, instead, and the advantage over
prefixes is that if you're writing code in that namespace, you won't need to use
the prefix to access other members of the namespace. So you avoid name
collisions, and can use the shorter form within the namespace (or if you
declare something like "using namespace mysql;" first, outside the
namespace (as in C++)).
Name collision is one of those purely theoretical problems. If you give your
functions decently descriptive names, it nearly never occurs. There are
thousands of words in the English language after all, each with specific
meaning. When words are combined, the combinations will also have specific
meanings. When I say "Buy a donut," I'm expressing the idea of buying a
donut. That idea is not going to all of a sudden have a namespace collision
with the idea of bitchslapping Bob.
"Terje Slettebø" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no... "Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message
news:cs*******************@news.demon.co.uk...
"Terje Slettebø" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no... > "Chung Leong" <ch***********@hotmail.com> wrote in message
>>
>> Namespace pollution is such a dumb metaphor. Do classes breath namespace? >> No. Do functions drink namespace? No. How the hell do you pollute an
>> abstract construct?
>
> It refers to filling a namespace with both desired and undesired names,
> similar to how e.g. water may be polluted, by containing both desired and > undesired substances. Therefore "namespace pollution". It's not more
> mystical than that. Did it help?
So the mere fact that all the standard PHP functions are *there* without
having to be specifically loaded implies that their function names are
polluting the global namespace? What a ridiculous idea!
I do not see what sort of a problem this "namespace pollution" causes,
therefore IMHO it does not need a solution.
The point is that you may get name collisions, such as if you try to
define
a function with the same name as an existing one.
Then the answer is not to define a function with a name that already exists.
Problem solved.
One way to avoid that risk
is to use prefixes, such as "mysql_...", which is used in newer libraries
in
PHP, which essentially "simulates" namespaces. With namespaces, you might
use mysql::connect(), for example, instead, and the advantage over
prefixes
is that if you're writing code in that namespace, you won't need to use
the
prefix to access other members of the namespace. So you avoid name
collisions, and can use the shorter form within the namespace (or if you
declare something like "using namespace mysql;" first, outside the
namespace
(as in C++)).
I understand that namespaces were considered, but dropped, during the
development of PHP5. I'll try to find that discussion in the internals
list
archive.
From what I remember of that discussion it was considered that the amount of
effort needed to implement namespaces what far too excessive compared with
the benefit.
--
Tony Marston http://www.tonymarston.net
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message
news:ct*******************@news.demon.co.uk...
From what I remember of that discussion it was considered that the amount
of effort needed to implement namespaces what far too excessive compared with
the benefit.
If I remember correctly, namespace was actually implemented. But it caused
performance degradation, so they decided to shelved it.
"Chung Leong" <ch***********@hotmail.com> wrote in message
news:79********************@comcast.com... "Terje Slettebø" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no...
The point is that you may get name collisions, such as if you try to define a function with the same name as an existing one. One way to avoid that
risk is to use prefixes, such as "mysql_...", which is used in newer
libraries in PHP, which essentially "simulates" namespaces. With namespaces, you
might use mysql::connect(), for example, instead, and the advantage over
prefixes is that if you're writing code in that namespace, you won't need to use
the prefix to access other members of the namespace. So you avoid name
collisions, and can use the shorter form within the namespace (or if you
declare something like "using namespace mysql;" first, outside the
namespace (as in C++)).
Name collision is one of those purely theoretical problems.
It may be more of a theoretical problem in PHP than in other languages,
since there's no linking of object files - only the files being included may
have name collisions. Except for the standard library - see below.
However, the possibility of name collisions isn't the only issue; there's
also things like avoiding duplication and very long names: What would you
rather like to write (implementing MySQL-like db-functions in PHP for the
sake of argument :) ):
namespace mysql
{
function connect(...) { ... }
function disconnect(...) { ... }
function query(...) { ... }
// ...
// A zillion more function definitions, here, often calling other
functions within the namespace
}
or:
function mysql_connect(...) { ... }
function mysql_disconnect(...) { ... }
function mysql_query(...) { ... }
// ...
// A zillion more function definitions, here, often calling other functions
within the namespace
I know with myself that I wouldn't miss writing all those "mysql_"... in the
code... :)
If you give your
functions decently descriptive names, it nearly never occurs.
Ah, great. "connect()" is a good name for connecting to a database, no? Does
that mean that all those zillion db-APIs in PHP can call their function
"connect()", then? No? I guess the problem of name collision is less
theoretical than you say.
There are
thousands of words in the English language after all, each with specific
meaning. When words are combined, the combinations will also have specific
meanings.
Yes, and both of these are combinations of words:
mysql_connect()
mysql::connect()
This is not an argument for or against namespaces. When you say we don't
need namespaces, you're really saying that prefixes like this are
preferable, or do you have another suggestion? Thus, it's not about
namespaces or not namespaces; it's about namespaces or ...(the
alternatives).
Regards,
Terje
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message
news:ct*******************@news.demon.co.uk...
"Terje Slettebø" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no...
The point is that you may get name collisions, such as if you try to
define
a function with the same name as an existing one.
Then the answer is not to define a function with a name that already
exists. Problem solved.
Yes, that works fine in toy-applications, where you may have just a few
functions. It may not work so great in a large application with many
functions, where you may not even be aware of all the functions existing
(especially if several people are working on it).
Besides, as mentioned in my reply to Chung Leong, it's not a question of
namespaces or not namespaces, but namespaces or (alternatives). Without
namespaces, prefixes are often used in PHP to avoid name collisions in the
standard library. However, the two solutions are not the same, and I go into
that in the reply to Chung.
Regards,
Terje
.oO(Terje Slettebø) This is not an argument for or against namespaces. When you say we don't
need namespaces, you're really saying that prefixes like this are
preferable, or do you have another suggestion?
Classes.
Micha
"Michael Fesser" <ne*****@gmx.net> wrote in message
news:ta********************************@4ax.com... .oO(Terje Slettebø)
This is not an argument for or against namespaces. When you say we don't
need namespaces, you're really saying that prefixes like this are
preferable, or do you have another suggestion?
Classes.
Yep, that's a reasonable alternative (as OP mentioned in the first posting).
However, uhm, take a look at the subject line: :) If you want to use classes
as namespace, then you can't have any classes nested inside that
"namespace". Also, there's no way to reopen the "namespace" in another file,
or "import" symbols into the current scope.
Regards,
Terje
"Terje Slettebø" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no... It may be more of a theoretical problem in PHP than in other languages,
since there's no linking of object files - only the files being included
may have name collisions. Except for the standard library - see below.
People have little problem building enormously complex programs using C
either. PHP is one example. Apache--another.
As you example shows, you only need namespace when you want to use generic
names for function and classes.
However, the possibility of name collisions isn't the only issue; there's
also things like avoiding duplication and very long names: What would you
rather like to write (implementing MySQL-like db-functions in PHP for the
sake of argument :) ):
People would implement that using classes. But since that's not your point,
I won't go into it. The thrust of you argument is basically that generic
function names are superior to more task-specific function names. I cannot
disagree more. The very purpose of names is to uniquely things and concepts.
The ideal situation is when one function name cooresponds to one
function--and we nearly have that with mysql_connect(). So yes, I would
prefer it and its mysql_* brothers to your generic version by a long shot.
When I write "mysql_connect" in this newsgroup, everyone knows exactly what
function I'm referring. When I google the term "mysql_connect," the
function's man page is the top link and every other result has one thing or
another to do with connecting to a MySQL database. If I use an editor with
autocomplete, "mysql_connect" will pop up with the correct parameter hints
as soon as I've entered "mysql_c." And what does your solution have to
offer? 6 less keys.
This is not an argument for or against namespaces. When you say we don't
need namespaces, you're really saying that prefixes like this are
preferable, or do you have another suggestion? Thus, it's not about
namespaces or not namespaces; it's about namespaces or ...(the
alternatives).
You are treating an essential difference as though it's trivial. A prefix
become part of an inseparable part of the a word. The combination isn't just
the sum of the two parts, but gives rise to a meaning that is distinct. Take
the term "namespace." Does it mean "space" in the context of nomenclature?
Is it space in the namespace of "name"? Of course not. Take away "name" and
the whole concept is lost. The same way with function names. Take away the
part "mysql_" and we're no longing talking about the same piece of code. To
hammer the point home let me say this in allcaps: PREFIXES CANNOT BE
OMITTED. Namespace identifier can be omitted. That very fact is what you
have offered up as the main benefit of using namespace. Don't turn around
now and say that there's really no difference.
"Chung Leong" <ch***********@hotmail.com> wrote in message
news:kY********************@comcast.com... "Terje Slettebø" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no... It may be more of a theoretical problem in PHP than in other languages,
since there's no linking of object files - only the files being included
may have name collisions. Except for the standard library - see below.
People have little problem building enormously complex programs using C
either. PHP is one example. Apache--another.
As you example shows, you only need namespace when you want to use generic
names for function and classes.
However, the possibility of name collisions isn't the only issue; there's
also things like avoiding duplication and very long names: What would you
rather like to write (implementing MySQL-like db-functions in PHP for the
sake of argument :) ):
People would implement that using classes. But since that's not your
point,
I won't go into it. The thrust of you argument is basically that generic
function names are superior to more task-specific function names. I cannot
disagree more. The very purpose of names is to uniquely things and
concepts.
The ideal situation is when one function name cooresponds to one
function--and we nearly have that with mysql_connect(). So yes, I would
prefer it and its mysql_* brothers to your generic version by a long shot.
When I write "mysql_connect" in this newsgroup, everyone knows exactly
what
function I'm referring. When I google the term "mysql_connect," the
function's man page is the top link and every other result has one thing
or
another to do with connecting to a MySQL database. If I use an editor with
autocomplete, "mysql_connect" will pop up with the correct parameter hints
as soon as I've entered "mysql_c." And what does your solution have to
offer? 6 less keys.
This is not an argument for or against namespaces. When you say we don't
need namespaces, you're really saying that prefixes like this are
preferable, or do you have another suggestion? Thus, it's not about
namespaces or not namespaces; it's about namespaces or ...(the
alternatives).
You are treating an essential difference as though it's trivial. A prefix
become part of an inseparable part of the a word. The combination isn't
just
the sum of the two parts, but gives rise to a meaning that is distinct.
Take
the term "namespace." Does it mean "space" in the context of nomenclature?
Is it space in the namespace of "name"? Of course not. Take away "name"
and
the whole concept is lost. The same way with function names. Take away the
part "mysql_" and we're no longing talking about the same piece of code.
To
hammer the point home let me say this in allcaps: PREFIXES CANNOT BE
OMITTED. Namespace identifier can be omitted. That very fact is what you
have offered up as the main benefit of using namespace. Don't turn around
now and say that there's really no difference.
Well said!
--
Tony Marston http://www.tonymarston.net
Chung Leong wrote: "Terje Slettebø" <ts*******@hotmail.com> wrote in message
news:41********@news.broadpark.no... It may be more of a theoretical problem in PHP than in other
languages, since there's no linking of object files - only the files being
included may have name collisions. Except for the standard library - see below.
People have little problem building enormously complex programs using
C either. PHP is one example. Apache--another.
Yes, but even if something is possible in C (or assembly or whatever),
that's not an argument for not _improving_ the language, or using a
language better suited for a task.
However, the possibility of name collisions isn't the only issue;
there's also things like avoiding duplication and very long names: What
would you rather like to write (implementing MySQL-like db-functions in PHP
for the sake of argument :) ):
People would implement that using classes.
Yes, that's an alternative.
But since that's not your point,
I won't go into it. The thrust of you argument is basically that
generic function names are superior to more task-specific function names.
No, it's not, and therefore your argument that follows addresses
something I don't claim.
My specific example was a db connect() function. Now tell me, is
"mysql_connect()" a more task-specific name than "mysql::connect()"?
The difference with the latter is that it separates the name of the
library/module, "mysql", from the name of the function, whereas the
former stuffs them both together in one name.
Now, let's not delude ourselves, here: I've read in the internals
archive, and namespaces have been seriously considered, and apparently
even implemented at one point, but was later dropped, so I'm not the
only one asking about this (OP being another, for example).
I cannot
disagree more. The very purpose of names is to uniquely things and
concepts. The ideal situation is when one function name cooresponds to one
function
As I said above, you're arguing against something I haven't said. I'm
certainly for good, descriptive names - but it may be better to be able
to decouple the function's name, from its library/module. For example,
in languages supporting namespaces, it's common to have something like
a "detail" or "impl" namespace, so when you see
"detail::some_function(...)" (or class or variable, for that matter),
you know it's part of the implementation, not the public interface.
Would you prefer to write "detail_some_function()" instead? Be my
guest...
Yes, classes might be an alternative, but as described in another
posting, they don't have the same ability. Classes are esssentially
"poor man's namespaces". Java also have a namespace system, in the form
of modules.
--and we nearly have that with mysql_connect(). So yes, I would
prefer it and its mysql_* brothers to your generic version by a long
shot. When I write "mysql_connect" in this newsgroup, everyone knows
exactly what function I'm referring.
mysql::connect would do the same.
When I google the term "mysql_connect," the
function's man page is the top link and every other result has one
thing or another to do with connecting to a MySQL database.
Given that search engines may separate the words "mysql" and "connect",
when using "mysql::connect", "mysql_connect" might be easier to find
this way.
If I use an editor with
autocomplete, "mysql_connect" will pop up with the correct parameter
hints as soon as I've entered "mysql_c."
An editor supporting namespaces/modules would do the same (like Java
editors). If you wrote "mysql::", you could get a list of all members
of the mysql namespace, and if you then typed "c", it could suggest
"connect", with parameter lists and all, just as in your example. It
does require such support in the editor, however.
And what does your solution have to
offer? 6 less keys.
Plus the possibility of having more or less the same capability as the
non-namespace version, as well as being able to compose the names in
logically grouped modules.
This is not an argument for or against namespaces. When you say we
don't need namespaces, you're really saying that prefixes like this are
preferable, or do you have another suggestion? Thus, it's not about
namespaces or not namespaces; it's about namespaces or ...(the
alternatives).
You are treating an essential difference as though it's trivial. A
prefix become part of an inseparable part of the a word. The combination
isn't just the sum of the two parts, but gives rise to a meaning that is
distinct. Take the term "namespace." Does it mean "space" in the context of
nomenclature? Is it space in the namespace of "name"? Of course not. Take away
"name" and the whole concept is lost. The same way with function names. Take
away the part "mysql_" and we're no longing talking about the same piece of
code. To hammer the point home let me say this in allcaps: PREFIXES CANNOT BE
OMITTED. Namespace identifier can be omitted. That very fact is what
you have offered up as the main benefit of using namespace. Don't turn
around now and say that there's really no difference.
Again I feel you're fighting a strawman. Yes, underscore makes the
parts of the word inseparable, as far as editors, the language, etc.
treats it. This may be good or bad. It's fine, when, as you say, the
parts making up the name really belong together, to get the right
meaning. Your example with the word "namespace" was a really bad one,
as it's one word, not two. "mysql_connect" are two words! It means make
a connection to a mysql database.
Anyway, the feeling I get from these discussions are basically: "The
language is fine as it is, don't bother us. We can do just fine with
what we have (even if we have to jump through hoops to implement things
resembling conventional overloading, or namespaces). Namespaces? Who
needs them? Overloading? Forget it. Type hints for built-in types? Nah.
We're used to fixing type-related bugs, so why bother?" So maybe
further discussion is rather unnecessary.
As I've mentioned earlier, I come from the C++ community, and even if
the language is one of the most complex and feature-rich there is, that
doesn't stop people from - decades after its invention, and 6 years
after standardisation - to come up with lots of suggestions for
improving the language
( http://www.open-std.org/JTC1/SC22/WG21/docs/papers/). Lambda,
closures, you name it. This gives a richer design space, and allows
more expressivity - to be able to clearer express your intent in the
code. That makes the language and community vibrant and fun.
Here, it's like: "We do well with what we have." Then so be it.
-
Regards,
Terje
That's why I dislike PHP5. Most of the new features are appeasement to folks
like this guy. Give them visibility and they'll want namespace. The next
thing you know they'll be demanding the Free City of Danzig in PHP.
Chung Leong wrote: That's why I dislike PHP5. Most of the new features are appeasement
to folks like this guy.
I rather think OO was added to PHP because OO in PHP has taken off
(apparently surprising its creators, as OO-support was more of a hack
at the time, from what I've read), and it's then useful to give people
features that help them make good, solid programs.
Naturally, you're free not to use any of it.
Personally, I don't understand what you would have against better OO
support and other things in PHP 5. Is it that you don't feel a need for
anything above something like C, in terms of abstraction? Well, there
are others who do appreciate being able to use higher levels of
abstraction, and being able to express more succinctly their intent in
the code, thus making it easier to understand and maintain.
Give them visibility and they'll want namespace. The next
thing you know they'll be demanding the Free City of Danzig in PHP.
Yeah, better stick to assembly, to be sure. ("What, you want an
assembler?!") :)
Regards,
Terje This discussion thread is closed Replies have been disabled for this discussion. Similar topics
3 posts
views
Thread by Erik Bongers |
last post: by
|
3 posts
views
Thread by Rubén Campos |
last post: by
|
6 posts
views
Thread by B0nj |
last post: by
|
8 posts
views
Thread by Robert W. |
last post: by
|
2 posts
views
Thread by Bob Day |
last post: by
|
2 posts
views
Thread by miked |
last post: by
|
5 posts
views
Thread by Jake K |
last post: by
|
3 posts
views
Thread by Cousson, Benoit |
last post: by
|
reply
views
Thread by Maric Michaud |
last post: by
| | | | | | | | | | | | | | | | | | | | | |
