On Wed, 12 Jul 2006 01:00:32 -0700, Walter Bright <newshound@digitalmars.com> wrote:

>
> I spent about 8 hours yesterday writing posts here. There's only so much I can do - especially since every post I write tends to generate a dozen responses.
>
>
>> Assuming you're considering any change as a result of this conversation, perhaps the details could be settled explicitly, either here or in a separate thread?  I think everyone has said their piece at this point, and it would probably help everyone cool down a bit if things wrapped up with a suggested plan, even if the plan is to not change a thing for reasons X Y and Z.
>
> I agree with waiting until things cool down.


Cool down, yes. "Not change a thing for reason X Y and Z", however, is NOT
a good alternative. I would find that very disturbing considering all the
energy put into this discussion.  That would leave the current problem with
name collisions a chronic problem for D, and many, many hours wasted for
everyone.

Much of the problem here too is that people started swamping this thread
(and other related threads) with numerous ideas for new import constructs.
We don't really need 100 new ideas for a construct at this stage... more so
we need (1) admission that a problem exists with the current import system
and (2) commitment to a fix.

(This whole process of swamping this newsgroup with alternative constructs
has very poor track record.  I'm not saying alternatives shouldn't be
discussed, but it's rather useless to do in this sort of system.  Walter is
incapable of investigating and studying every possibility.  He can barely
can keep up with posts here. Nor can I, for that matter.)

Walter suggested a fix that really didn't appear palatable to a vast
majority of the people here, and yet he remained unconvinced of any
alternatives, despite some very good ones being put forward.  Most of us
agreed that we would settle for something else, almost anything else that
Walter chose as long as it (1) met certain basic criteria (ie no explicit
use of alias, no use of "static import"), (2) was somewhat elegant, and (3)
fixed the original import problem.  That was our compromise, as hard as it
was (even at the expense of losing selective imports which people agreed was
useful but perhaps not critical).

So now we finish with a decision by dictatorship (I'm not being cute here;
just stating the facts) with the same mess of decision by committee... I
think we got nowhere just as fast: that everybody should cool down and
perhaps nothing at all should be done after all.  I'm not impressed.

Not to say a committee is any good, but this is no better, in my opinion, in
that the situation exchanges multi-level bureaucracy for single-level
stonewalling, sieged mightily by numerous community members that seem
tricked into thinking that their numerous suggestions will make a
difference, meanwhile vying with each other over numerous construct
alternatives (if you can follow that sentence, you win a prize; it's about
as clear as what's going on in this thread).  Even Walter can't (nor should
he be expected to) keep up to all the discussion which makes this all a
literal rats nest of useless brainstorming.

Walter, you said in another response to my post that, anybody could have
forked D at any time via gdc.  And the implication was that nobody has done
it because they trust in your leadership.  If that's what you meant, I don't
think that's necessarily the case, and it seems somewhat presumptuous of you
to think that way.  I'd say that people are reticent to do that sort of
thing out of respect for a your intellectual investment: it seems like a
harsh move and /could/ cast doubt on the original authors ability to manage
a language's design.  I really think the community wants to give you the
benefit of the doubt.  We have no desire to mess with what might be the
progress of D.  So see people's reticence to fork as a /desire/ to trust...
not trust it self.

But as time goes on, and more people get doubts about D's evolution, you
surely are tempting people to do consider forking.  Maybe a fork shouldn't
be looked at in such dark and sinister way.  Perhaps you don't mind? Perhaps
you would love to see an alternative that could share the research of a
alternative constructs such that trials could migrate back into the original
D?  I'm not sure if you would mind that or not.  If that's acceptable to
you, I guess it could be a useful alternative for testing out new principles
in D.  And I'd certainly hope that such an idea could be conducted with
cooperation and respect to you.

Cooling down is a great idea, but doing so does nothing to erase the issues
we have faced, currently face, and continue to face with the way D's growth
is managed.

-JJR

Lars Ivar Igesund wrote:
> Walter Bright wrote:
> 
>> Lars Ivar Igesund wrote:
>>> Well, who did ever say that was a good idea, everything public by
>>> default? ;)
>> I did <g>.
> 
> Right :) I don't agree.

Let me explain why I think default public is a good idea.

It reduces clutter in sample, example, and quick programs. Access security is an advanced feature, one that's invaluable for a complex project, but is just in the way for smaller ones.

I don't mind at all when crafting a carefully designed, reusable module that 'private' needs to be explicit. It helps document the intention, and lends the impression that the designer did put some thought into the code.

