July 12, 2006
Jari-Matti Mäkelä wrote:
> kris wrote:
>>The syntax itself does not need to be complex at all.
> 
> 
> Right. I only meant that the syntax does not have to be a monster like this
> 
> [<protection>] [static] import {[in]} <FQN Module> [alias <Module Alias>]
> {[<<Member> [alias <Member Alias>]>[, ...]]};
> 

Right. This simpler the syntax, the better (in this case). I suspect that the use of prefix-import alone would be sufficient, and the optional selective-import is somewhat redundant?

I'm sure we could all think of cases where the latter would be useful, but prefix-import (call it partially-qualified-symbols if one prefers) would suffice, IMO.


>>No static, no alias. Looks very much like the existing import, and is
>>almost as effortless to use. Perhaps you might like to read the "Import
>>RFC" posted? It explains the issues in a little more depth.
> 
> 
> kris, I read it already. 

Yes, I realized that right after the above post. Sorry about that :(


July 12, 2006
Walter Bright wrote:
> John Reimer wrote:
>> Several dedicated people here are making these import suggestions based on lots
>> of time and experience putting D to use in large projects.  It becomes more
>> evident, in that context, why D is NOT the same as Java, C#, C++, and why it
>> shouldn't be the same, even in the context of namespaces. It's a complete
>> mistake to try to cast D in the same mold as those languages, whatever Walter
>> keeps saying.  D maintains a different aura and seems to invite a new style, all
>> evidence of a healthy evolution of a language.
> 
> It's easy to demonstrate the utility of feature X if it has a proven track record in other languages. If it does not exist in those other languages, the case for X must have a significantly higher bar to get over.

Perl's module importing supports subsetting of symbols.

use module;  -- imports everything in the module
use module(sym1,sym2); -- imports strictly sym1 and 2, and nothing else.

From a maintainability standpoint, being able to easily and quickly deduce where a symbol comes from is invaluable.  More so when a language is highly dynamic as perl is, though it holds for all languages.

It's one of the things that bugs me about c and c++.. it's often a pain to discover where some symbol comes from without the use of grep or source indexers (lxr, cscope, c/etags, intellisense and its ilk).  This is one of the core aspects of this thread, imho, and it's not been explicitly pointed out (though I could have easily missed it amongst the avalanche of posts).

Later,
Brad
July 12, 2006
On Tue, 11 Jul 2006 18:20:54 -0700, kris <foo@bar.com> wrote:
> Jari-Matti Mäkelä wrote:
>> kris wrote:
>>> The syntax itself does not need to be complex at all.
>>   Right. I only meant that the syntax does not have to be a monster like this
>>  [<protection>] [static] import {[in]} <FQN Module> [alias <Module Alias>]
>> {[<<Member> [alias <Member Alias>]>[, ...]]};
>>
>
> Right. This simpler the syntax, the better (in this case). I suspect that the use of prefix-import alone would be sufficient, and the optional selective-import is somewhat redundant?

I agree. It seems that selective-import solves the same problem (avoiding clashes) in a less comprehensive fashion than the prefix-import. Unless there is some other problem the selective-import solves?

Regan
July 12, 2006
Jari-Matti Mäkelä wrote:

> Lars Ivar Igesund wrote:
>> I believe I might have been a bit rash here, but I got somewhat pissed pouring over all the posts for the last few days. I will therefore restate some of my thoughts in a calmer manner:
>> 
>> If we for a second ignore the language issues chatted about recently, most people agree that D is missing libraries to be able to really compete with other languages. It is therefore unfathomable to me why you Walter don't actively try to make it easy to create good libraries in D. Libraries that can be made stable, failsafe and predictable. You have said many enough times that D is different enough to need different solutions to problems already solved in other languages. Why is it then that you seemingly refuse to listen to those that have tried to solve these problems in D over the years? Those that have found that the language features in D probably need to be refined to not only make libraries in D possible, but fun to write, fun to use, safe to use and with a predictable usage pattern.
> 
> I think you're a bit too harsh on Walter now. In the recent two week or so Walter has fixed many important things like most of the import bugs. The only thing left are:
> 
>  * some people thing that imports should be private by default
>    - changing this would break some old code, but does it matter?
>     (statistically private imports are much more common)
> 
>  * most of the people want an additional safe import syntax that allows
> importing to a custom namespace.
> 
>  * some general show-stopper bugs
> 
> The first two of these are luckily easy to fix. We're not far from 1.0. If were not in a hurry, I would like the interface things to be fixed (that double lookup implementation) too before reaching stable. Then D will be perfect for real production level use.
> 

Ah, maybe I was still too harsh, but I've been around for a while, and we're not talking new issues. That it really is mostly all about easy fixes, don't make it any more sensible to me that they haven't already been made, or why he keep suggesting fixes so cumbersome that noone will use them.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
July 12, 2006
Carlos Santander wrote:
> Here's what I've understood:
> 
> (Using Rioshin's examples)
> 
> You propose this:
> 
>     static import module.name;
>     alias module.name.foo bar;
> 
>     foo();    // illegal
>     module.name.foo();    // legal
>     bar();    // legal
> 
> With minor syntax variations, here's what others are proposing:
> 
>     with module.name import foo as bar;
> 
>     foo();    // illegal
>     module.name.foo();    // illegal
>     bar();    // legal
> 
> Notice how the FQN would be illegal.
> 
> (That's basically it, right?)

Yes, but I don't think it is a substantive difference.

> ====
> 
> Personally, I think both "static import" (or some variation of it), selective import (with .. import ..) and import with aliasing (import .. as ..) are needed. However, I don't like the "as" syntax: I think a symbol would make it easier to read. My preferred choice would be =, but like this:
> 
>     with a.b.c import f1 = foo1, f2 = foo2, f3 = foo3;
> 
> (Where f1, f2 and f3 are the aliased names.) I think the symbols provide visual stops to understand clearly what's going on. That also makes me dislike:
> 
>     import a.b.c d;
> 
> Because the space is easy to miss. IMO

Some good points.
July 12, 2006
Regan Heath wrote:
> On Wed, 12 Jul 2006 01:03:16 +1200, Regan Heath <regan@netwin.co.nz> wrote:
> 
>> On Tue, 11 Jul 2006 15:56:44 +0300, Georg Wrede <georg.wrede@nospam.org>  wrote:
>>
>>> Bill Baxter wrote:
>>>
>>>> static import module.with.a.long.name.string;
>>>> alias module.with.a.long.name.string Str;
>>>
>>> import module.with.a.long.name.string as Str;
>>>
>>> This keeps "Str" and the module name and the word import on one line,  making it hugely easier to grep for them.
>>
>>
>> Assuming the coder wasn't a 'half sane monkey on crack' you should be  able to open the file in an editor, go to the top and do a search/find  on "Str", the first result should find it. Anything else is either bad  programming practice or a moderately rare case where 2 things include  each other and so one uses the other before it's declaration.

Personally, I do a lot of grepping to find stuff in source trees. Mostly they are recursive greps, i.e., not done within an editor.

For an example, I might want to know with what names this "module.with.a.long.name.string" is imported in the tree. Of course I could create a two-line regexp for the search, but that's a lot of work. And I'd have to allow for a potential comment or empty line(s) in between, for all I know. :-(

But to a more important point, "module.with.a.long.name.string" is only written once. Maintenance gets a lot easier that way.

> In fact a good UI should be able to take you to the declaration of a  symbol with the press of a single button, like F12 in developer studio  does when you have browse info enabled.

I don't know of too many that good IDEs for D.
July 12, 2006
Lars Ivar Igesund wrote:
> Jari-Matti Mäkelä wrote:
> 
>> Lars Ivar Igesund wrote:
>>> I believe I might have been a bit rash here, but I got somewhat pissed
>>> pouring over all the posts for the last few days. I will therefore
>>> restate some of my thoughts in a calmer manner:
>>>
>>> If we for a second ignore the language issues chatted about recently,
>>> most people agree that D is missing libraries to be able to really
>>> compete with other languages. It is therefore unfathomable to me why you
>>> Walter don't actively try to make it easy to create good libraries in D.
>>> Libraries that can be made stable, failsafe and predictable. You have
>>> said many enough times that D is different enough to need different
>>> solutions to problems already solved in other languages. Why is it then
>>> that you seemingly refuse to listen to those that have tried to solve
>>> these problems in D over the years? Those that have found that the
>>> language features in D probably need to be refined to not only make
>>> libraries in D possible, but fun to write, fun to use, safe to use and
>>> with a predictable usage pattern.
>> I think you're a bit too harsh on Walter now. In the recent two week or
>> so Walter has fixed many important things like most of the import bugs.
>> The only thing left are:
>>
>>  * some people thing that imports should be private by default
>>    - changing this would break some old code, but does it matter?
>>     (statistically private imports are much more common)
>>
>>  * most of the people want an additional safe import syntax that allows
>> importing to a custom namespace.
>>
>>  * some general show-stopper bugs
>>
>> The first two of these are luckily easy to fix. We're not far from 1.0.
>> If were not in a hurry, I would like the interface things to be fixed
>> (that double lookup implementation) too before reaching stable. Then D
>> will be perfect for real production level use.
>>
> 
> Ah, maybe I was still too harsh, but I've been around for a while, and we're
> not talking new issues. That it really is mostly all about easy fixes,
> don't make it any more sensible to me that they haven't already been made,
> or why he keep suggesting fixes so cumbersome that noone will use them.
> 

That's what it boils down to. import-and-alias(*) in one step (vs. specific symbol import or both) seems relatively easy to implement and any more argument against that alone just seems silly.

Then there's the specific symbol import that C# (and Perl and Python) allow. I could see where perhaps this would be tougher to implement but I think is well worth it; given large libraries and long namespaces it can really make code easier to build, debug and maintain.

Like Kris though, I'd settle for the first, at least for v1.0.

* import std.stdio stdio; // std.stdio imported and aliased as stdio
July 12, 2006
In article <1wb7225zjf13v.1n8u9dwecz2a8$.dlg@40tude.net>, Derek Parnell says...
>
>On Wed, 12 Jul 2006 02:51:08 +0300, Jari-Matti Mäkelä wrote:
>
>>> Consider the simple situation in Phobos
>>> 
>>>  std.string.find
>>>  std.regexp.find
>>>  internal.gc.gcx.find
>>> 
>>> then add the various other 'find' members in external libraries.
>> 
>> Ok, have to admit that's true. But do you really use them all in the same module?
>
>Apparently, as that's how I got the error messages. ;-)
>
>> If there's only a small amount of conflicting names, the import syntax does not have to be so incredibly complex.
>
>Totally agree. Currently I'm using this sort of syntax ...
>
> import std.string;
> alias std.string.find str_find;
> alias std.string.replace str_replace;
>
> import std.regexp;
> alias std.regexp.find re_find;
> alias std.regexp.replace re_replace;
>
> import util.str;
> alias util.str.find utl_find;

I've written some code similar to this before. It worked, but it was wordy and awkward. (And it seemed to break easily, but that was probably more due to incompetent programming on my part than a weakness of D.)


> import std.string alias str;
> import std.regexp alias re;
> import util.str alias utl;

I really like that proposed syntax. (We don't /need/ new keywords, so we shouldn't need to add new ones.) I can't believe that syntax would be hard for Walter to add, so it should be added. It would be incredibly useful.


> . . .
> re.find( ... );
> . . .
> str.find( ... );
> . . .
> utl.find( ... );
>
>would do nicely, thank you.

Yes, I think that'd be really cool.

jcc7
July 12, 2006
"jcc7" <jcc7_member@pathlink.com> wrote:
> In article <1wb7225zjf13v.1n8u9dwecz2a8$.dlg@40tude.net>, Derek Parnell says...
>> import std.string alias str;
>> import std.regexp alias re;
>> import util.str alias utl;
>
> I really like that proposed syntax. (We don't /need/ new keywords, so we
> shouldn't need to add new ones.) I can't believe that syntax would be hard
> for
> Walter to add, so it should be added. It would be incredibly useful.

The version I wrote (note that I did not like the distinction between 'alias' and 'as', which is why the 'as' was mentioned as optional) with selective imports is what I would like to have - not that I'm that likely to use selective imports, but the idea of having the option is alluring. But I'm willing to settle for aliased imports (implicitly static, mind), for which the approximate grammar would be:

ImportDeclaration:
    'import' ModuleList ';'

ModuleList:
    ModuleDeclaration
    ModuleDeclaration ',' ModuleList

ModuleDeclaration:
    ModuleName 'alias' AliasedName
    ModuleName


July 12, 2006
Rioshin an'Harthen wrote:
> "jcc7" <jcc7_member@pathlink.com> wrote:
>> In article <1wb7225zjf13v.1n8u9dwecz2a8$.dlg@40tude.net>, Derek Parnell says...
>>> import std.string alias str;
>>> import std.regexp alias re;
>>> import util.str alias utl;
>> I really like that proposed syntax. (We don't /need/ new keywords, so we
>> shouldn't need to add new ones.) I can't believe that syntax would be hard
>> for
>> Walter to add, so it should be added. It would be incredibly useful.
> 
> The version I wrote (note that I did not like the distinction between 'alias' and 'as', which is why the 'as' was mentioned as optional) with selective imports is what I would like to have - not that I'm that likely to use selective imports

I guess the libraries are currently written so that there aren't many name conflicts and thus there's no need to use several namespaces.

> But I'm willing to settle for aliased imports (implicitly static, mind), for which the approximate grammar would be:
> 
> ImportDeclaration:
>     'import' ModuleList ';'
> 
> ModuleList:
>     ModuleDeclaration
>     ModuleDeclaration ',' ModuleList
> 
> ModuleDeclaration:
>     ModuleName 'alias' AliasedName
>     ModuleName

Yes, this is much simpler and perhaps also friendlier to newbies. Yet another alternative is to use => -symbol and parenthesis:

import modulename => namespacename, module2;
import modulename(member1, member2) => namespacename(foo, bar);
import modulename(member1, member2) => foo, namespacename(bar);

There are really so many possibilities. I would let Walter choose the syntax he thinks would fit best in D, but let the community decide the functional requirements. There's a nice summary thread started by Lucas there. Perhaps we can all find a consensus there.

-- 
Jari-Matti
1 2 3 4
Next ›   Last »