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.

I agree. An interesting example is that many small classes in C++ STL programs use 'struct' instead of 'class' because it defaults to public.
You can find 'struct' all over the Boost libraries! Default public must be worth something.

But I don't think this argument is applicable to imports.
(a) For quick and dirty programs, and for most examples, you don't care if imports are public or not.
(b) Since a module exists in its own file, I don't think the consistency argument carries much weight. Functions in an executable file or DLL are only public if you add 'extern' to them (the program as a whole defaults to 'private'). For modules, we're talking about 'default transitory public' which I think is quite different to 'default public'. I can see over my neighbours fence, but that doesn't mean I can see over *his* neighbours fence (even though he can).

Changing to default private would break code, but it might not break a whole lot of existing code.
(a) I suspect that the majority of quick and dirty imports don't actually care if they are public or private. It's not as if every existing instance of 'import' would need to be changed to 'public import'.
(b) Some existing broken code would be fixed! I keep finding I need to put 'private' in front of 'import' in existing modules, to solve name conflicts.

And any code that would break could be fixed very quickly.

Please consider this issue again. There is still a window to change it before 1.0.

"Don Clugston" wrote:

[ default public ]

> An interesting example is that many small classes in C++ STL programs use
> 'struct' instead of 'class' because it defaults to public.
> You can find 'struct' all over the Boost libraries! Default public must be
> worth something.
>

This is mainly because a specialised keyword is missing.

These structs are neither used as "real classes"
(to be inherited or having virtual functions)
not as "value classes" but mostly for metaprogramming.


In some cases it is because of lazyness to write one more line.

/Pavel

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

I didn't mean it's useful to make D a language to teach people about programming. I meant it's useful for teaching D to people.

It's not always true, but languages that are less wordy in their example code tend to be picked up faster. People's first projects in D aren't going to be large, complex, professional products. They'll want to just try it out on something simple. That bar should be as low as reasonable.

Don Clugston wrote:
> Walter Bright wrote:
>> And it's just plain irritating when writing smaller programs where access control is quite irrelevant.
> I agree. An interesting example is that many small classes in C++ STL programs use 'struct' instead of 'class' because it defaults to public.
> You can find 'struct' all over the Boost libraries! Default public must be worth something.

If you write classes like:

	struct Point { int x, y; }

It's just irritating to have to write it:

	struct Point { public int x, y; }

Quite a lot of classes have all public members.

> But I don't think this argument is applicable to imports.
> (a) For quick and dirty programs, and for most examples, you don't care if imports are public or not.

That's a good point.

> (b) Since a module exists in its own file, I don't think the consistency argument carries much weight. Functions in an executable file or DLL are only public if you add 'extern' to them (the program as a whole defaults to 'private').

Minor nit: 'export', not 'extern'.

> For modules, we're talking about 'default transitory public' which I think is quite different to 'default public'. I can see over my neighbours fence, but that doesn't mean I can see over *his* neighbours fence (even though he can).
> 
> Changing to default private would break code, but it might not break a whole lot of existing code.
> (a) I suspect that the majority of quick and dirty imports don't actually care if they are public or private. It's not as if every existing instance of 'import' would need to be changed to 'public import'.
> (b) Some existing broken code would be fixed! I keep finding I need to put 'private' in front of 'import' in existing modules, to solve name conflicts.
> 
> And any code that would break could be fixed very quickly.
> 
> Please consider this issue again. There is still a window to change it before 1.0.

I think you've made a pretty good case for it.

Walter Bright wrote:
> Don Clugston wrote:
>> Walter Bright wrote:
>>> And it's just plain irritating when writing smaller programs where access control is quite irrelevant.
>> I agree. An interesting example is that many small classes in C++ STL programs use 'struct' instead of 'class' because it defaults to public. You can find 'struct' all over the Boost libraries! Default public must be worth something.
> 
> If you write classes like:
> 
>     struct Point { int x, y; }
> 
> It's just irritating to have to write it:
> 
>     struct Point { public int x, y; }
> 
> Quite a lot of classes have all public members.
> 
>> But I don't think this argument is applicable to imports.
>> (a) For quick and dirty programs, and for most examples, you don't
>> care if imports are public or not.
> 
> That's a good point.
> 
>> (b) Since a module exists in its own file, I don't think the consistency argument carries much weight. Functions in an executable file or DLL are only public if you add 'extern' to them (the program as a whole defaults to 'private').
> 
> Minor nit: 'export', not 'extern'.
> 
>> For modules, we're talking about 'default transitory public' which I think is quite different to 'default public'. I can see over my neighbours fence, but that doesn't mean I can see over *his* neighbours fence (even though he can).
>>
>> Changing to default private would break code, but it might not break a
>> whole lot of existing code.
>> (a) I suspect that the majority of quick and dirty imports don't
>> actually care if they are public or private. It's not as if every
>> existing instance of 'import' would need to be changed to 'public
>> import'.
>> (b) Some existing broken code would be fixed! I keep finding I need to
>> put 'private' in front of 'import' in existing modules, to solve name
>> conflicts.
>>
>> And any code that would break could be fixed very quickly.
>>
>> Please consider this issue again. There is still a window to change it before 1.0.
> 
> I think you've made a pretty good case for it.