But when writing illustrative sample code, I feel that having to add in 'public's is distracting from the point (unless, of course, the point is about how access control works!). I see this a lot in sample C++ code, and it is distracting, to me anyway.

And it's just plain irritating when writing smaller programs where access control is quite irrelevant.

Derek Parnell wrote:
> On Wed, 12 Jul 2006 00:39:31 -0700, Walter Bright wrote:
> 
>> Bill Baxter wrote:
>>> All I've heard in this discussion is proponents for these two changes, with the
>>> exception of Walter, of course.
>> There are a lot more D users than people who post here. I hear from them when I make a change that breaks their code, and they are rarely happy about it.
> 
> I can understand that.

I also want to add that it's considered generally true that if you hear a complaint from one person, there's probably another 25 who have the same complaint but don't bother to complain - they just go away.


> If I may be so bold as to say that you really ought
> to telegraph your intentions in detail before implementing them. Especially
> stuff which has the potential to break otherwise conformant code.
> 
> So ... what are you planning for imports and when might we see any changes?

I'll take Sean's suggestion and let things cool down a bit first. Decisions made when feelings are running high tend to be rotten ones <g>.

Derek Parnell wrote:
> On Wed, 12 Jul 2006 01:00:32 -0700, Walter Bright wrote:
>> I was quite surprised at the negative reaction to it from the people who suggested those changes.
> 
> Just to clarify, not *all* people who suggested those changes that you
> implemented were upset by you doing that. I use AAs a lot and I love the
> changes you made to them. 

Thanks for letting me know that. It does make me feel better about that episode.

Walter Bright wrote:

> Lars Ivar Igesund wrote:
>> Walter Bright wrote:
>> 
>>> Lars Ivar Igesund wrote:
>>>> Well, who did ever say that was a good idea, everything public by default? ;)
>>> I did <g>.
>> 
>> Right :) I don't agree.
> 
> Let me explain why I think default public is a good idea.
> 
> It reduces clutter in sample, example, and quick programs. Access security is an advanced feature, one that's invaluable for a complex project, but is just in the way for smaller ones.
> 
> I don't mind at all when crafting a carefully designed, reusable module that 'private' needs to be explicit. It helps document the intention, and lends the impression that the designer did put some thought into the code.
> 
> But when writing illustrative sample code, I feel that having to add in 'public's is distracting from the point (unless, of course, the point is about how access control works!). I see this a lot in sample C++ code, and it is distracting, to me anyway.
> 
> And it's just plain irritating when writing smaller programs where access control is quite irrelevant.

And it here I think you miss the point. When D as a language rather help in writing small example programs, instead of making it easy and safe to write large applications and libraries, how is then D supposed to take the ultimate step? D has so much potential for writing large, powerful applications and libraries, and D continously shoots it down. Illustrative code should show the actual features making the language good to use in larger projects (once they are there, they will contain much larger bodies of code than all the smaller ones combined), not be a goal for the language itself.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Walter Bright wrote:
> Lars Ivar Igesund wrote:
>> Walter Bright wrote:
>>
>>> Lars Ivar Igesund wrote:
>>>> Well, who did ever say that was a good idea, everything public by
>>>> default? ;)
>>> I did <g>.
>>
>> Right :) I don't agree.
> 
> Let me explain why I think default public is a good idea.

For the general case (classes/functions/etc.), I'd say both private and public defaults have their advantages and disadvantages, so OK, but I'd still like you to reconsider imports.


> It reduces clutter in sample, example, and quick programs. Access security is an advanced feature, one that's invaluable for a complex project, but is just in the way for smaller ones.

In single-module programs, it doesn't matter either way
In multiple-module programs (both small and large), the clutter is greater than it would be if imports were private by default.


> And it's just plain irritating when writing smaller programs where access control is quite irrelevant.

Exactly. Yet you force us to declare imports private as soon as more than one module is used.

You seem to miss the obvious fact that most imports serve a module's implementation, not its interface..


BTW, in any case neither the current "import foo" nor potential "public import foo" don't really indicate what they do, at least to me.. how about:

import foo;         // currently "private import foo;"
import/export foo;  // currently "import foo;"

Don't take that too seriously, but it would make things far more obvious...


xs0

On Wed, 12 Jul 2006 19:25:57 +1000, Walter Bright <newshound@digitalmars.com> wrote:

> Lars Ivar Igesund wrote:
>> Walter Bright wrote:
>>
>>> Lars Ivar Igesund wrote:
>>>> Well, who did ever say that was a good idea, everything public by
>>>> default? ;)
>>> I did <g>.
>>  Right :) I don't agree.
>
> Let me explain why I think default public is a good idea.
>
> It reduces clutter in sample, example, and quick programs. Access security is an advanced feature, one that's invaluable for a complex project, but is just in the way for smaller ones.
>
> I don't mind at all when crafting a carefully designed, reusable module that 'private' needs to be explicit. It helps document the intention, and lends the impression that the designer did put some thought into the code.
>
> But when writing illustrative sample code, I feel that having to add in 'public's is distracting from the point (unless, of course, the point is about how access control works!). I see this a lot in sample C++ code, and it is distracting, to me anyway.
>
> And it's just plain irritating when writing smaller programs where access control is quite irrelevant.

Oh for Bob's sake ... you mean the primary purpose of D is to write sample programs and examples? How did I miss that!!?? I thought it was to be a real language to write commercial applications with rather than an educational tool/toy. Sorry I misunderstood.


-- 
Derek Parnell
Melbourne, Australia

Walter Bright wrote:
> Bill Baxter wrote:
>> All I've heard in this discussion is proponents for these two changes, with the
>> exception of Walter, of course.
> 
> There are a lot more D users than people who post here. I hear from them when I make a change that breaks their code, and they are rarely happy about it.

Assuming you're talking about 'private import by default'.

If you bold and highlight it in the change log and the general download page I would think that would be enough. How hard could it be to stick 'public ' in front of ones imports? Especially since they can keep using v0.162 until they make the change?

Walter Bright wrote:
> Lars Ivar Igesund wrote:
>> Walter Bright wrote:
>>
>>> Lars Ivar Igesund wrote:
>>>> Well, who did ever say that was a good idea, everything public by
>>>> default? ;)
>>> I did <g>.
>>
>> Right :) I don't agree.
> 
> Let me explain why I think default public is a good idea.
> 
> It reduces clutter in sample, example, and quick programs. Access security is an advanced feature, one that's invaluable for a complex project, but is just in the way for smaller ones.
> 
> I don't mind at all when crafting a carefully designed, reusable module that 'private' needs to be explicit. It helps document the intention, and lends the impression that the designer did put some thought into the code.

I think you'll get most of us to agree for access control in general and my experience with the language bares that out.

For imports though, many of us feel that private shouldn't need to be explicit because we don't want the side-effects (by default) we may have little control over for such a sweeping statement as 'import' (that may import thousands of symbols, and that may increase geometrically as more top level modules import their own, etc...).

> 
> But when writing illustrative sample code, I feel that having to add in 'public's is distracting from the point (unless, of course, the point is about how access control works!). I see this a lot in sample C++ code, and it is distracting, to me anyway.
> 
> And it's just plain irritating when writing smaller programs where access control is quite irrelevant.

Walter Bright wrote:
> Lars Ivar Igesund wrote:
> 
>> Walter Bright wrote:
>>
>>> Lars Ivar Igesund wrote:
>>>
>>>> Well, who did ever say that was a good idea, everything public by
>>>> default? ;)
>>>
>>> I did <g>.
>>
>>
>> Right :) I don't agree.
> 
> 
> Let me explain why I think default public is a good idea.
> 
> It reduces clutter in sample, example, and quick programs. Access security is an advanced feature, one that's invaluable for a complex project, but is just in the way for smaller ones.

Hmm. So D is becoming an educational language, like Pascal.

> I don't mind at all when crafting a carefully designed, reusable module that 'private' needs to be explicit. It helps document the intention, and lends the impression that the designer did put some thought into the code.

If somebody wants a public import, then /that/ intention should be documented -- not the other way around, right?

> But when writing illustrative sample code, I feel that having to add in 'public's is distracting from the point (unless, of course, the point is about how access control works!). I see this a lot in sample C++ code, and it is distracting, to me anyway.

Problem is, readers of illustrative code tend to copy them in their own first programs, then make similar code, and in time larger pieces of code. They frequently miss the transition point where they should change their behavior (in this case, to start using "private"), and the end result is large code with small-code practices. Very bad, and you can see it all over the place!

> And it's just plain irritating when writing smaller programs where access control is quite irrelevant.

Code should be written so implicitly public imports are not needed!

If I import some high-level module which in turn imports some low-level module, and I happen to need stuff from that low-level module too, I sure as hell better import that explicitly in my program.

Code has to be clear, deliberate, and lucid. This is not achieved by good-luck chained imports. And definitely not by good-luck chained implicit or invisible, or even gratuituous imports.