On Mon, 6 Sep 2004 22:57:44 -0700, antiAlias <fu@bar.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
>> a) isn't it often a sign of inconsistent and potentially buggy design
>> where an implicit cast is actually generated? In other cases, it's sheer
>> laziness on the part of the programmer. That's not a criminal offence,
>> but support
>> for that shouldn't cripple significant aspects of the language either.
>
> I wouldn't call it 'sheer laziness' I would call it 'convenience' and as I
> said earlier, each programmer desires a different balance between
> convenience and robustness.
>
> ========
> You'd happily trade-off robustness for a few keystrokes?

Yes. IMO:

-- 'few' is incorrect, try millions.
-- the robustness I actually loose is miniscule.

obviously you will disagree with both of the above. That was my other point: each person wants to draw the line in a different place. You favour robustness over convenience, I prefer a little more convenience and (given the narrowing implicit conversions in D) Walter wants even more convience (or they're a bug).

> If you're serious,then Matthew's choice-phrase for that sort of attitude towards design &
> coding fits the bill quite nicely. I think you should start another topic on that one :-)
> That aside, you avoided the point.

Which one?

a. an implicit cast is a sign of bad design?
b. an implicit cast is a sign of a lazy programmer?
c. implicit conversions cripple the language?

Those are all I see above, so, my responses..

a & b) If you have implicit casts (which we do) then we will use them, it's only the un-intentional use of them which could be hazardous, and generally it's only a problem if it's a narrowing conversion, which IMO should never be implicit.

c) is C/C++ crippled? It doesn't seem to be.

>> e) method-name alias would not be required, simplifying compiler
>> implementation and removing a considerable learning impediment from the D language.
>
> So, on one hand you don't want implicit type conversion, as it introduces
> bugs... but on the other you do want implicit inclusion of symbols in the
> child class scope... and this also introduces bugs... but you're happy
> with one set of bugs and not the other?
>
> ===============
> I'm truly surprised, Regan. You seemed to understand the issue, and then say this?

Are you gonna tell me what you dislike about it, or leave me guessing?

Basically what I am trying to point out is:

-- what you want is for symbols to be included 'implicitly'.
-- what you dont want is for types to be converted 'implicitly'.

IMO anything done implicitly creates a chance that it was not what the programmer intended and thus can cause bugs, we have had examples of them for both of the above.

What I don't understand is how you can desire robustness *and* implicit symbol inclusion (which has been shown to decrease robustness)

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

This little excursion started out as a mere heads' up regarding some issues with respect to implicit conversion. That post ended with the request to "Please consider", before further implicit conversion might be added to the compiler.

I won't pretend to understand the reasons why this topic has been dragged through the gutter. Perhaps there's a need to divert attention, from the original point? Perhaps there's some other unseen notion at play. Whatever the goal, posting here is becoming an increasingly futile exercise. That's a shame.

I'll make this one response to your ever-escalating drivel, Regan, and then bid you adieu:

******************************

| IMO anything done implicitly creates a chance that it was not what the
| programmer intended and thus can cause bugs, we have had examples of them

Now you've completely flip-flopped, and are making my point for me. Doh! That's okay though.


| > So, on one hand you don't want implicit type conversion, as it
introduces
| > bugs... but on the other you do want implicit inclusion of symbols in
the
| > child class scope... and this also introduces bugs... but you're happy
| > with one set of bugs and not the other?
| >
| -- what you want is for symbols to be included 'implicitly'.
| -- what you dont want is for types to be converted 'implicitly'.
|
| What I don't understand is how you can desire robustness *and* implicit
| symbol inclusion (which has been shown to decrease robustness)


Au Contraire;

First; you're hanging onto half-baked notions of what you term implicit and explicit. Second; you continue to cast what, you appear to hope, are vaguely contradictory notions my way, with no substance whatsoever to back them up.

Let's take a look at those shall we?

You claim that inheritance of methods is implicit. Or, rather you claim that I do, and use that as a basis for derogatory remark. I've got news for you Regan: inheritance is /explicit/. You appear to conveniently forget that little detail. When you inherit, you must do so explicitly, like so:

class X : Y {}

What this does, Regan, is to extend class X with all the functionality that class Y exposes (or vice versa, if you prefer). You, as a programmer, have taken an explicit action to make this happen, and are telling the compiler that you are assuming responsibility for the consequence of your action.

