Chung Leong wrote:[color=blue]
> "Terje Slettebø" <tslettebo@hotmail.com> wrote in message
> news:41f6a3cd$1@news.broadpark.no...[color=green]
> > It may be more of a theoretical problem in PHP than in other[/color][/color]
languages,[color=blue][color=green]
> > since there's no linking of object files - only the files being[/color][/color]
included[color=blue]
> may[color=green]
> > have name collisions. Except for the standard library - see below.[/color]
>
> People have little problem building enormously complex programs using[/color]
C[color=blue]
> either. PHP is one example. Apache--another.[/color]
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.
[color=blue][color=green]
> > However, the possibility of name collisions isn't the only issue;[/color][/color]
there's[color=blue][color=green]
> > also things like avoiding duplication and very long names: What[/color][/color]
would you[color=blue][color=green]
> > rather like to write (implementing MySQL-like db-functions in PHP[/color][/color]
for the[color=blue][color=green]
> > sake of argument :) ):[/color]
>
> People would implement that using classes.[/color]
Yes, that's an alternative.
[color=blue]
> But since that's not your point,
> I won't go into it. The thrust of you argument is basically that[/color]
generic[color=blue]
> function names are superior to more task-specific function names.[/color]
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).
[color=blue]
> I cannot
> disagree more. The very purpose of names is to uniquely things and[/color]
concepts.[color=blue]
> The ideal situation is when one function name cooresponds to one
> function[/color]
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.
[color=blue]
> --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[/color]
shot.[color=blue]
> When I write "mysql_connect" in this newsgroup, everyone knows[/color]
exactly what[color=blue]
> function I'm referring.[/color]
mysql::connect would do the same.
[color=blue]
> When I google the term "mysql_connect," the
> function's man page is the top link and every other result has one[/color]
thing or[color=blue]
> another to do with connecting to a MySQL database.[/color]
Given that search engines may separate the words "mysql" and "connect",
when using "mysql::connect", "mysql_connect" might be easier to find
this way.
[color=blue]
> If I use an editor with
> autocomplete, "mysql_connect" will pop up with the correct parameter[/color]
hints[color=blue]
> as soon as I've entered "mysql_c."[/color]
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.
[color=blue]
> And what does your solution have to
> offer? 6 less keys.[/color]
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.
[color=blue][color=green]
> > This is not an argument for or against namespaces. When you say we[/color][/color]
don't[color=blue][color=green]
> > 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).[/color]
>
> You are treating an essential difference as though it's trivial. A[/color]
prefix[color=blue]
> become part of an inseparable part of the a word. The combination[/color]
isn't just[color=blue]
> the sum of the two parts, but gives rise to a meaning that is[/color]
distinct. Take[color=blue]
> the term "namespace." Does it mean "space" in the context of[/color]
nomenclature?[color=blue]
> Is it space in the namespace of "name"? Of course not. Take away[/color]
"name" and[color=blue]
> the whole concept is lost. The same way with function names. Take[/color]
away the[color=blue]
> part "mysql_" and we're no longing talking about the same piece of[/color]
code. To[color=blue]
> hammer the point home let me say this in allcaps: PREFIXES CANNOT BE
> OMITTED. Namespace identifier can be omitted. That very fact is what[/color]
you[color=blue]
> have offered up as the main benefit of using namespace. Don't turn[/color]
around[color=blue]
> now and say that there's really no difference.[/color]
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
