Yes, that's a good point. The upside, however, is that it provides uniqueness.

However, I guess if it's a collegial approach to naming - which can be as simply as suggesting a module base name on the newsgroup and waiting for the flak - then we should be able to work around the lack of absolute uniqueness.

The downside to this freer approach is that names would be inconsistent, which would mean either remembering them, or wasting time looking for them. Hence, there would have to be some agreed convention. Suggestions, please, everyone.

Another approach would be to use a UUID for the module name, such as

  import F4E600DD_72CE_4576_8327_17F25C1773A3.win32.gdi;




"Mark T" <Mark_member@pathlink.com> wrote in message news:b7i6i9$1kjb$1@digitaldaemon.com...
> >
> >I would vote this way too.  I'm a little worried about the convention of
using
> >the domain name for the namespace.  An independent developers may not
have a
> >domain name or domain name that would be appropriate for the namespace.
> >
>
> totally agree, companies come and go (along with their domain name), the internet domain naming stuff is very weak
>
>

Yes, please avoid the domain names.

Besides that unnatural binding, there is actually _no need_ for globally unique names. What's needed is avoiding clashes, but that does not require a global hierarchy.

1. Add a prefix (like "d", as someone suggested) for the
standard lib, meaning:

    "Sorry, I reserve this one subtree of the global space,
    to ensure a standard base layout for every installation
    -- Walter" ;)

2. Non-standard packages, OTOH, don't need a standard layout -- exactly because they are non-standard...

3. Collisions are a project-specific issue of combining non-standard packages in a conflicting way.

4. That has to be addressed on the project-level. One clean way is importing a conflicting package into a "sandbox", using a prefix. (Is the C++ way applicable to D?)


Cheers,
Sz.

> Yes, please avoid the domain names.

Have no problem with that

> Besides that unnatural binding, there is actually _no need_ for globally unique names. What's needed is avoiding clashes, but that does not require a global hierarchy.
>
> 1. Add a prefix (like "d", as someone suggested) for the
> standard lib, meaning:
>
>     "Sorry, I reserve this one subtree of the global space,
>     to ensure a standard base layout for every installation
>     -- Walter" ;)

Totally agree with this. Why is it not done consistently already?

> 2. Non-standard packages, OTOH, don't need a standard layout -- exactly because they are non-standard...
>
> 3. Collisions are a project-specific issue of combining non-standard packages in a conflicting way.

So you're arguing for the status quo - with which people are already having problems.

Why not just forget about packages and uniquness and just declare everything globally?

> 4. That has to be addressed on the project-level. One clean way is importing a conflicting package into a "sandbox", using a prefix. (Is the C++ way applicable to D?)

Why not come up with a convention that works, and save us all a huge amount of totally pointless effort?

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:b7njkc$1gv3$1@digitaldaemon.com...
>
> > 3. Collisions are a project-specific issue of combining non-standard packages in a conflicting way.
>
> So you're arguing for the status quo - with which people are already
having
> problems.

No, I don't think I do.

> Why not just forget about packages and uniquness and just declare
everything
> globally?

Because that would be a bit stupid, Matt. ;)

_Within a project_, you need a hieararchy. You need to
design and maintain _your own_ hierarchical namespace.
But not the whole world. See now? There *is* life between
a totally flat global namespace and a single global tree.
Both extremes are suboptimal.

> > 4. That has to be addressed on the project-level. One clean way is importing a conflicting package into a "sandbox", using a prefix. (Is the C++ way applicable to D?)
>
> Why not come up with a convention that works, and save us all a huge
amount
> of totally pointless effort?

(Sorry, do I correctly sense unnecessary emotions here?...)

Cheers,
Sz.

> > 4. That has to be addressed on the project-level. One clean way is importing a conflicting package into a "sandbox", using a prefix. (Is the C++ way applicable to D?)
>
> Why not come up with a convention that works, and save us all a huge
amount
> of totally pointless effort?

Sorry, I'm too tired now for that. I've just finished porting the fresh Lua 5.0 API to D and I need a looong sleep.

Someone who is also familiar with the C++ namespaces
_and_ much more familiar with D than I am, _and_ is
not so exhausted as I am now _and_ understands my point,
would be in a much better position for coming up with
a usable syntax than me.

Think of something along this idea:

//--- std. stuff
import d.stuff;    // all clear

//--- conflicting stuff 1
import badname;
//imort badname;  // another package with the same name; no way...
import badname as goodname;    // now its fine

//--- conflicting stuff 2
imort package1;    // imports 'badname'
//imort package2;  // would import its own 'badname'
import package2 as xxx.package2;   // now it would import
                                   // its own 'badname' as xxx.badname;

Cannot keep awake now, sorry...

Good luck,
Sz.

An omission:

> //--- conflicting stuff 1
> import badname;
> //imort badname;  // another package with the same name; no way...
> import badname as goodname;    // now its fine

Could make sense this way, perhaps:

> //--- conflicting stuff 1
> import badname;
> //imort badname;  // no way
> import some/path/to/another/badname as goodname;    // OK

(But I'm really not familiar enough with the current
D mechanism -- this is why I wanted to leave the details
for the more knowledgeable.)

Good night (soon morning here),
Sz.

> > > 3. Collisions are a project-specific issue of combining non-standard packages in a conflicting way.
> >
> > So you're arguing for the status quo - with which people are already
> having
> > problems.
>
> No, I don't think I do.

Then I need a more fulsome explanation, as that's how it appears.

>
> > Why not just forget about packages and uniquness and just declare
> everything
> > globally?
>
> Because that would be a bit stupid, Matt. ;)
>

That was sarcasm, as, presumably, your response is. Either or both of us should probably drop that, as it is misunderstood all too readily. Sorry.

> _Within a project_, you need a hieararchy. You need to
> design and maintain _your own_ hierarchical namespace.
> But not the whole world. See now? There *is* life between
> a totally flat global namespace and a single global tree.
> Both extremes are suboptimal.

You'd need to give me examples. Without them it seems you are proposing a laissez faire approach which is already causing problems and is _guaranteed_ to cause big problems in the future. It happens in C++, it happens in .NET and it even happens in Java, despite their best attempts. (Though it's mostly caused in Java by the use of the evil "import *;")

Since I'm anything but imaginative and am, for want of a better description, a pragmatist, I'll go for the strictest mechanism possible, simply because maintenance costs are always the most significant. If people disagree with that, as is both their right and wont, then they need to propose something workable - dare I say "professional" - or accept that they're going to have to make a few more key-presses.

> > > 4. That has to be addressed on the project-level. One clean way is importing a conflicting package into a "sandbox", using a prefix. (Is the C++ way applicable to D?)
> >
> > Why not come up with a convention that works, and save us all a huge
> amount
> > of totally pointless effort?
>
> (Sorry, do I correctly sense unnecessary emotions here?...)

I understood this to be you suggesting that we can wrap conflicting symbols/modules inside proprietary modules that serve only to disambiguate clashes, in the same way that one has to, for example, wrap the otherwise well-written ZLib in an API simply because it takes too many liberties with the global namespace.

If that was not what you were suggesting - which would be workable, but tedious (hence my "save us all a huge amount of totally pointless effort") - then I retract my comment, and reserve judgment until I understand what you do mean.


Sorry if I've been short on this - and it was not directed at any individual - but I just find debates based upon people wanting to type fewer characters in exchange for dumping large amounts of robustness, flexibility and clarity very perplexing and not a little annoying. I thought the point of D is to become a serious contender in the real - and that is to say, whether we like it or not, the business world - and not just be a toy or hobby; at least that's what I've been led to believe.

Spleen at 0. Fire at will.

Matthew

> > //--- conflicting stuff 1
> > import badname;
> > //imort badname;  // no way
> > import some/path/to/another/badname as goodname;    // OK

Back in school when I had to "invent" a fake language as part of a project,
I actually had something like this.. I think the syntax was more along the
lines of:
   include std/utils/collection/vector @ libVector;

This would have included the 'std/utils/collection/vector' library, with its namespace set to 'libVector'... which I guess is kind of obvious. Personally though, I rather like the idea of using 'as' to do this, rather than my old @ syntax from around 1998 or so.  :)

As to the module-naming issue, I vote for semi-strict names with phobos
top-level and renamed to d.
As to the issue of how the names should be formed... you got me.

--C. Sauls

This is reminiscent of Python's import syntax:

        import sys

        def quitter():
                sys.exit()      # have to explicitly specify sys.*

Example 2:

        from sys import exit

        def quiter():
                exit()          # we imported the symbol directly

Basically, what you import is what you get. If you say "import foo.bar.X" then you have to prefix everything by "foo.bar.X", whereas "from foo.bar.X import Y", then you can use Y directly.

Certainly helps to control conflicts. Then again, in python conflicts during import just overwrite the namespace. In a compiler such as the D language they should issue an error and abort compilation.

--thomas

C. Sauls wrote:

>> > //--- conflicting stuff 1
>> > import badname;
>> > //imort badname;  // no way
>> > import some/path/to/another/badname as goodname;    // OK
> 
> Back in school when I had to "invent" a fake language as part of a
> project, I actually had something like this.. I think the syntax was more
> along the lines of:
>    include std/utils/collection/vector @ libVector;
> 
> This would have included the 'std/utils/collection/vector' library, with its namespace set to 'libVector'... which I guess is kind of obvious. Personally though, I rather like the idea of using 'as' to do this, rather than my old @ syntax from around 1998 or so.  :)
> 
> As to the module-naming issue, I vote for semi-strict names with phobos
> top-level and renamed to d.
> As to the issue of how the names should be formed... you got me.
> 
> --C. Sauls

-- 
"Paul Lynde to block..."
-- a contestant on "Hollywood Squares"