On Sun, 09 Jul 2006 11:59:37 +1000, Kirk McDonald <kirklin.mcdonald@gmail.com> wrote:


> I posted this proposal earlier, but I like it so much I'll repeat myself:
>
> import B with bar;
> bar(); // unambiguous
>
> The point is you can list multiple names from the module without repeating the module name:
>
> import MyModule with foo, baz;
>
> And "with" is already a keyword.

So what? But if you did want to reuse the "with" keyword why not use it in the same manner...

 with MyModule import foo, baz;


-- 
Derek Parnell
Melbourne, Australia

Derek Parnell wrote:
> On Sun, 09 Jul 2006 11:59:37 +1000, Kirk McDonald  <kirklin.mcdonald@gmail.com> wrote:
> 
> 
>> I posted this proposal earlier, but I like it so much I'll repeat myself:
>>
>> import B with bar;
>> bar(); // unambiguous
>>
>> The point is you can list multiple names from the module without  repeating the module name:
>>
>> import MyModule with foo, baz;
>>
>> And "with" is already a keyword.
> 
> 
> So what? But if you did want to reuse the "with" keyword why not use it in  the same manner...
> 
>  with MyModule import foo, baz;
> 
> 

It makes the grammar simpler to start both with "import," I think. I also think it reads better. Both work, though. I am not picky, and will be happy no matter what actual keywords we get for this functionality, so long as we get it.

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

Walter Bright wrote:
> 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.

Hrm;

The use of alias, regarding imports, should very likely be kept to a bare minimum in anything other than Q&D development. Ideally zero.

It's like the use of goto ~ use it where it can really help, but otherwise consider alternatives instead. I don't know what kind of development-scales you have in mind for D, but I'll happily testify that a boatload of aliases littering the imports would have no place in any project I'm responsible for; nor in those of the people I learned from. Here's why:

Quantities of alias do little but complicate ones comprehension of the code. Having a second-step (import then alias) is not only messy for each import, it does nothing to /encourage/ smart usage of namespace seperation. In fact, the extra step will likely discourage everyone but the diehards from using anything but the current global namespace, and we'll end up right back at square one.

At that point, the language would be lacking. And why? This is all about maturity and usability of the language in specific areas. Why the rollback to something that can be considered "arcane" instead?

Hey ~ if you'd actually roll in the changes, I'd be happy to make them myself ... I'd add both selective import and the "as" variation ~ a flexible combination to handle all cases, including the one Derek astutely pointed out. No aliases required by the user:

// import as we know it today, and with a required prefix "locale."
import lib.text.locale;
import lib.text.locale as locale;

// selective import of one entity, and alternatively with an alias
import lib.text.locale.Time;
import lib.text.locale.Time as otherTime;

==================================

Okay. Let's reflect for a moment?

The functionality is there, but the syntax could probably be better? There's a number of other posts proposing the use of "with" and so on, which look rather promising (from Kirk & Derek):

with lib.text.locale import Time, Date;

Seems pretty darned clear what's going on there. Seems to me that's a much more user-focused solution for selective imports. Let's combine this with a means to import an entire module under a prefix, as we've previously seen:

     // import as we know it today
import lib.text.locale;
auto time = new Time;

     // "locale." prefix required (great for IFTI modules)
import lib.text.locale as locale;
auto utc = locale.utcTime();
auto dst = locale.daylightSavings();

     // selective import
with lib.text.locale import Time, Date;
auto time = new Time;
auto date = new Date;

     // selective import with alias
with lib.text.locale import Time, Date as MyDate;
auto time = new Time;
auto date = new MyDate;

==================================

How about it?

Kirk McDonald wrote:
> Derek Parnell wrote:
> 
>> On Sun, 09 Jul 2006 11:59:37 +1000, Kirk McDonald  <kirklin.mcdonald@gmail.com> wrote:
>>
>>
>>> I posted this proposal earlier, but I like it so much I'll repeat myself:
>>>
>>> import B with bar;
>>> bar(); // unambiguous
>>>
>>> The point is you can list multiple names from the module without  repeating the module name:
>>>
>>> import MyModule with foo, baz;
>>>
>>> And "with" is already a keyword.
>>
>>
>>
>> So what? But if you did want to reuse the "with" keyword why not use it in  the same manner...
>>
>>  with MyModule import foo, baz;
>>
>>
> 
> It makes the grammar simpler to start both with "import," I think. I also think it reads better. Both work, though. I am not picky, and will be happy no matter what actual keywords we get for this functionality, so long as we get it.
> 

That is *very* clear syntax. Hope you don't mind that I used it in a follow-up post ...

