On Mon, 10 Jul 2006 09:30:32 +1000, Derek Parnell <derek@psych.ward> wrote:
> On Mon, 10 Jul 2006 08:43:17 +1000, Regan Heath <regan@netwin.co.nz> wrote:
>
>> On Sun, 9 Jul 2006 19:15:29 +0000 (UTC), John Reimer <John_member@pathlink.com> wrote:
>>> In article <e8rhud$1cca$1@digitaldaemon.com>, Deewiant says...
>>>>
>>>> John Reimer wrote:
>>>>> Also, for selective import, I think using "from" instead of "with" looks much
>>>>> better.
>>>>>
>>>>
>>>> "from" is a quite common variable name though, so introducing it as a keyword
>>>> would probably break a lot of code.
>>>>
>>>
>>>
>>> It is?  I don't see "from" very often.  Seems like an unusual name for a
>>> variable.  Saying it will break "a lot" of code seems like an exaggeration.
>>
>> You don't write a mail server ;)
>
> I don't use multi-character identifier names that don't have at least one uppercase character. ;)

Ahh.. you'd call it "emailFrom" or "EmailFrom" or similar. :)

Regan

In article <optcf1efmv23k2f5@nrage>, Regan Heath says...
>
>On Sun, 9 Jul 2006 19:15:29 +0000 (UTC), John Reimer <John_member@pathlink.com> wrote:
>> In article <e8rhud$1cca$1@digitaldaemon.com>, Deewiant says...
>>>
>>> John Reimer wrote:
>>>> Also, for selective import, I think using "from" instead of "with"
>>>> looks much
>>>> better.
>>>>
>>>
>>> "from" is a quite common variable name though, so introducing it as a
>>> keyword
>>> would probably break a lot of code.
>>>
>>
>>
>> It is?  I don't see "from" very often.  Seems like an unusual name for a variable.  Saying it will break "a lot" of code seems like an exaggeration.
>
>You don't write a mail server ;)
>
>Regan


LOL!  Yes, you are right!  Touche! :D

-JJR

Dave wrote:
> Actually, how about:
> 
> import from some.long.modid func as f1, abcd, efgh as zzz;
> private import from this.other.cool.db.lib as dblib;
> 
> Is more consistent w/ current syntax, maintains the visual continuity, allows more than one symbol import per module (w/o retyping the module), and combines the import w/ the alias if desired.
> 
> - Dave


Don't wish to belabour the point, but why the private attribute when it's not really required?

Traditional import:

a - import lib.text.locale;

Safe import:

b - import lib.text.locale as locale;


Selective safe import variations:

1 - import from lib.text.locale Date, Time as myTime;

2 - import lib.text.locale.Date;
    import lib.text.locale.Time as myTime;

3 - with lib.text.locale import Date, Time as myTime;


If import consistency is deemed desirable, then #1 & #2 perhaps looks like the most appropriate in that context? Although the latter seems notably more verbose. Personally, I like your #1 due to the consistency of the leading "import"

Whatever the outcome, daily usage should be simple to use and maintain, obvious, and not tiresomely redundant -- we want to encourage the use of the safe import.

------------

Contrived illustration:

module lib.net.server.ftp;

import lib.io.file,
       lib.text.convert.utf as utf;

import from lib.text.locale Date, Time;

On Mon, 10 Jul 2006 11:32:45 +1200, Regan Heath wrote:

>>> You don't write a mail server ;)
>>
>> I don't use multi-character identifier names that don't have at least one uppercase character. ;)
> 
> Ahh.. you'd call it "emailFrom" or "EmailFrom" or similar. :)

Yeah, something like that.


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
10/07/2006 10:43:46 AM

On Sun, 09 Jul 2006 16:57:55 -0700, kris wrote:

> Dave wrote:
>> Actually, how about:
>> 
>> import from some.long.modid func as f1, abcd, efgh as zzz; private import from this.other.cool.db.lib as dblib;
>> 
>> Is more consistent w/ current syntax, maintains the visual continuity, allows more than one symbol import per module (w/o retyping the module), and combines the import w/ the alias if desired.
>> 
>> - Dave
> 
> Don't wish to belabour the point, but why the private attribute when it's not really required?

Because a 'private' import is supposed to prevent modules that import the one with the private import from seeing the members of that privately imported module. Otherwise it could reference those members *as if* it had also imported it.

The examples below ignore the current bug in DMD about FQN overriding privacy.

 -- aaa.d --
 int X;

 -- bbb.d --
 private import aaa;
 void func_bbb()
 {
  aaa.X = 1;
 }

 -- ccc.d ---
 import bbb;
 void func_ccc()
 {
  aaa.X = 5; // Illegal 'cos bbb imported aaa privately.
 }


However ...

 -- bbb.d --
 import aaa;
 void func_bbb()
 {
  aaa.X = 1;
 }

 -- ccc.d ---
 import bbb;
 void func_ccc()
 {
  aaa.X = 5; // Okay now.
 }


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
10/07/2006 10:45:15 AM

kris wrote:
> Dave wrote:
>> Actually, how about:
>>
>> import from some.long.modid func as f1, abcd, efgh as zzz;
>> private import from this.other.cool.db.lib as dblib;
>>
>> Is more consistent w/ current syntax, maintains the visual continuity, allows more than one symbol import per module (w/o retyping the module), and combines the import w/ the alias if desired.
>>
>> - Dave
> 
> 
> Don't wish to belabour the point, but why the private attribute when it's not really required?
> 

