Wow! Thanks!

what you said is i want to say long time ago.

but, my poor english....


In addition, sometime, we want doing something nicer, not only has ability to do. it's the different between professional and layman, maturity and babyhood.


"John Reimer" <John_member@pathlink.com> дÈëÏûÏ¢ÐÂÎÅ:e8pptc$2acl$1@digitaldaemon.com...
> In article <e8pk3b$26bo$1@digitaldaemon.com>, Walter Bright says...
>>
>>Kris wrote:
>>> Er, that really doesn't work at all. Please ignore what I said a few
>>> minutes ago
>>> regarding this option (I really should get some sleep instead).
>>>
>>> The problem here is that, for the proposed static imports, everything
>>> must be
>>> fully-qualified with the /original import name/, and that's just plain
>>> awful for
>>> long import names. The "import as" allows one to give it a nice short
>>> name
>>> instead.
>>
>>Alias also works fine for making substitutes for long, awkward names:
>>
>>import x.y.mod;
>>alias x.y.mod t;
>>
>>x.y.mod.foo(); // works
>>t.foo(); // also works
>>
>>
>>> And, I still think the selective-import is the superior solution anyway.
>>
>>Semantically, it isn't any different. It would even be implemented internally using the 'alias' machinery.
>
>
> Walter,
>
> The use of "alias" still looks like a hack.  We know you've always been
> firm in
> your belief that "alias" is the way to do it.  I doubt that all these
> people
> would be discussing options here if they were satisfied with that solution
> (which has been around for a looong time).
>
> We know it can be done with alias. Kris knows. We don't think it's good
> enough.
> That's why this whole topic is being wrangled.
>
> So if you choose to make the internal machinery do it with alias, fine!
> We just
> want something that's better, nicer, more professional looking! :) (please
> not
> "static import," though).
>
> While I do agree that D would suffer if you followed the communities whim
> for
> every little feature suggested, yet I think you are far too independent
> minded
> most of the time.  The quote in your recent interview at Bitwise -- "D is
> going
> wherever the D community wants it to go" -- is really a farce.  D is going
> where
> /you/ want it to go, Walter.
>
> And there's nothing wrong with admitting that.  I just think a honesty is
> important here.  This is your language.  You've made that very plain over
> the
> years, and most of us who have stuck around have accepted that. You
> strongly
> disfavour committees and bureaucracy, which is completely understandable;
> but,
> your over-protectiveness and fear of them may be doing the same sort of
> damage
> on the opposite end of the spectrum.
>
> Don't take this wrong:  I'm very thankful about all you've done with D; I
> just
> get a little frustrated at how hard you are to convince of anything, a
> trait
> that may do well for you in some ways but probably hurts you so much more
> in
> other ways.
>
> -JJR
>
>
>
> 

John Reimer wrote:
> "in" seems inappropriate in this situation.  "as" perfectly correlates to a renaming or aliasing action.  "in" is confusing and looks more like an action on a set.
> 

If you read it as "into" I think it should make sense, if you think of namespaces:

import foo.bar in foobar; // import foo.bar into the foobar namespace

Deewiant wrote:
> John Reimer wrote:
> 
>>"in" seems inappropriate in this situation.  "as" perfectly correlates to a
>>renaming or aliasing action.  "in" is confusing and looks more like an action on
>>a set.
>>
> 
> 
> If you read it as "into" I think it should make sense, if you think of namespaces:
> 
> import foo.bar in foobar; // import foo.bar into the foobar namespace

Except you aren't importing it /into/ the foobar namespace, you're importing it /as/ the foobar namespace.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

Kirk McDonald wrote:
> Deewiant wrote:
>> John Reimer wrote:
>>
>>> "in" seems inappropriate in this situation.  "as" perfectly
>>> correlates to a
>>> renaming or aliasing action.  "in" is confusing and looks more like
>>> an action on
>>> a set.
>>>
>>
>>
>> If you read it as "into" I think it should make sense, if you think of namespaces:
>>
>> import foo.bar in foobar; // import foo.bar into the foobar namespace
> 
> Except you aren't importing it /into/ the foobar namespace, you're importing it /as/ the foobar namespace.
> 

What's the difference? I create the namespace when importing a module, and put everything from that module /into/ the namespace.

If it won't be possible to import multiple modules into the same namespace, then "as" might make more sense, I admit. But IMHO the difference between the meanings is so small that we don't need a new keyword for this; overloading "static" yet again, on the other hand, is much worse, and the new meaning is far from intuitive.