You've pointed out in the past that you've not used C++ before, nor Java, so one might understand your confusion over this basic point. However, you should perhaps consider this lack of experience before rifling others over such matters. After all, it was only recently that you learned the distinction between override and overload: news:opsbtjg6ko5a2sq9@digitalmars.com Your claimed 6 year of writing C does not do you any favours in such matters. While we're on that subject; you talk about a "child class" instead of superclass (they are quite different things), and you talk about "symbols" instead of inherited methods. Please try to be a little more accurate with terminology, as it will assist you.

If we assume that you already know inheritance is an explicit action, then
your rhetoric becomes clear for what it is; all inherited methods
(non-private) are indeed included into the scope of a derived class
/by default/. That is the way method inheritance operates, Regan. D (and
C++) have a number of special cases in this respect; one of which is with
regard to methods of the same name. It's been shown on a number of prior
occasions where such special cases can lead. Here's one that would have been
rather amusing, were it not for the consequence:
news:cgat6b$1424$1@digitaldaemon.com


As for your deluded assertion that I have some contrary notion in mind; consider this: news:ce44ka$1ji4$1@digitaldaemon.com

Perhaps that will put paid to your snide and bizarre aberrations? I think perhaps you should read more, Regan. Without getting your facts straight, you tend to look a bit foolish.


| > You'd happily trade-off robustness for a few keystrokes?
|
| Yes. IMO:

Then you do not deserve that job of yours in tech-support, or product development, or whatever it is you claim to do. Trading off software-robustness is perhaps questionable at any level, but trading it off for laziness is shallow in the extreme. You're advocating more of that should be built into the compiler. Thankfully, you then go on to contradict yourself again with this:

| IMO anything done implicitly creates a chance that it was not what the
| programmer intended and thus can cause bugs, we have had examples of them


Hallelujah!


Lastly: You have a big mouth, Regan. Perhaps you should put your money where that mouth is, and post an extensive essay upon the detrimental aspects of what you term "the Java way" regarding this topic, and compare/contrast with all the documented "quirks" of the D approach?  Please try to form some semblance of punctuation while you're at it. And don't forget to try and get the terminology straight.

Others have been willing to do so in the past, and face the consequences. I should imagine that you'd prefer to stay behind your little desk instead; brazenly decrying alternate approaches to the discussed issues without understanding them in the first place. Put up the money, Regan. If you do so, then you might even get some of the respect you seem to need so desperately.

Have a nice life, dude. And thanks for the entertainment!

On Wed, 8 Sep 2004 10:24:50 -0700, antiAlias <fu@bar.com> wrote:
> This little excursion started out as a mere heads' up regarding some issues
> with respect to implicit conversion. That post ended with the request to
> "Please consider", before further implicit conversion might be added to the
> compiler.
>
> I won't pretend to understand the reasons why this topic has been dragged
> through the gutter. Perhaps there's a need to divert attention, from the
> original point? Perhaps there's some other unseen notion at play. Whatever
> the goal, posting here is becoming an increasingly futile exercise. That's a
> shame.
>
> I'll make this one response to your ever-escalating drivel, Regan, and then
> bid you adieu:

Kris, we're all adults here (at least I thought we were), your habit of abusing someone because they disagree with you is childish at best. If you cannot handle having your opinions disagreed with I suggest you stop posting them.

I was tempted to leave this reply at that, but for the sake of continued understanding I will attempt to clear up our recent missunderstandings...



> ******************************
>
> | IMO anything done implicitly creates a chance that it was not what the
> | programmer intended and thus can cause bugs, we have had examples of them
>
> Now you've completely flip-flopped,

No, I have not.


> and are making my point for me. Doh!
> That's okay though.

Im not sure to which point you are referring?

I am perfectly willing to accept implicit behaviour can cause unexpected results. I am perfectly willing to accept that requiring explicit behaviour creates more robust code.

The points I am trying to make (which you seem to miss) are:

- that each person desires a different balance between the two.
- that the behaviour you have been asking for is implicit behaviour.