I missed that... You're right, no need for 'private'.

> Traditional import:
> 
> a - import lib.text.locale;
> 
> Safe import:
> 
> b - import lib.text.locale as locale;
> 
> 
> Selective safe import variations:
> 
> 1 - import from lib.text.locale Date, Time as myTime;
> 
> 2 - import lib.text.locale.Date;
>     import lib.text.locale.Time as myTime;
> 
> 3 - with lib.text.locale import Date, Time as myTime;
> 
> 
> If import consistency is deemed desirable, then #1 & #2 perhaps looks like the most appropriate in that context? Although the latter seems notably more verbose. Personally, I like your #1 due to the consistency of the leading "import"
> 

I tend to forget things if I don't use a syntax (or a language) for a while; the more consistent things are the less I have to RTFM for something I've forgotten - just my preference. I think it'll probably be important for brand-newbies too, along with the aforementioned scanning code for imports.

The other part of it is that the C-lineage languages all start their 'includes' with a verb, not a preposition, so #1 just feels more natural than #3.

> Whatever the outcome, daily usage should be simple to use and maintain, obvious, and not tiresomely redundant -- we want to encourage the use of the safe import.
> 
> ------------
> 
> Contrived illustration:
> 
> module lib.net.server.ftp;
> 
> import lib.io.file,
>        lib.text.convert.utf as utf;
> 
> import from lib.text.locale Date, Time;
> 
> 

Dave wrote:
> kris wrote:
>> Dave wrote:
>>> Actually, how about:
>>>
>>> import from some.long.modid func as f1, abcd, efgh as zzz;
>>> private import from this.other.cool.db.lib as dblib;
>>>
>>> Is more consistent w/ current syntax, maintains the visual continuity, allows more than one symbol import per module (w/o retyping the module), and combines the import w/ the alias if desired.
>>>
>>> - Dave
>>
>>
>> Don't wish to belabour the point, but why the private attribute when it's not really required?
>>
> 
> I missed that... You're right, no need for 'private'.
> 

Hmm, that is if the new syntax proposals import exclusively into the current module, which I had thought I'd read somewhere earlier when I replied. Is that the case?

Otherwise 'private import' would be needed for the same reasons it is used now.

>> Traditional import:
>>
>> a - import lib.text.locale;
>>
>> Safe import:
>>
>> b - import lib.text.locale as locale;
>>
>>
>> Selective safe import variations:
>>
>> 1 - import from lib.text.locale Date, Time as myTime;
>>
>> 2 - import lib.text.locale.Date;
>>     import lib.text.locale.Time as myTime;
>>
>> 3 - with lib.text.locale import Date, Time as myTime;
>>
>>
>> If import consistency is deemed desirable, then #1 & #2 perhaps looks like the most appropriate in that context? Although the latter seems notably more verbose. Personally, I like your #1 due to the consistency of the leading "import"
>>
> 
> I tend to forget things if I don't use a syntax (or a language) for a while; the more consistent things are the less I have to RTFM for something I've forgotten - just my preference. I think it'll probably be important for brand-newbies too, along with the aforementioned scanning code for imports.
> 
> The other part of it is that the C-lineage languages all start their 'includes' with a verb, not a preposition, so #1 just feels more natural than #3.
> 
>> Whatever the outcome, daily usage should be simple to use and maintain, obvious, and not tiresomely redundant -- we want to encourage the use of the safe import.
>>
>> ------------
>>
>> Contrived illustration:
>>
>> module lib.net.server.ftp;
>>
>> import lib.io.file,
>>        lib.text.convert.utf as utf;
>>
>> import from lib.text.locale Date, Time;
>>
>>

Dave wrote:
> Dave wrote:
>> kris wrote:
>>> Don't wish to belabour the point, but why the private attribute when it's not really required?
>>>
>>
>> I missed that... You're right, no need for 'private'.
>>
> 
> Hmm, that is if the new syntax proposals import exclusively into the current module, which I had thought I'd read somewhere earlier when I replied. Is that the case?
> 
> Otherwise 'private import' would be needed for the same reasons it is used now.

I apologize ... thought you were using the 'private' keyword as a replacement for Walter's "static import" thingy ... Sorry

So, yes ~ private/package/public/whatever should operate exactly as it does today. Well, I mean "operate as it is supposed to work" today ;)

Derek Parnell wrote:
>> 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;
> 

This is starting to look a lot like Python syntax:

from MyModule import foo, baz
from MyModule import veryLongName as vln


If you use the simple syntax in Python, you need to fully qualify names when you use them:

import MyModule

MyModule.baz


You can also import all names into the current namespace:

from MyModule import *


Or alias:

import MyModule as MM


Would have been great to have all this control and flexibility in D.


Or instead of 'with', does using 'scope' make sense?

import scope MyModule foo, baz

Tydr Schnubbis wrote:
> Derek Parnell wrote:
> 
>>> 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;
>>
> 
> This is starting to look a lot like Python syntax:
> 
[snip]

That's where it came from in the first place. :-)

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