oh SWEET !!!!!

BA

"Walter Bright" <newshound@digitalmars.com> wrote in message news:e93hja$1sfu$1@digitaldaemon.com...
> Don Clugston wrote:
>> Walter Bright wrote:
>>> And it's just plain irritating when writing smaller programs where access control is quite irrelevant.
>> I agree. An interesting example is that many small classes in C++ STL programs use 'struct' instead of 'class' because it defaults to public.
>> You can find 'struct' all over the Boost libraries! Default public must be worth something.
>
> If you write classes like:
>
> struct Point { int x, y; }
>
> It's just irritating to have to write it:
>
> struct Point { public int x, y; }
>
> Quite a lot of classes have all public members.
>
>> But I don't think this argument is applicable to imports.
>> (a) For quick and dirty programs, and for most examples, you don't care if imports are public or not.
>
> That's a good point.
>
>> (b) Since a module exists in its own file, I don't think the consistency argument carries much weight. Functions in an executable file or DLL are only public if you add 'extern' to them (the program as a whole defaults to 'private').
>
> Minor nit: 'export', not 'extern'.
>
>> For modules, we're talking about 'default transitory public' which I think is quite different to 'default public'. I can see over my neighbours fence, but that doesn't mean I can see over *his* neighbours fence (even though he can).
>>
>> Changing to default private would break code, but it might not break a whole lot of existing code.
>> (a) I suspect that the majority of quick and dirty imports don't actually care if they are public or private. It's not as if every existing instance of 'import' would need to be changed to 'public import'.
>> (b) Some existing broken code would be fixed! I keep finding I need to put 'private' in front of 'import' in existing modules, to solve name conflicts.
>>
>> And any code that would break could be fixed very quickly.
>>
>> Please consider this issue again. There is still a window to change it before 1.0.
>
> I think you've made a pretty good case for it.


Once again, the case was made based on C++.  That certainly makes it difficult to convince you any other way, and leaves a lot of non-C++ people incapable of ever making a strong argument for D changes.  You seem to have a strong attachment to the C++ community still.  There's a lot of peer pressure there, I guess?

Oh well, hopefully everything works out.

-JJR

Walter Bright wrote:

> kris wrote:
>> Personally, I have to wonder what compelling reason there is to continue ploughing so much effort into helping make D a success, behind the scenes, when it appears to have so little value in your eyes.
> 
> Language design is hardly cut and dried. There is rarely a right and a wrong answer. There are only benefits and costs, and those vary from application to application, and peoples' opinions of them vary as well.
> 
> You and I have different opinions about how certain things should work. Nothing more should be read into it than that.

But you would have to agree with the fact that on this matter and quite a few others, more people tend to agree with Kris rather than you?

I am very happy that you seem to go for "private by default", but if you don't actually give us a real solution to the symbol collision mess (without using those static or alias), we are after all seeing a rare agreement in this NG that your proposed solution is more or less worse than what we already have, I suspect the discussions will flare again with even more intensity. Cooling down the discussion don't mean that we should implement a bad solution. Private imports by default are just minor nitpicks compared to the namespace collision problems.

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

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.

Let me just say that I am *not* one of those people. I've been letting my more esteemed colleagues (Kris, Sean, Lars, et al) do the talking. I just want to remind you, Walter, that these are those who have written the most code, at least publicly, in your language. Perhaps you should lend more weight to their arguments because of this.

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright

Walter Bright wrote:
> kris wrote:
> 
>> Personally, I have to wonder what compelling reason there is to continue ploughing so much effort into helping make D a success, behind the scenes, when it appears to have so little value in your eyes.
> 
> 
> Language design is hardly cut and dried. There is rarely a right and a wrong answer. There are only benefits and costs, and those vary from application to application, and peoples' opinions of them vary as well.
> 
> You and I have different opinions about how certain things should work. Nothing more should be read into it than that.


Excuse me ... you and the *community* have different opinions !

Do yourself, and everyone here, a big favour and stop insisting this this is between you and I. By doing so, you send a clear message that the opinions of everyone else clamouring (or begging) for exactly the same thing is utterly worthless. That the community segment requesting this small change simply don't know what they are talking about. Fools that we all are.