> | > So, on one hand you don't want implicit type conversion, as it
> introduces
> | > bugs... but on the other you do want implicit inclusion of symbols in
> the
> | > child class scope... and this also introduces bugs... but you're happy
> | > with one set of bugs and not the other?
> | >
> | -- what you want is for symbols to be included 'implicitly'.
> | -- what you dont want is for types to be converted 'implicitly'.
> |
> | What I don't understand is how you can desire robustness *and* implicit
> | symbol inclusion (which has been shown to decrease robustness)
>
>
> Au Contraire;
>
> First; you're hanging onto half-baked notions of what you term implicit and
> explicit. Second; you continue to cast what, you appear to hope, are vaguely
> contradictory notions my way, with no substance whatsoever to back them up.
>
> Let's take a look at those shall we?
>
> You claim that inheritance of methods is implicit.

No, I did not.

> Or, rather you claim that
> I do

No, I did not.

> , and use that as a basis for derogatory remark.

No, I did not.

You seem to continually misunderstand, misconstrue and misrepresent my comments.

I am perfectly aware what implicit and explicit mean, you seem to have missunderstood what I was referring to. Perhaps I was not clear enough, perhaps I should have explicitly used the word overloaded when referring to inheritance, I hope it's clearer now.


> I've got news for you
> Regan: inheritance is /explicit/. You appear to conveniently forget that
> little detail. When you inherit, you must do so explicitly, like so:
>
> class X : Y {}
>
> What this does, Regan, is to extend class X with all the functionality that
> class Y exposes (or vice versa, if you prefer). You, as a programmer, have
> taken an explicit action to make this happen, and are telling the compiler
> that you are assuming responsibility for the consequence of your action.

Yes, I realise inheritance is explicit, however inheritance itself is not the problem you're having. The problem you're having is with "overloaded" inherited methods and name resolution.

What you want is for overloaded inherited methods to be implicitly included in the child class scope for name resolution. (Correct me if I am wrong).

This behaviour is *not* currently the case, and you must explicitly 'alias' them in.


> You've pointed out in the past that you've not used C++ before, nor Java, so
> one might understand your confusion over this basic point. However, you
> should perhaps consider this lack of experience before rifling others over
> such matters.

Yet again you seem to simply be taking exception to me disagreeing with you. I have no idea what "rifling others" is, but I am pretty sure I have done no such thing.

Unless I am mistaken this is a 'News Group' where people come to share their knowledge and opinions on various things, where people discuss those opinions and form new ones. If you cannot handle me or anyone else doing that, then I suggest you leave.

All I have ever been trying to do is share my opinion.


> After all, it was only recently that you learned the
> distinction between override and overload:

To be perfectly honest, I understood the concept just not the correct term to use.


> news:opsbtjg6ko5a2sq9@digitalmars.com Your claimed 6 year of writing C does
> not do you any favours in such matters. While we're on that subject; you
> talk about a "child class" instead of superclass (they are quite different
> things), and you talk about "symbols" instead of inherited methods. Please
> try to be a little more accurate with terminology, as it will assist you.

Thank you, it was simply the terminology that I lack, I am catching up however.


> If we assume that you already know inheritance is an explicit action, then
> your rhetoric becomes clear for what it is; all inherited methods
> (non-private) are indeed included into the scope of a derived class
> /by default/. That is the way method inheritance operates, Regan. D (and
> C++) have a number of special cases in this respect; one of which is with
> regard to methods of the same name. It's been shown on a number of prior
> occasions where such special cases can lead. Here's one that would have been
> rather amusing, were it not for the consequence:
> news:cgat6b$1424$1@digitaldaemon.com

You're right, inherited methods are included, however, they're not the problem here. The problem is with "overloaded" inherited methods, which are not included and must be explicitly aliased in.

<snip>

I have snip'ped the last part of this post because you seem to have degenerated into name calling, something I won't join you in doing.


To all the other people taking part in this NG:

