Regan Heath wrote:
> On Tue, 11 Jul 2006 04:16:29 -0700, kris <foo@bar.com> wrote:
>> 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).
>>
>> It's far beyond a difference of opinion, Walter. Just look at the swell of experienced developers here literally begging for you to make a small change. Instead of listening carefully with an open mind, you project a closed and vacant shell. I think you'd have to agree that this is one serious issue.
>>
>> Why do you simply stonewall it? The projection is as though you're not even open to discussion.
> 
> I think you're being unfair, I'm not getting that impression.
> 
> Regan

I'm not getting that impression either. You (kris) were right about the problem of a lack of FQN import, and now everyone, Walter in particular, agree that it should be fixed[*].
But as for the other import features, I'm not sure the demand is that overwhelming. It's not the size of the thread that should judge that, there is lots of confusion(as Regan said) and also remnants of the original discussions. (Or maybe I'm just being "sly and blind"..)

[*] It is thanks to you kris, that of lack of FQN imports is now decided to be fixed. Despite I having mentioned this issue over a year ago, and also recently before this thread, you presented a hard and immediate example problem, which didn't occur to me or anyone else who participated in the previous discussions (the ones known of at least), and which convinced Walter to fix it.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> 
> [*] It is thanks to you kris, that of lack of FQN imports is now decided to be fixed. Despite I having mentioned this issue over a year ago, and also recently before this thread, you presented a hard and immediate example problem, which didn't occur to me or anyone else who participated in the previous discussions (the ones known of at least), and which convinced Walter to fix it.
> 

Examples, hard evidence, *pragmatism* are the key to getting things changed. And it's the best standard IMO.

Walter is basing his resistance to syntax changes (i.e.: along the lines of from / as) because he hasn't yet seen much _D_ code that would greatly benefit from it. I submit that there is a good body of evidence written in Java, C# and Python - the large and diverse libraries - because we all hope D libs. will soon emulate those in usefulness.

Dave wrote:
> 
> There also the 'using x = [namespace|symbol];' form, which allows you to assign a namespace _or_ a specific symbol a different name.
> 
> See: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/40005
> 

Ah, I had read that post after I posted.

> I think they by and large got it right.
> 

I think so too. C# imports are easier to work with than D.

> An interesting aside is that FQN's are pretty rare in C# as the amount of code to type / scan / read explodes because of the long namespace names in the .NET lib.

I've seen a few FQN's, but yes they are very rare.

Lucas

Bruno Medeiros wrote:
> 
> Sidenote: C#'s using-namespace and using-alias do not create new members in where they are imported, they are not transitive. In other words, they are like "private import". (As everyone says D's import should be by default...)
> 

This is why I get along with C# a lot better.

Lucas

Walter Bright wrote:
> John Reimer wrote:
> 
>> I've seen this error also on several occasions.  I can't remember the exact source of it, but I think it's related to another issue.  It was my understanding that that was due to public imports somewhere up the line. This might have been one of the reasons why discussions started concerning a borked import system.  Perhaps I'm wrong?
> 
> 
> How imports work is that first a name is searched for in the current namespace. If it is not found, then it is looked for in the import list. If it is found uniquely among the imports, then that is used. If it is in more than one import, an error occurs:

That is not how aliases currently work, just a friendly reminder.
-DavidM

Sean Kelly wrote:
> 
> ...
> 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.
> 
> Sean

Very well said. I think I see both points to the issue but sometimes an argument comes up that doesn't really address what the problem is and takes the topic off to discussing the same feature but a different issue (sometimes even the same issue with just a different syntax or style).

Kris and Walter both had some good points, and a summation from Walter of what he thinks should be done... BEFORE it's done would be nice.

Lucas

Walter Bright wrote:
> 
>> OT: if you'll be changing the import system, _PLEASE_ make private imports the default.
> 
> It's too late for that, sorry. Also, everything else in D is public by default, and consistency is sometimes better than special case rules, even if those special case rules make some things easier.

Nonsense, of course it's not too late! In fact, for this change in particular, it's quite easy to write a trivial script that can easily convert from one syntax to the other, without errors. So if you want to argue about this proposal, do so regarding it's merits only, not compatibility.

So about the consistency issue: I too think consistency and orthogonality are very important (maybe even more than you :P ), but the key thing to notice here is that a (private) import is not defining new members of a module. It's not creating a new entity or entities. I view an import as very different from defining a class, struct, variable, function, etc., and therefore I don't find it inconsistent for the default protection to be different.

In fact, I even have some doubts about the whole thing of imports having protection attributes in the first place. It wouldn't strike me as odd if import was protectionless, working only the same as the current "private import", and that the functionality of the current "public import" were achieved in some other way like "alias somemodule.*;" or "aliasimport somemodule;" or something like that.

=> One clue that an import is different from any other declarations with protection attributes, is that its names go to a secondary namespace. That's inconsistency right there. (if you view the imports the same as the other things)


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Dave wrote:
> Bruno Medeiros wrote:
>>
>> [*] It is thanks to you kris, that of lack of FQN imports is now decided to be fixed. Despite I having mentioned this issue over a year ago, and also recently before this thread, you presented a hard and immediate example problem, which didn't occur to me or anyone else who participated in the previous discussions (the ones known of at least), and which convinced Walter to fix it.
>>
> 
> Examples, hard evidence, *pragmatism* are the key to getting things changed. And it's the best standard IMO.
> 

I had a hard example too... but it required the existence of a code-completing IDE to be hard evidence >:P


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Walter Bright wrote:
>>
>>> OT: if you'll be changing the import system, _PLEASE_ make private imports the default.
>>
>> It's too late for that, sorry. Also, everything else in D is public by default, and consistency is sometimes better than special case rules, even if those special case rules make some things easier.
> 
> Nonsense, of course it's not too late! In fact, for this change in particular, it's quite easy to write a trivial script that can easily convert from one syntax to the other, without errors. So if you want to argue about this proposal, do so regarding it's merits only, not compatibility.
> 
> So about the consistency issue: I too think consistency and orthogonality are very important (maybe even more than you :P ), but the key thing to notice here is that a (private) import is not defining new members of a module. It's not creating a new entity or entities. I view an import as very different from defining a class, struct, variable, function, etc., and therefore I don't find it inconsistent for the default protection to be different.
> 
> In fact, I even have some doubts about the whole thing of imports having protection attributes in the first place. It wouldn't strike me as odd if import was protectionless, working only the same as the current "private import", and that the functionality of the current "public import" were achieved in some other way like "alias somemodule.*;" or "aliasimport somemodule;" or something like that.
> 
> => One clue that an import is different from any other declarations with protection attributes, is that its names go to a secondary namespace. That's inconsistency right there. (if you view the imports the same as the other things)
> 

Well said - you beat me to it <g> Especially the last point, which is a great argument against strict consistency and orthogonality for imports because as declarations some of their properties stand alone.

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.