March 31, 2005
On Thu, 31 Mar 2005 10:33:26 -0800, Walter wrote:

> "Georg Wrede" <georg.wrede@nospam.org> wrote in message news:424BD4C1.5090109@nospam.org...
>> Walter wrote:
>>>>So what I meant was 'foo.d' is allowed along side a directory called
>>>>
>>>> 'foo'.
>>>
>>> Of course. But the filesystem doesn't allow you to refer to "foo.d" as "foo".
>>
>> Ehhhhhh, I'm totally at a loss here. 8-/
>>
>> I see no reason for this need or not need to have files and directories with the same name. And probably there's never been a good reason for it for anybody else either, otherwise unix would already have it.

Huh? Who is asking for files and directories to have the same name? I'm
not.

> I agree. I am at a loss as well why this is perceived as a problem, which is why I'd asked for a clarification.

The "perceived" problem is that one is unable to have the file "foo.d" and the directory "foo" both in the same directory *and* have your application import "foo.d" or anything from inside "foo". In other words, one cannot code ...

  import foo.bar;

if "foo.d" happens to exist.

Why would somebody want to do this? Ask Arcane Jill. She wanted to have "BigInteger.d" contain imports for all the modules inside the BigInteger package to make it easier for coders to import the entire package. Not realizing this restriction, she used names that seemed natural to use. The best way around this problem is to rename "BigInteger.d" to something else.

-- 
Derek Parnell
Melbourne, Australia
1/04/2005 6:43:14 AM
March 31, 2005
> The "perceived" problem is that one is unable to have the file "foo.d" and the directory "foo" both in the same directory *and* have your application import "foo.d" or anything from inside "foo". In other words, one cannot code ...
>
>  import foo.bar;
>
> if "foo.d" happens to exist.
>
> Why would somebody want to do this? Ask Arcane Jill. She wanted to have "BigInteger.d" contain imports for all the modules inside the BigInteger package to make it easier for coders to import the entire package. Not realizing this restriction, she used names that seemed natural to use. The best way around this problem is to rename "BigInteger.d" to something else.

I wanted to use this in DTL.



March 31, 2005
On Fri, 1 Apr 2005 06:59:33 +1000, Derek Parnell <derek@psych.ward> wrote:
> On Thu, 31 Mar 2005 10:33:26 -0800, Walter wrote:
>
>> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
>> news:424BD4C1.5090109@nospam.org...
>>> Walter wrote:
>>>>> So what I meant was 'foo.d' is allowed along side a directory called
>>>>>
>>>>> 'foo'.
>>>>
>>>> Of course. But the filesystem doesn't allow you to refer to "foo.d" as
>>>> "foo".
>>>
>>> Ehhhhhh, I'm totally at a loss here. 8-/
>>>
>>> I see no reason for this need or not need to have files and directories
>>> with the same name. And probably there's never been a good reason for it
>>> for anybody else either, otherwise unix would already have it.
>
> Huh? Who is asking for files and directories to have the same name? I'm
> not.
>
>> I agree. I am at a loss as well why this is perceived as a problem, which is
>> why I'd asked for a clarification.
>
> The "perceived" problem is that one is unable to have the file "foo.d" and
> the directory "foo" both in the same directory *and* have your application
> import "foo.d" or anything from inside "foo". In other words, one cannot
> code ...
>
>   import foo.bar;
>
> if "foo.d" happens to exist.
>
> Why would somebody want to do this? Ask Arcane Jill. She wanted to have
> "BigInteger.d" contain imports for all the modules inside the BigInteger
> package to make it easier for coders to import the entire package. Not
> realizing this restriction, she used names that seemed natural to use. The
> best way around this problem is to rename "BigInteger.d" to something else.

The problem seems to me to be that if you say:

import a.b;

and you have:
  a.d
  a\b.d

does the import import the file b.d, or does it import a symbol called "b" from the module "a" (file a.d).

[clarification of terms:
  symbol  == class, struct, enum, instance?
  module  == file
  package == directory
]

My questions are:
 - is it important that the above is possible?
 - does it make sense to import a symbol from within a module?
 - if not, then there is no problem.
 - if so, how do we disambiguate the above?

Suggestions to disambiguate.

1. Use "" eg.
  import "a.b"  <- imports a symbol "a.b"
  import a.b    <- imports the module "b" from package "a"

This breaks no existing code. Unquoted is the same as it's always been.

2. Require file extensions
  import a.b    <- imports a symbol "a.b"
  import a.b.d  <- imports the module "b" from package "a"

This breaks all current code/behaviour.

3. Use a different seperator for directories
  import a.b  <- imports a symbol "a.b"
  import a/b  <- imports the module "b" from package "a"

Either / or \ could be used or allow both interchangably.
This breaks all current code/behaviour.

To me, #3 is the clearest, #2 is actually more confusing, #1 is the only solution that does not break existing behaviour/code.

Regan
March 31, 2005
"Roberto Mariottini" <Roberto_member@pathlink.com> wrote in message news:d2go14$pno$1@digitaldaemon.com...
> In article <d2dsn9$n7k$1@digitaldaemon.com>, Walter says...
>>"Java" is another name for a major product that is not impeded by its name.
>
> And don't forget "swing". Swing was the internal code name for the
> project, and
> at some point in time it was renamed to "JFC". Still today nobody uses JFC
> and
> everybody keeps calling it swing.