If I am offending anyone in any way, shape or form with any comments/arguments/opinions I have voiced please let me know, either post here, or email me directly (the above address is valid)

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"antiAlias" <fu@bar.com> wrote in message news:chj8i6$1vt6$1@digitaldaemon.com...
> "Regan Heath" <regan@netwin.co.nz>
> Of course. I agree. However, I have yet to be presented with an approach
> which I would consider better. I have seen the Java way which suffers from
> a potential hidden bug, which IMO makes it a worse solution than what we
> currently have.
>
> ===================
> On whether that is a bug or something else entirely, I will quote yourself:
> "IMO this example could be a red herring, engineered to show the bug, not
> at all likely in reality"
>
> I fully agree with your statement Regan. The fact that such a (at best)
> "questionable" example should mandate this direction is beyond the pale :-)
>
> And what of other, similar, bugs that D doesn't bother to handle? The required use of 'override' would catch a bunch of rather nasty, and rather common, ones (unlike that "square" example of a particular engineering travesty). Yet, 'override' is not required. That kind of argument against what you call "the Java way" is somewhat futile on several fronts.
>
>
>> I doubt very much that I'm alone in that respect.
>
> No, you're not, quite a few people have expressed dissatisfaction with the current system, myself included, however until a 'better' system is proposed it will likely remain.
>
> =====================
> Fair enough. Two notions immediately spring to mind:
>
> 1) How does Java successfully combine method-name resolution with implicit primitive conversion? And what is wrong with adopting that model instead, if it resolves these problems far more successfully than the existing D approach does?
>
> 2) forget about implicit conversion altogether. Even MSVC v6.0 requires me to explicitly downcast an int to a char (unless I'm prepared to live with warnings, which I'm not).
>
> Consider this:
>
> a) isn't it often a sign of inconsistent and potentially buggy design where an implicit cast is actually generated? In other cases, it's sheer laziness on the part of the programmer. That's not a criminal offence, but support for that shouldn't cripple significant aspects of the language either.
>
> b) D will quietly convert a long argument to an int or char parameter without so much as a peep! This is much looser than MSVC, for crying out loud ... and should be considered a potential bug, if not an outright one (and D is supposed to be more typesafe than C?)

In a language without warnings, that is a bug. Pure and simple.

> c) the implicit conversions of primitive-types makes a total mess of overload, especially with respect to inheritance. Just look at some of the bizarre examples given in the past for justifying the current name-resolution and method-alias scheme <g>
>
> d) implicit conversion also makes a mess of certain operator-overloads, such that the compiler quits with an error message. The same is true of certain constructor patterns.

Example(s) please.

> e) method-name alias would not be required, simplifying compiler implementation and removing a considerable learning impediment from the D language.

Example(s) please.

> To all the other people taking part in this NG:
>
> If I am offending anyone in any way, shape or form with any comments/arguments/opinions I have voiced please let me know, either post here, or email me directly (the above address is valid)