Kirk McDonald wrote:
> Bruno Medeiros wrote:
>> This behavior of having all project entities(names) automatically available by FQN is also how Java and C# work[*], which I think is a quite sensible approach. And perhaps this should even be the standard among D programs.
>>
>> [*] How is it in Python and Ruby? (I do not know those languages well) Or in any other language you know with such similar structured hierarchical namespacing?
>>
>>
> 
> I've reviewed Python's import rules previously:
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39396
> 

How does Python determine module names, and map modules to files (or vice-versa)?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Sorry, I still don't understand what the hubbub is about with Imports?

My understanding was that you put classes in the files named the same.  This is intelligent design at it's finest.  Why would you WANT to import bla.blorg as bob?

Bruno Medeiros wrote:
> Kirk McDonald wrote:
> 
>> Bruno Medeiros wrote:
>>
>>> This behavior of having all project entities(names) automatically available by FQN is also how Java and C# work[*], which I think is a quite sensible approach. And perhaps this should even be the standard among D programs.
>>>
>>> [*] How is it in Python and Ruby? (I do not know those languages well) Or in any other language you know with such similar structured hierarchical namespacing?
>>>
>>>
>>
>> I've reviewed Python's import rules previously:
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39396
>>
> 
> How does Python determine module names, and map modules to files (or vice-versa)?
> 

In the simple case, the file "foo.py" is mapped to the module "foo". When you attempt the import the module, Python searches something called the "Python path," which is a list of directories. Normally, this is just set to the current directory, the location(s) of the standard library, and the standard "site-packages" directory, where add-on libraries live. Python being Python, this list can be altered at runtime.

Python can accept other kinds of files as modules. .pyc files are bytecode-compiled Python code; .pyd, .dll, and/or .so files are compiled C (or C++, or D) extensions.

Python also has the concept of a "package," not unlike D. However, Python's packages are slightly more sophisticated than D's. Each directory in the package has a special "__init__.py" file which defines what the other components of the package are. This file is also a full-fledged Python source file, so you can do any number of things when just the /package/ is imported. It acts as a standard single point of access for the entire package.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

David Medlock wrote:
> Derek Parnell wrote:
> 
>>
>> I'm hope I'm not messing up Kris' words here but I think he is saying that  we need to cut down on the amount of typing and reading people *must* do  in a program. Keep it to a minimum. Try and work the syntax so that the  common and mandatory things are short, easy, and intuitive to do. Make the  unusual and 'special' things have more detail in the syntax.
>>
> 
> I 100% agree.  The usual cases should be implicit, and the corner cases explicit.

But *are* they the usual case? As far as I can tell, Python is the only significant language that allows aliasing of import names (though the Python manual calls it "binding"). (We'll set aside the C++ #define trick as not a reasonable method.) I haven't seen it used in Python code, though I admit I haven't seen much Python code.

That's why I suggest just trying it for a while. Kris' original concerns are met with the combination of 'static import' (I know, I know, should think of some better keyword combination) and 'alias'. Syntax changes should be done conservatively - if there's an existing way to do it, it has to be used a lot to justify special syntax for it.

Kris brought up 'goto' - sure, we can do a 'while' loop with a goto, but loops are so very, very common that special syntactic sugar for it has proven to be a big win.

D already has a lot of syntax in it. We should be very careful about adding more; not every convenience should have its own syntactic sugar.

Bruno Medeiros wrote:
> [*] How is it in Python and Ruby? (I do not know those languages well) 

http://docs.python.org/ref/import.html

"Walter Bright" <newshound@digitalmars.com> wrote in message news:e8qf7k$2q0d$1@digitaldaemon.com...
> What I don't get is what is "unprofessional" or hackish about alias? Is it (as I posted to Kris) that it looks too much like #define?

I think the problem with "alias" is that you'll have multiple ways to refer to the imported name.

You can use the FQN, the global one (in case there are no conflicts) and finally the aliased name. And there's no restriction: the code in that module could be using any of the three alternatives, or worse still, all! You'll have to keep track on a piece of paper (or comments :) that .foo == lib.bar.foo == myfoo.

An "import x as y" would leave only 1 alternative: y. "static import" will still have two, the FQN and the alias. (I liked "import x alias y", by the way)

> Each idea goes through a gauntlet of:
> 1) is lack of this idea turning users away from D
> 2) how much power it adds
> 3) how much complexity it adds
> 4) is it consistent with the rest of D
> 5) how hard is it to implement
> 6) how does it rank in importance against all the other ideas

Lets make this the official yardstick to which to subject all future proposals.

If you have an opinion on any feature request, no matter how silly the request, you should write a small reaction. Perhaps just a comment like "denied, see item 6 of The List". Of course, people will want to argue with you futher, but it's likely that the community can take it from there.

L.