I don't think those are fair comparisons because "java" and "swing" both use the same word as the name of the technology, and the name of the namespace:

# import java.lang.Object;
# import javax.swing.*;

Thus it's to be expected that nobody calls Swing JFC, because no Swing programmer actually types, reads about, or discusses the letters "JFC". There is no class named JFC.  The compiler doesn't recognize JFC.  It's "swing" because the compiler, class structure, and namespace all agree it's called Swing.  Even the closest the documentation gets to calling it "JFC" is "JFC/Swing".

In fact, I think you've argued my *exact* point in reverse.  Phobos is to JFC as STD is to Swing.

So if your point is that "successful technologies can have cool names", I'll grant that.

But you've only reinforced my core notion that "successful technologies have *one* name that is used by programmer and compiler alike".  Same goes for Boost, Xiph, and others (STL is a bit funky, but at least it has the word "standard" in the name).

I'm not totally against Phobos.  I'm just totally for a sensible namespace where everything is called by it's right name.  If the right name is Phobos, let's call it that.  If the right name is STD, then great.  But my mind is grappling with how they're both right names, at the same time.

-david


March 31, 2005
On Fri, 01 Apr 2005 10:16:28 +1200, Regan Heath wrote:


[snip]
> 
> The problem seems to me to be that if you say:
> 
> import a.b;
> 
> and you have:
>    a.d
>    a\b.d
> 
> does the import import the file b.d, or does it import a symbol called "b"
>  from the module "a" (file a.d).

Huh? I don't think that D allows one to import symbols from a module.

  import a.b;

Always means "access the file whose path is 'a/b.d'

-- 
Derek
Melbourne, Australia
1/04/2005 9:10:14 AM
April 01, 2005
On Fri, 1 Apr 2005 09:12:06 +1000, Derek Parnell <derek@psych.ward> wrote:
> On Fri, 01 Apr 2005 10:16:28 +1200, Regan Heath wrote:
>
>
> [snip]
>>
>> The problem seems to me to be that if you say:
>>
>> import a.b;
>>
>> and you have:
>>    a.d
>>    a\b.d
>>
>> does the import import the file b.d, or does it import a symbol called "b"
>>  from the module "a" (file a.d).
> Huh? I don't think that D allows one to import symbols from a module.
>
>   import a.b;
>
> Always means "access the file whose path is 'a/b.d'

Just checking.

Actually I think I just recalled Walters reasoning earlier. The problem is this:

[a.d]
class foo {
  int i;
}
foo b;

[a\b.d]
float i;

import a;
import a.b;

a.b.i = 6; //which 'i' is set?

Regan
April 01, 2005
On Fri, 01 Apr 2005 12:10:38 +1200, Regan Heath <regan@netwin.co.nz> wrote:
> On Fri, 1 Apr 2005 09:12:06 +1000, Derek Parnell <derek@psych.ward> wrote:
>> On Fri, 01 Apr 2005 10:16:28 +1200, Regan Heath wrote:
>>
>>
>> [snip]
>>>
>>> The problem seems to me to be that if you say:
>>>
>>> import a.b;
>>>
>>> and you have:
>>>    a.d
>>>    a\b.d
>>>
>>> does the import import the file b.d, or does it import a symbol called "b"
>>>  from the module "a" (file a.d).
>> Huh? I don't think that D allows one to import symbols from a module.
>>
>>   import a.b;
>>
>> Always means "access the file whose path is 'a/b.d'
>
> Just checking.
>
> Actually I think I just recalled Walters reasoning earlier. The problem is this:
>
> [a.d]
> class foo {
>    int i;
> }
> foo b;
>
> [a\b.d]
> float i;

[another.d]

> import a;
> import a.b;
>
> a.b.i = 6; //which 'i' is set?

Correction/addition  above.
Regan
April 01, 2005
> I'm not totally against Phobos.  I'm just totally for a sensible namespace where everything is called by it's right name.  If the right name is Phobos, let's call it that.  If the right name is STD, then great.  But my mind is grappling with how they're both right names, at the same time.

Phobos (the library) includes std, etc and internal (the packages).


April 01, 2005
Unknown W. Brackets wrote:
> I'll remember not to joke in the future.  No one gets it.
> 
> -[Unknown]

You won't believe me now, but I really did think of you a split second when I saw the [Unknown] line in the OP. If you had asked who "[Ambivalent]" was I might've figured it out.

My real name is "the" (but my friends all call me "a").

-- 
jcc7
http://jcc_7.tripod.com/d/
April 01, 2005
Ben Hinkle wrote:
>>I'm not totally against Phobos.  I'm just totally for a sensible namespace where everything is called by it's right name.  If the right name is Phobos, let's call it that.  If the right name is STD, then great.  But my mind is grappling with how they're both right names, at the same time.
> 
> 
> Phobos (the library) includes std, etc and internal (the packages). 

Except that non-standard things can also supposedly go in etc and it's somewhat debatable whether the contents of internal are
(1) actually part of the standard library
or
(2) internal compiler thingees that if missing would cause the compiler to explode.

Sometimes it's hard to tell where the compiler ends and the library begins. The original Mars and Phobos don't have this problem (the black stuff in between makes it pretty obvious).

I hope my confusion isn't contagious. Everybody be sure to wash your hands.

-- 
jcc7
http://jcc_7.tripod.com/d/