I won't single anyone out - though I'll take my share of the blame - but this NG has degenerated enormously in the last few months to the point of unreadability. (I've now all but stopped reading it, but was prompted to digest this thread at the behest of a friend, who wanted my opinion.)

I think this has happened due to two factors:

1. The increasing visibility of D has brought a lot of new people in, many of whom appear to prefer to yack than hack.
(As is their right, of course.)
2. The increasing frustrations of the extant D community
    (i) to the degrading yack:hack ratio, and, probably more significantly,
    (ii) with the evolution of the language and its libraries. As the language ages, more things are found to be
fundamentally wrong with it, and yet fewer things *appear* (I may be wrong, so I'll stick with appear) to be addressed.
There are a disconcerting number of warts in D already, and yet many people were drawn to it because of its promise to
be evolutionary and learning from the mistakes of other languages. Again (caveats to the fore), I may be wrong here, but
it sure feels like this is the case. I don't doubt that, if anyone was motivated, we could easily amass a list of 20-30
serious show-stopping (or, rather, sideline-precipitating) warts in the language itself. But it seems like there's very
little interest in these "higher" issues, especially where Walter disagrees with them - <too many to list> - or deems
them unimportant - e.g. the opApply() delegate return type.

Of all my competent non-D friends - i.e. people who have many years experience in several systems and scripting languages - none whom I managed to persuade to look at it seriously over the last couple of years have been motivated to stick with it, and I've been unable to motivate a single one to even look at it in, say, the last 6 months. This is not promising.

For my part, I am still keen to see D succeed, and I still believe it _can_, but I am less sure that it _will_ than I used to be. It has some very powerful advantages over other languages, but I fear they're likely to be deemed insignificant when basic issues of usability, large-scale development and robustness remain unaddressed.

:-(

Matthew

In article <chop6a$1n94$1@digitaldaemon.com>, Matthew says...
>[...] this NG has degenerated enormously in the last few months to the point of unreadability. [...]
>
>I think this has happened due to two factors:
>
>1. The increasing visibility of D has brought a lot of new people in, many of whom appear to prefer to yack than hack.

I, for one, agree.  It's a symptom of the movement that D has created.  From the beginning I was apprehensive how this group would behave as participation grew. I think the NG is beginning to mature and is soon going to be in need of a basic NG-FAQ to help keep the noobs with the basics.  Thankfully, the group has been fairly well self-moderated which is evident by how quickly some problems are dealt with.

As a side note, I don't see the amount of chatter on the group a problem so long as its positive.  After all, how the heck are we supposed to get along or agree on anything without knowing at least a little bit about each others goals and interests?  Also, the amount of messageboard volume over on dsource has shown that a good amount of D-based discussion, that could have been dumped here, is instead being focused on a project-by-project basis; and more is moving there all the time, like with Ares (PhobosRising).  Could the amount of yacking here be the result of this trend?

>(As is their right, of course.)
>2. The increasing frustrations of the extant D community
>    (i) to the degrading yack:hack ratio, and, probably more significantly,
>    (ii) with the evolution of the language and its libraries. As the language ages, more things are found to be
>fundamentally wrong with it, and yet fewer things *appear* (I may be wrong, so I'll stick with appear) to be addressed. There are a disconcerting number of warts in D already, and yet many people were drawn to it because of its promise to be evolutionary and learning from the mistakes of other languages. Again (caveats to the fore), I may be wrong here, but it sure feels like this is the case. I don't doubt that, if anyone was motivated, we could easily amass a list of 20-30 serious show-stopping (or, rather, sideline-precipitating) warts in the language itself. But it seems like there's very little interest in these "higher" issues, especially where Walter disagrees with them - <too many to list> - or deems them unimportant - e.g. the opApply() delegate return type.

Again, I agree.  It may look like development is being stalled, but I think that may be due to forces well beyond Walter's control.  Then again, who else other than he is able to speak for these points directly?

When Ares lifts off, I can see the language library issues being addressed at least in parallel with the core distribution.  I feel bad advocating that we (as a community of developers) circumvent the core development of the language, but I really don't see any other way to accomplish rapid progress.

As for the compiler and language issues, perhaps some of us (I'm not implying Matthew BTW, but honestly anyone who's read this far) may take to deeper hacking of the dmd frontend to determine how and why certain things break?  If it helps, I know that the closer one gets to solving the problem directly, when filing a bug report, the more attention it recieves.

>Of all my competent non-D friends - i.e. people who have many years experience in several systems and scripting languages - none whom I managed to persuade to look at it seriously over the last couple of years have been motivated to stick with it, and I've been unable to motivate a single one to even look at it in, say, the last 6 months. This is not promising.

Yep, some of the shouting and trolling here in the group certainly doesn't help the overall image of Walter's (or anyone else's) efforts, especially since this is one of the only places where one can go to keep current on D.  One only has to look at the blog site for Mono to see how even a modest improvement in maturity can impact the presence of a technology (even if its nothing new).  But then again, mono's blog is developers *only* so there's something to be said for selecting your representatives to the world at large.

I'm not at all suprised that its been difficult to get others interested.  I've run into the same problem, but only because I have nothing to say that will really "hook" someone.  The most compact thing I can say about D that does it any justice is: "A compiled, portable, object-oriented, garbage-collected C dialect that out performs similar technologies."  Anyone who understands that mouthful of jargon gets it, but is then soundly dissapointed by its beta status.


Here's the way I see it: D has innumerable /slight/ advantages over similar languages.  There is no single "killer feature" that will really entice a hoard of people in.  So we must get the word out that "D is an all round better language" than others.  This will take nothing short of the community here putting its best foot forward to entice new and old developers alike.  It means better promotion and more complete projects.  Something high profile would be a boon too.

Also, once we clear V1.0, I expect many to take D more seriously.  In the meantime, D is stable enough now to accomplish a world of good.

- Pragma
[[ Eric Anderton at (d is good) yahoo dot com]]

"pragma" <pragma_member@pathlink.com> wrote in message news:chq1ak$2e62$1@digitaldaemon.com...
> In article <chop6a$1n94$1@digitaldaemon.com>, Matthew says...
>>[...] this NG has degenerated enormously in the last
>>few months to the point of unreadability. [...]
>>
>>I think this has happened due to two factors:
>>
>>1. The increasing visibility of D has brought a lot of new people in, many of whom appear to prefer to yack than hack.
>
> I, for one, agree.  It's a symptom of the movement that D has created.  From the beginning I was apprehensive how this group would behave as participation grew. I think the NG is beginning to mature and is soon going to be in need of a basic NG-FAQ to help keep the noobs with the basics.  Thankfully, the group has been fairly well self-moderated which is evident by how quickly some problems are dealt with.
>
> As a side note, I don't see the amount of chatter on the group a problem so long as its positive.  After all, how the heck are we supposed to get along or agree on anything without knowing at least a little bit about each others goals and interests?

12-18 months ago, there was a happy community and people did indeed exchange personal/OT debates, and no-one minded. Indeed, it helped cement relationships and provided some nice entertainment. People at that time were earnest, but there was little of the dogma and ego that haunts it now. It may well be that this in an inevitable part of any movement as it expands, but I don't think that's entirely covers it.

>  Also, the amount of messageboard volume over on dsource has shown
> that a good amount of D-based discussion, that could have been dumped here, is
> instead being focused on a project-by-project basis; and more is moving there
> all the time, like with Ares (PhobosRising).  Could the amount of yacking here
> be the result of this trend?
>
>>(As is their right, of course.)
>>2. The increasing frustrations of the extant D community
>>    (i) to the degrading yack:hack ratio, and, probably more significantly,
>>    (ii) with the evolution of the language and its libraries. As the language ages, more things are found to be
>>fundamentally wrong with it, and yet fewer things *appear* (I may be wrong, so I'll stick with appear) to be
>>addressed.
>>There are a disconcerting number of warts in D already, and yet many people were drawn to it because of its promise to
>>be evolutionary and learning from the mistakes of other languages. Again (caveats to the fore), I may be wrong here,
>>but
>>it sure feels like this is the case. I don't doubt that, if anyone was motivated, we could easily amass a list of
>>20-30
>>serious show-stopping (or, rather, sideline-precipitating) warts in the language itself. But it seems like there's
>>very
>>little interest in these "higher" issues, especially where Walter disagrees with them - <too many to list> - or deems
>>them unimportant - e.g. the opApply() delegate return type.
>
> Again, I agree.  It may look like development is being stalled, but I think that may be due to forces well beyond Walter's control.  Then again, who else other than he is able to speak for these points directly?

Exactly the point!

> When Ares lifts off, I can see the language library issues being addressed at least in parallel with the core distribution.  I feel bad advocating that we (as a community of developers) circumvent the core development of the language, but I really don't see any other way to accomplish rapid progress.

I've gone off the idea. I'm now tending towards thinking that we need Walter/Phobos action on issues, one at a time. I'd like to see a Library Issue Of The Week, *including* Walter's attention/involvement. For example, I'd suggest that we clean up the Exception/Error Hierarchy this week. Why not?

[Since I wrote the first part of this response, Walter's agreed to this very notion, so now I have to eat my own words, and dance to the manic ditty I've been singing. :-)]

> As for the compiler and language issues, perhaps some of us (I'm not implying Matthew BTW, but honestly anyone who's read this far) may take to deeper hacking of the dmd frontend to determine how and why certain things break?  If it helps, I know that the closer one gets to solving the problem directly, when filing a bug report, the more attention it recieves.

Would love to, but have not the time, and cannot imagine ever getting it, alas.

>>Of all my competent non-D friends - i.e. people who have many years experience in several systems and scripting
>>languages - none whom I managed to persuade to look at it seriously over the last couple of years have been motivated
>>to
>>stick with it, and I've been unable to motivate a single one to even look at it in, say, the last 6 months. This is
>>not
>>promising.
>
> Yep, some of the shouting and trolling here in the group certainly doesn't help the overall image of Walter's (or anyone else's) efforts, especially since this is one of the only places where one can go to keep current on D.  One only has to look at the blog site for Mono to see how even a modest improvement in maturity can impact the presence of a technology (even if its nothing new).  But then again, mono's blog is developers *only* so there's something to be said for selecting your representatives to the world at large.

I shall have a look.

> I'm not at all suprised that its been difficult to get others interested.  I've run into the same problem, but only because I have nothing to say that will really "hook" someone.  The most compact thing I can say about D that does it any justice is: "A compiled, portable, object-oriented, garbage-collected C dialect that out performs similar technologies."  Anyone who understands that mouthful of jargon gets it, but is then soundly dissapointed by its beta status.

There are some *really* challenging issues ahead, most notably getting DLLs and GC to work in large-scale/project scenarios. Until such issues are resolved, D's only going to be good for implementing stand-alone link-units, or those that cooperate via C-APIs. (Not that I am troubled by such things, since that's the only way I use C++, but it's too much boilerplate and nitty-gritty for a new language to require of its users.)

> Here's the way I see it: D has innumerable /slight/ advantages over similar languages.  There is no single "killer feature" that will really entice a hoard of people in.

Not sure I agree. I think D's combination of some borrowed features makes it unique. (I'm not saying any more, as I'm trying to get an article up for DDJ on this very point ... <g>)

>  So we must get the word out that "D is an all round better
> language" than others.

Is it? I didn't think such a thing existed. For example, I recently changed the license information in *all* of the STLSoft and recls libraries, and a whole lot of other minor textual inconsistencies. Naturally, I used the recls-Ruby mapping. I wouldn't think of doing it in D!

>  This will take nothing short of the community here
> putting its best foot forward to entice new and old developers alike.  It means
> better promotion and more complete projects.  Something high profile would be a
> boon too.

I agree with the projects notion. As soon as I can get my head above water, I have a rather nifty (C++) code-generator to write, and I'm thinking of doing it in D. All those slices are harder to resist than Willy Wonka's chocolate, or Mrs Miggins' pies!

> Also, once we clear V1.0, I expect many to take D more seriously.  In the:. meantime, D is stable enough now to accomplish a world of good.

Disagree. It's stable enough to accomplish many small islands of good. There is a *lot* of work to be done before we're onto worlds.

Still, I'm feeling more optimistic about D now than the last month or two, so let's look forward.

Cheers

Matthew

In article <chrfr1$12uc$1@digitaldaemon.com>, Matthew says...
>
>12-18 months ago, there was a happy community and people did indeed exchange personal/OT debates, and no-one minded. Indeed, it helped cement relationships and provided some nice entertainment. People at that time were earnest, but there was little of the dogma and ego that haunts it now. It may well be that this in an inevitable part of any movement as it expands, but I don't think that's entirely covers it.

This is why I suggested a listserv for dev talk, though I'd still like to believe it's not necessary.  The drama that's gone on here these past few months is completely unproductive.

>I've gone off the idea. I'm now tending towards thinking that we need Walter/Phobos action on issues, one at a time. I'd like to see a Library Issue Of The Week, *including* Walter's attention/involvement. For example, I'd suggest that we clean up the Exception/Error Hierarchy this week. Why not?

If we can get Walter's participation on core library issues then I'm all for it. It doesn't have to be anything fancy, but I would like to see some of the core features (such as exceptions) sorted out in the coming months.

>There are some *really* challenging issues ahead, most notably getting DLLs and GC to work in large-scale/project scenarios. Until such issues are resolved, D's only going to be good for implementing stand-alone link-units, or those that cooperate via C-APIs. (Not that I am troubled by such things, since that's the only way I use C++, but it's too much boilerplate and nitty-gritty for a new language to require of its users.)

Yup.  Personally, I think any major project in D right now is kind of putting the cart before the horse.  They do aid in finding problems in language implementation, but it's hard to build a castle on sand.  It would be nice to see more discussion of these and similar issues.  I'm confident that they will all be addressed, but I'd prefer that be sooner than later :)


Sean

In article <chaapt$1rac$1@digitaldaemon.com>, antiAlias says...
>
>There was some commentary about the benefits of auto-conversion between char[], wchar[] and dchar[], where the compiler will automatically convert array literals as it sees fit. So, for example, if you have a method:
>
># void myFunc (wchar[] string) {...}
>
>and call it with:
>
># myFunc ("a char array");
>
>the compiler will convert the literal to a wchar[] instead of a char[]. This is apparently considered a GoodThing. Recently, there's been a lot of talk regarding additional automatic conversion, between UTF8 and its wchar[] and dchar[] representations.
>
>Unfortunately, all this implicit conversion conflicts badly with method resolution. For instance, if I have two methods:
>
># myFunc (char[] string) { ... }
># myFunc (wchar[] string) { ... }
>
>the compiler now can't tell which one should be called (vis-a-vis the prior example). To get around this, one has to cast the string literal like so:
>
># myFunc (cast(wchar[]) "a char array");
># myFunc (cast(char[]) "a char array");
>
>Ugly. What some folks do to get around this is to add different method names for the same functionality, a la Win32:
>
># writeString (char[] x);
># writeStringW (wchar[] x);
>
>They are forced into this approach to avoid having to use those ugly casts everywhere. This is what Streams.d does, along with others. Okay, so some might ask why this is a problem? Well, there are certain method names that are fixed in stone by the compiler, and you can't add a suffix even if you wanted to:
>
># class MyClass
># {
>#     this (char[] initialContent) { ... }
>#     this (wchar[] initialContent) { ... }
># }
>
>See the problem? The compiler cannot resolve which constructor to use when you write
>
># new MyClass ("blah blah blah");
>
>Instead, one is forced to use a cast:
>
># new MyClass (cast(char[]) "blah blah blah");
>
>One can hardly add a "W" suffix to the keyword "this". The same thing happens for operator overloads too. One way around this is to introduce string prefixes, such as w"this is a wchar string". This has been suggested before, and it would certainly get rid of those ugly casts (I was under the misguided impression that casts should not be used on a general basis). BTW: the w"string" prefix is not a cast; it's a storage-attribute. I'd like to suggest such prefixes be supported and adopted.
>
>Anyway; the reason for the post is to make folk aware of the kinds of problems introduced when a compiler performs implicit conversions. This is bound to become more troublesome if additional "convenience" conversions occur implicitly within the D language, such as the oft discussed UTF8 conversions.
>
>Please consider.
>
>
>
>

antiAlias: To reiterate, I think your initial points that started this thread are on the money...also I'm not quite sure I understand how the thread took a hard right and then a nose dive soon after you posted it. But do hope Walter will fix this soon, with maybe adding the prefixes w"" and d"" for string literals, which should solve both the parameter passing and string concatenation (~) problems when using string literals. Well here's hoping anyway!

Also, I think we all need a *Big Group Hug*. Let's all get back to supporting "D" and each other in very positive ways!!  :))

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

"Sean Kelly" <sean@f4.ca> wrote in message news:chsj13$1kqq$1@digitaldaemon.com...
> In article <chrfr1$12uc$1@digitaldaemon.com>, Matthew says...
>>
>>12-18 months ago, there was a happy community and people did indeed exchange personal/OT debates, and no-one minded.
>>Indeed, it helped cement relationships and provided some nice entertainment. People at that time were earnest, but
>>there
>>was little of the dogma and ego that haunts it now. It may well be that this in an inevitable part of any movement as
>>it
>>expands, but I don't think that's entirely covers it.
>
> This is why I suggested a listserv for dev talk, though I'd still like to believe it's not necessary.  The drama that's gone on here these past few months is completely unproductive.
>
>>I've gone off the idea. I'm now tending towards thinking that we need Walter/Phobos action on issues, one at a time.
>>I'd
>>like to see a Library Issue Of The Week, *including* Walter's attention/involvement. For example, I'd suggest that we
>>clean up the Exception/Error Hierarchy this week. Why not?
>
> If we can get Walter's participation on core library issues then I'm all for it.

Indeed.

> It doesn't have to be anything fancy, but I would like to see some of the core
>features (such as exceptions) sorted out in the coming months.

Then *please* apply your considerable expertise to the "Exception hierarchy refactoring" thread sometime in the next couple of weeks. :-)

>>There are some *really* challenging issues ahead, most notably getting DLLs and GC to work in large-scale/project scenarios. Until such issues are resolved, D's only going to be good for implementing stand-alone link-units, or those that cooperate via C-APIs. (Not that I am troubled by such things, since that's the only way I use C++, but it's too much boilerplate and nitty-gritty for a new language to require of its users.)
>
> Yup.  Personally, I think any major project in D right now is kind of putting the cart before the horse.  They do aid in finding problems in language implementation, but it's hard to build a castle on sand.  It would be nice to see more discussion of these and similar issues.  I'm confident that they will all be addressed, but I'd prefer that be sooner than later :)