kris wrote:
> Walter Bright wrote:
> 
>> 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.
> 
> 
> Hrm;
> 
> The use of alias, regarding imports, should very likely be kept to a bare minimum in anything other than Q&D development. Ideally zero.
> 
> It's like the use of goto ~ use it where it can really help, but otherwise consider alternatives instead. I don't know what kind of development-scales you have in mind for D, but I'll happily testify that a boatload of aliases littering the imports would have no place in any project I'm responsible for; nor in those of the people I learned from. Here's why:
> 
> Quantities of alias do little but complicate ones comprehension of the code. Having a second-step (import then alias) is not only messy for each import, it does nothing to /encourage/ smart usage of namespace seperation. In fact, the extra step will likely discourage everyone but the diehards from using anything but the current global namespace, and we'll end up right back at square one.
> 
> At that point, the language would be lacking. And why? This is all about maturity and usability of the language in specific areas. Why the rollback to something that can be considered "arcane" instead?
> 
> Hey ~ if you'd actually roll in the changes, I'd be happy to make them myself ... I'd add both selective import and the "as" variation ~ a flexible combination to handle all cases, including the one Derek astutely pointed out. No aliases required by the user:
> 
> // import as we know it today, and with a required prefix "locale."
> import lib.text.locale;
> import lib.text.locale as locale;
> 
> // selective import of one entity, and alternatively with an alias
> import lib.text.locale.Time;
> import lib.text.locale.Time as otherTime;
> 
> ==================================
> 
> Okay. Let's reflect for a moment?
> 
> The functionality is there, but the syntax could probably be better? There's a number of other posts proposing the use of "with" and so on, which look rather promising (from Kirk & Derek):
> 
> with lib.text.locale import Time, Date;
> 
> Seems pretty darned clear what's going on there. Seems to me that's a much more user-focused solution for selective imports. Let's combine this with a means to import an entire module under a prefix, as we've previously seen:
> 
>      // import as we know it today
> import lib.text.locale;
> auto time = new Time;
> 
>      // "locale." prefix required (great for IFTI modules)
> import lib.text.locale as locale;
> auto utc = locale.utcTime();
> auto dst = locale.daylightSavings();
> 
>      // selective import
> with lib.text.locale import Time, Date;
> auto time = new Time;
> auto date = new Date;
> 
>      // selective import with alias
> with lib.text.locale import Time, Date as MyDate;
> auto time = new Time;
> auto date = new MyDate;
> 
> ==================================
> 
> How about it?
> 

Yes! All of this is good.

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

John Reimer wrote:
> 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
> 
> 
> 


It takes a lot of courage to stand up and say something like that, so I'll be first to give you an ovation ... very well said, John. Hear Hear!

One has to wonder whether this type of online "environment" is conducive to solid progress anyway? I mean, we're all a bit disembodied, and the experience is really nothing like sitting down together for an afternoon with a whiteboard, and thrashing through issues. Can't even get close to that. We have zero body-language cues to guide us, and with differing opinions that can be a crucial factor in reaching a resolution or not.

Bruno Medeiros wrote:
> Well, that clearly states that private members should not be invisible in C++, but I'm having trouble understanding why. He says "Without it, private out-of-class member declarations become impractical to parse in the general case." but I don't see how or why, anyone has an example or clarification?

I don't understand that, either.

My best guess is that getting consistent overloading results when changing protections was deemed by Bjarne to be less surprising, but I'm just guessing.

"Derek Parnell" <derek@psych.ward> wrote in message news:op.tceexnbq6b8z09@ginger.vic.bigpond.net.au...
> On Sun, 09 Jul 2006 10:54:03 +1000, Walter Bright <newshound@digitalmars.com> wrote:
>
>
>> 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
>
> Why not join the two ...
>
>   import x.y.mod alias t;
>
>   t.foo();
>
Good idea.  That way the aliases are right where you can see them as opposed to god knows where.

> -- 
> Derek Parnell
> Melbourne, Australia

John Reimer wrote:
[...]

thank you for saying that JJR.
I tried to say it before but my style is aggressive, curt and confrontational - but that's exactly what I meant.

and Walter dont' forget:
> 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
[...]
> -JJR

I give up posting because my posts became too negative.
but I'm still here - that says more then anything else.

thank again Walter.

Ant

Bruno Medeiros wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> Derek Parnell wrote:
>>>> I'm sorry Walter but I don't give newt's fart about C++. If I wanted to code under the rules of C++, I'd use C++. You have changed (improved) many of the C++ rules in D, so why not get this one right too?
>>>
>>> I agree that D exists to fix broken rules in C++, but we need to understand the rationale for why they are the way they are in C++, else we run the risk of making a severe error. I don't recall why the access rules are the way they are in C++, but I do know they weren't don't that way for backwards compatibility.
>>
>> Please see my post here:
>>
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39072
>>
>> According to Daveed Vandevoorde:
>>
>>    The fact that private members are inaccessible but not invisible
>>    regularly surprises incidental programmers. Like macros, seemingly
>>    unrelated declarations interfere with subsequent code. Unfortunately,
>>    there are good reasons for this state of affair: Without it, private
>>    out-of-class member declarations become impractical to parse in the
>>    general case.
> 
> Well, that clearly states that private members should not be invisible in C++, but I'm having trouble understanding why. He says "Without it, private out-of-class member declarations become impractical to parse in the general case." but I don't see how or why, anyone has an example or clarification?

It seems he's implying that "truly invisible" privates would require two separate methods of symbol lookup: one for calling functions and another for defining them (if the definition occurs outside class scope where the function being defined should technically be invisible).  I still don't really see the technical hurdle there, but then I've never written a C++ compiler so perhaps it would turn out to be more difficult in practice than in theory.  Perhaps it was simply something perceived difficult at the time the decision was made?  In any case, I'm hoping Walter can find out more than I did here.


Sean