The attitude here is exactly what was alluded to in the original post; you make a point of utterly ignoring (and removing) the principal points, and contort what little is left. Frankly, such behaviour should not be tolerated within this community.

To make it perfectly clear, yet again, we're *all* asking for the equivalent of a combined import and alias:

import x.y.z as n;

where n becomes a required prefix. We're not interested in using alias as a secondary instruction, for all the myriad reasons noted that you have yet to even acknowledge exist. And the "static import", as you've surely seen by the many negative responses, simply does not cut the mustard with the D community.

I'm reattaching the original post, Since the essence there has been lost:






Walter Bright wrote:

> kris wrote:
>
>> Anyone would think we were trying to sabotage the language,
>
>
>
> Nobody thinks that. We are all trying to get the best design for D possible. That doesn't mean we are all going to agree on what the best design is. There's no cause to label a difference of opinion as sabotage, or any of the other epithets bandied about in this disagreement (or some of the previous ones).


You know, Walter, I'm more than willing to apologize profusely if you honestly feel you've been undeservedly slighted. And will do so earnestly and sincerely.

On the same token, there's little point in me denying that your approach here, as in previous similar discourse, is frustrating to the extreme; to the point where it often appears there's a notable lack of integrity, despite the presence of various other attributes which might otherwise be conducive to progress. Some will quietly agree with that, and some will disagree. Doesn't matter much.

What does matter (to me and probably to most of us) is the success of D in the one place where we can happily use it on a daily basis: where we get paid to use it. A small percentage of the D supporters go out of their way in order to help make that happen, Yet, you appear content to flatly dismiss a collective request for what seems to be a minor change.

Makes zero sense, and when my frustration with this aspect boils over then it's not exactly a big surprise to you or anyone else. You and I have a history of such exchanges, and that doesn't help either. However, it is more than thoroughly disappointing to see the community opinion dismissed in such a manner. Makes it harder to retain a level of faith in the genuine integrity of the overall situation; try as one might.

I'd like to gently suggest you place more value in those supporting D with their sustained efforts. Much more than zero. They are, after all, the very people who will be the most profound evangelists. That's not to say you should be swayed by individual opinion. Not at all. On the other hand, taking the position that you alone have the right answers while a significant group of experienced developers are united (with zero detractors!) in a request for a minor yet far-reaching positive change, is one that tends to shut the door on entirely the wrong people.

You've labeled this a "difference of opinion". If so, it would appear to be between you and a proactive, motivated, and valuable segment of the community.

Personally, I have to wonder what compelling reason there is to continue ploughing so much effort into helping make D a success, behind the scenes, when it appears to have so little value in your eyes. I'm far from being the first to feel this way, and probably won't be the last. Naturally one can hardly expect you to be able to provide such a reason, but I will urge you again to place some merit in the experience and knowledge of this group. As individuals, none of us are infallible.

Walter Bright wrote:
> Don Clugston wrote:
>> Walter Bright wrote:
>>> And it's just plain irritating when writing smaller programs where access control is quite irrelevant.
>> I agree. An interesting example is that many small classes in C++ STL programs use 'struct' instead of 'class' because it defaults to public.
>> You can find 'struct' all over the Boost libraries! Default public must be worth something.
> 
> If you write classes like:
> 
>     struct Point { int x, y; }
> 
> It's just irritating to have to write it:
> 
>     struct Point { public int x, y; }
> 
> Quite a lot of classes have all public members.
> 
>> But I don't think this argument is applicable to imports.
>> (a) For quick and dirty programs, and for most examples, you don't care if imports are public or not.
> 
> That's a good point.
> 
>> (b) Since a module exists in its own file, I don't think the consistency argument carries much weight. Functions in an executable file or DLL are only public if you add 'extern' to them (the program as a whole defaults to 'private').
> 
> Minor nit: 'export', not 'extern'.
> 
>> For modules, we're talking about 'default transitory public' which I think is quite different to 'default public'. I can see over my neighbours fence, but that doesn't mean I can see over *his* neighbours fence (even though he can).
>>
>> Changing to default private would break code, but it might not break a whole lot of existing code.
>> (a) I suspect that the majority of quick and dirty imports don't actually care if they are public or private. It's not as if every existing instance of 'import' would need to be changed to 'public import'.
>> (b) Some existing broken code would be fixed! I keep finding I need to put 'private' in front of 'import' in existing modules, to solve name conflicts.
>>
>> And any code that would break could be fixed very quickly.
>>
>> Please consider this issue again. There is still a window to change it before 1.0.
> 
> I think you've made a pretty good case for it.

Wow, this sounds very good :)