me too

Roland


Pavel \"EvilOne\" Minayev a écrit :

> "Walter" <walter@digitalmars.com> wrote in message news:9si4hs$2ved$3@digitaldaemon.com...
>
> > I'm more interested in compelling arguments  (!)
>
> Suppose we have the following code:
>
>     int*[]* x, y;
>
> "Old" way: x is pointer to array of pointers, y is an array of
>     pointers. The first asterisk applies to both, the second
>     is applied only to x. Not only it's weird, but just try to
>     define a _clear_ rule (say, for the specification) that
>     strictly defines meaning of asterisk.
>
> New way: both are pointers to array of pointers. Anything
>     that's on the left is part of the type and is applied to
>     all variables on the line, no special cases and
>     exceptions.
>
> I vote for the new one...

Sooo?

Hmm, private imports. That might be a good idea!

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9slg8k$23nj$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:9skeha$1dh9$2@digitaldaemon.com...
>
> > "Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sjljv$v8m$1@digitaldaemon.com...
> > > If module B imports module C, and module A
> > > imports B, does A import C?
> >
> > Scoping issues aside, yes.
>
> So there's no way to import a module for my own,
> "private" use?
>
> Something like that:
>
>     import vector;        // this is visible to everybody
>     private import math;  // this is used internally and thus is visible
> only to myself
>
> And then, forbid any constants and types from private- imported modules to be used in public declarations?
>
>

On Mon, 19 Nov 2001 09:44:01 +0000, Walter wrote:

> Hmm, private imports. That might be a good idea!
> 

Actually, could you explain why public imports are a good idea (in
particular as a default)?

"Ben Cohen" <bc@skygate.co.uk> wrote in message news:9td75g$4ep$1@digitaldaemon.com...
> On Mon, 19 Nov 2001 09:44:01 +0000, Walter wrote:
>
> > Hmm, private imports. That might be a good idea!
> >
>
> Actually, could you explain why public imports are a good idea (in
> particular as a default)?

I agree. Module imports must be private by default. This would provide better control over them.

"Ben Cohen" <bc@skygate.co.uk> wrote in message news:9td75g$4ep$1@digitaldaemon.com...
> On Mon, 19 Nov 2001 09:44:01 +0000, Walter wrote:
> > Hmm, private imports. That might be a good idea!
> Actually, could you explain why public imports are a good idea (in
> particular as a default)?


We obviously are approaching this from different directions :-)

On Tue, 20 Nov 2001 17:38:05 +0000, Walter wrote:

>> > Hmm, private imports. That might be a good idea!
>> Actually, could you explain why public imports are a good idea (in
>> particular as a default)?
> 
> We obviously are approaching this from different directions :-)

Yes, I think so too.  OK then, first I'll explain why I think private imports would be a better default :-)

Suppose you have a module A which imports other modules B, C, and D.  I think
that it is more likely that you don't want all the names in B, C and D to be
imported into an application when you import A.  (E.g., A = http library,
B = networking, etc.)  Not importing B, C and D when the calling application
imports A would be better software engineering; otherwise you would have names
added to your namespace which you didn't expect.

Public imports are a bit like inheritance (and you don't make "public" the default attribute for class members).

Of course, perhaps you are writing an application which needs to use module B independently (e.g., it uses http, and also an extra networking protocol); you can then "import A, B;" in your application.

In the presumably less common case where importing A always requires the application to import B explicitly, then you do need a public import.  (E.g., the application has to open the connection itself for the http library to work?)  But I think the private import is the more common and natural default.

Overall, I like this idea a lot.  However, I would note that, unlike inheritance, if you privately import a library and then another module imports the same library, we don't want duplicate symbols of everything.  It seems to me that we should have only one copy of the module, no matter how many of the chains of modules import it.

Thus, it really isn't a "private" import...it's more of an "extern/intern" issue. I would suggest that the "public" import syntax then be:

extern import A,B;

while the "private" syntax is just:

import C,D;



Also, a side effect of less namespace pollution is that you don't have as many dependencies at build time.  Say module A imports B&C privately, and D imports A. If you modify B, then A will need to be rebuilt...but D does not.  If all imports are public, then a modification to B causes a rebuild of D.  On the other hand, if A also includes a (public) import of E, then modifying E causes rebuilds of both A and D, since both contain the names & types in it.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Ben Cohen" <bc@skygate.co.uk> wrote in message news:9tfs9k$1uhi$1@digitaldaemon.com...
> Public imports are a bit like inheritance (and you don't make "public" the default attribute for class members).

Actually, D does <g>. The idea is to minimize the fluff for quick & dirty programs, while providing the facilities for the more carefully engineered production code.

On Fri, 23 Nov 2001 00:28:09 +0000, Walter wrote:


> "Ben Cohen" <bc@skygate.co.uk> wrote in message news:9tfs9k$1uhi$1@digitaldaemon.com...
>> Public imports are a bit like inheritance (and you don't make "public" the default attribute for class members).
> 
> Actually, D does <g>. The idea is to minimize the fluff for quick & dirty programs, while providing the facilities for the more carefully engineered production code.

Oh, I missed that -- so the keyword "public" would be redundant for class members?

That means either that protected (say) should be the default for classes, or else my argument doesn't work any more, depending on which way you look at it.  ;)