www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - loaded ==, !=, ===, is, !==

reply "Kris" <fu bar.com> writes:
Food for thought:

Java is explicit about the distinction between equality and identity, just
as D is. However, where D uses '==' as an equivalence operator, Java uses an
equals() method. Where D uses (triple) '===' and 'is' for identity purposes,
Java uses the traditional double '==' instead.

So, what's that got to do with the price of tea in China?

While porting 125,000 lines of Java to D, and an interesting thing happened.
You'll perhaps not be surprised to hear Java identity style tests are far
more prevalent than equivalence tests, but you may be surprised to know that
the former comprised 98.75% of all explicit tests within those 125,000
lines. To embellish, equals() was applied just 1.25% of the time.

Please note that we're talking about high-quality Java code that makes
extensive use of OO practices, and does indeed use equals() appropriately
when doing class comparisons. It's just that there's relatively little call
for that kind of thing once you get beyond writing sorting-algorithms,
containers, and so on. What I'd classify as "user-level code" appears to
apply equivalence testing rather seldom.

The Java code was converted mechanically, so it was thankfully easy to
change all identity tests into the D equivalent, which is the word 'is', or
the triplet '==='. Likewise, the inversion was converted from '!=' to the D
triplet '!=='. Each equals() instance was translated into the more
traditional twin '==' equivalence operator.

This has some notable ramifications; of which I'll attempt to be brief:

1) The converted Java code now has reams of  'is' statements throughout the
code, which makes it look 'interesting', to say the least. Quite nice,
actually; and eminantly readable, even vaguely amusing at times. The '!=='
instances look suitably alien by comparison. This amplifies the need for a
sibling for the word 'is', such as the oft proposes 'not' or the colloquial
'aint'.

BTW, using 'is' generates optimal code for that 98.75% of tests within that
large body of code. That is absolutely not the case when applying the
traditional operators instead. Look at the emitted codegen.

2) Anyone used to C or Java will habitually use the traditional '==' and
'!=' all over their D code. This is actually the *wrong* thing to do, since
those operators in D are for equivalence testing instead of identity
testing. This has implications for both performance and for "expectations of
behaviour". For example, the subsequent addition of an opEquals() to some
aggregate may break the overall system in all manner of subtle and
unexpected ways, where the original developer used '==' by force of habit.

3) Just as importantly, this highlights a significant divergence of D from C
and, IMO, in a rather fundamental manner. Think about this: you should
actually be using 'is' most of the time instead of (twin) '=='. How many of
you even use 'is' at all?

One might perhaps argue the numbers above are artificially inflated since
many of those test are applied to native types rather than to classes and
structs ~ that may be true. But we're talking about something that's already
well-developed as a habit in the community (the double '==') and we're
talking about consistency in the majority case.

I think D has perhaps made a serious blunder here. IMO, Java has the right
approach by maintaining compatability for the vast majority of usage, whilst
providing an option for testing "deep equivalence" via the equals() method
for the remaining small percentage.

D has effectively inverted that, and almost requires the adoption of a
different, and somewhat confusing, idiom to do what has been tradition for a
rather long time. The alternative is potentially error-prone code.

There's ostensibly nothing wrong with change, but it's not clear what the
benefit is here ~ if any?

At the very least, one has to mentally shift gears to perform identity tests
on classes and structs instead of native types. This would be OK if such
things were in the minority, but they're not. In the case noted above, one
has to continually shift gears for the overwhelming majority of tests.

Those of you who avoid OO like the plague will likely not be bothered by
such trivialities. For the rest, is it best to full embrace "is" and just
stick with it?

What sayeth ye?

- Kris
Apr 08 2005
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Common sense and anecdotal observations argues against the wisdom of 
lexing, never mind using, == and === / != and !==. You're correct in 
pointing out that your quantitative observation's Java-biased, but 
... [hang on while I divert power to the aft shields] ... I think 
D's going to end up being more Java-like than C++-like anyway, 
especially in the balance between value and reference semantics.

I'd be 100% behind === and !== being removed - after a deprecation 
phase - in favour of "is" and "isnot'.

(Contrarily, I'd have to say that I can't remember making any ==/=== 
or !=/!== transcription errors for some years, but then I am quite 
the language gadfly and probably not representative.)

Cheers

Charon


"Kris" <fu bar.com> wrote in message 
news:d37pdo$179t$1 digitaldaemon.com...
 Food for thought:

 Java is explicit about the distinction between equality and 
 identity, just
 as D is. However, where D uses '==' as an equivalence operator, 
 Java uses an
 equals() method. Where D uses (triple) '===' and 'is' for identity 
 purposes,
 Java uses the traditional double '==' instead.

 So, what's that got to do with the price of tea in China?

 While porting 125,000 lines of Java to D, and an interesting thing 
 happened.
 You'll perhaps not be surprised to hear Java identity style tests 
 are far
 more prevalent than equivalence tests, but you may be surprised to 
 know that
 the former comprised 98.75% of all explicit tests within those 
 125,000
 lines. To embellish, equals() was applied just 1.25% of the time.

 Please note that we're talking about high-quality Java code that 
 makes
 extensive use of OO practices, and does indeed use equals() 
 appropriately
 when doing class comparisons. It's just that there's relatively 
 little call
 for that kind of thing once you get beyond writing 
 sorting-algorithms,
 containers, and so on. What I'd classify as "user-level code" 
 appears to
 apply equivalence testing rather seldom.

 The Java code was converted mechanically, so it was thankfully 
 easy to
 change all identity tests into the D equivalent, which is the word 
 'is', or
 the triplet '==='. Likewise, the inversion was converted from '!=' 
 to the D
 triplet '!=='. Each equals() instance was translated into the more
 traditional twin '==' equivalence operator.

 This has some notable ramifications; of which I'll attempt to be 
 brief:

 1) The converted Java code now has reams of  'is' statements 
 throughout the
 code, which makes it look 'interesting', to say the least. Quite 
 nice,
 actually; and eminantly readable, even vaguely amusing at times. 
 The '!=='
 instances look suitably alien by comparison. This amplifies the 
 need for a
 sibling for the word 'is', such as the oft proposes 'not' or the 
 colloquial
 'aint'.

 BTW, using 'is' generates optimal code for that 98.75% of tests 
 within that
 large body of code. That is absolutely not the case when applying 
 the
 traditional operators instead. Look at the emitted codegen.

 2) Anyone used to C or Java will habitually use the traditional 
 '==' and
 '!=' all over their D code. This is actually the *wrong* thing to 
 do, since
 those operators in D are for equivalence testing instead of 
 identity
 testing. This has implications for both performance and for 
 "expectations of
 behaviour". For example, the subsequent addition of an opEquals() 
 to some
 aggregate may break the overall system in all manner of subtle and
 unexpected ways, where the original developer used '==' by force 
 of habit.

 3) Just as importantly, this highlights a significant divergence 
 of D from C
 and, IMO, in a rather fundamental manner. Think about this: you 
 should
 actually be using 'is' most of the time instead of (twin) '=='. 
 How many of
 you even use 'is' at all?

 One might perhaps argue the numbers above are artificially 
 inflated since
 many of those test are applied to native types rather than to 
 classes and
 structs ~ that may be true. But we're talking about something 
 that's already
 well-developed as a habit in the community (the double '==') and 
 we're
 talking about consistency in the majority case.

 I think D has perhaps made a serious blunder here. IMO, Java has 
 the right
 approach by maintaining compatability for the vast majority of 
 usage, whilst
 providing an option for testing "deep equivalence" via the 
 equals() method
 for the remaining small percentage.

 D has effectively inverted that, and almost requires the adoption 
 of a
 different, and somewhat confusing, idiom to do what has been 
 tradition for a
 rather long time. The alternative is potentially error-prone code.

 There's ostensibly nothing wrong with change, but it's not clear 
 what the
 benefit is here ~ if any?

 At the very least, one has to mentally shift gears to perform 
 identity tests
 on classes and structs instead of native types. This would be OK 
 if such
 things were in the minority, but they're not. In the case noted 
 above, one
 has to continually shift gears for the overwhelming majority of 
 tests.

 Those of you who avoid OO like the plague will likely not be 
 bothered by
 such trivialities. For the rest, is it best to full embrace "is" 
 and just
 stick with it?

 What sayeth ye?

 - Kris


 

Apr 08 2005
next sibling parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <d37ucp$1bbd$1 digitaldaemon.com>, Matthew says...
 ...

I'd be 100% behind === and !== being removed - after a deprecation 
phase - in favour of "is" and "isnot'.

 ...

I agree with Matthew on deprecating and removing the "===" and "!==" operators, I've always felt that any operator that needs three operator symbols treads to make the source code ugly and confusing to read...so it should probably be spelled out anyway with a keyword. So, I think the current "is" was a good replacement for "===", and that it makes perfect sense that "isnot" (but not "aint", because it's simply bad grammar to use) would match up rather nicely to replace "!==". David L. ------------------------------------------------------------------- "Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Apr 09 2005
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Hi, Charon, :)

Python uses forms:

'is' ['not']
and also
['not'] 'in'

I am personally quite happy with
=== and !== too.

And for IsNot there is a US patent :)

http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220040230959%22.PGNR.&OS=DN/20040230959&RS=DN/20040230959

Andrew Cerberus.





"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d37ucp$1bbd$1 digitaldaemon.com...
 Common sense and anecdotal observations argues against the wisdom of 
 lexing, never mind using, == and === / != and !==. You're correct in 
 pointing out that your quantitative observation's Java-biased, but ... 
 [hang on while I divert power to the aft shields] ... I think D's going to 
 end up being more Java-like than C++-like anyway, especially in the 
 balance between value and reference semantics.

 I'd be 100% behind === and !== being removed - after a deprecation phase - 
 in favour of "is" and "isnot'.

 (Contrarily, I'd have to say that I can't remember making any ==/=== or 
 !=/!== transcription errors for some years, but then I am quite the 
 language gadfly and probably not representative.)

 Cheers

 Charon


 "Kris" <fu bar.com> wrote in message 
 news:d37pdo$179t$1 digitaldaemon.com...
 Food for thought:

 Java is explicit about the distinction between equality and identity, 
 just
 as D is. However, where D uses '==' as an equivalence operator, Java uses 
 an
 equals() method. Where D uses (triple) '===' and 'is' for identity 
 purposes,
 Java uses the traditional double '==' instead.

 So, what's that got to do with the price of tea in China?

 While porting 125,000 lines of Java to D, and an interesting thing 
 happened.
 You'll perhaps not be surprised to hear Java identity style tests are far
 more prevalent than equivalence tests, but you may be surprised to know 
 that
 the former comprised 98.75% of all explicit tests within those 125,000
 lines. To embellish, equals() was applied just 1.25% of the time.

 Please note that we're talking about high-quality Java code that makes
 extensive use of OO practices, and does indeed use equals() appropriately
 when doing class comparisons. It's just that there's relatively little 
 call
 for that kind of thing once you get beyond writing sorting-algorithms,
 containers, and so on. What I'd classify as "user-level code" appears to
 apply equivalence testing rather seldom.

 The Java code was converted mechanically, so it was thankfully easy to
 change all identity tests into the D equivalent, which is the word 'is', 
 or
 the triplet '==='. Likewise, the inversion was converted from '!=' to the 
 D
 triplet '!=='. Each equals() instance was translated into the more
 traditional twin '==' equivalence operator.

 This has some notable ramifications; of which I'll attempt to be brief:

 1) The converted Java code now has reams of  'is' statements throughout 
 the
 code, which makes it look 'interesting', to say the least. Quite nice,
 actually; and eminantly readable, even vaguely amusing at times. The 
 '!=='
 instances look suitably alien by comparison. This amplifies the need for 
 a
 sibling for the word 'is', such as the oft proposes 'not' or the 
 colloquial
 'aint'.

 BTW, using 'is' generates optimal code for that 98.75% of tests within 
 that
 large body of code. That is absolutely not the case when applying the
 traditional operators instead. Look at the emitted codegen.

 2) Anyone used to C or Java will habitually use the traditional '==' and
 '!=' all over their D code. This is actually the *wrong* thing to do, 
 since
 those operators in D are for equivalence testing instead of identity
 testing. This has implications for both performance and for "expectations 
 of
 behaviour". For example, the subsequent addition of an opEquals() to some
 aggregate may break the overall system in all manner of subtle and
 unexpected ways, where the original developer used '==' by force of 
 habit.

 3) Just as importantly, this highlights a significant divergence of D 
 from C
 and, IMO, in a rather fundamental manner. Think about this: you should
 actually be using 'is' most of the time instead of (twin) '=='. How many 
 of
 you even use 'is' at all?

 One might perhaps argue the numbers above are artificially inflated since
 many of those test are applied to native types rather than to classes and
 structs ~ that may be true. But we're talking about something that's 
 already
 well-developed as a habit in the community (the double '==') and we're
 talking about consistency in the majority case.

 I think D has perhaps made a serious blunder here. IMO, Java has the 
 right
 approach by maintaining compatability for the vast majority of usage, 
 whilst
 providing an option for testing "deep equivalence" via the equals() 
 method
 for the remaining small percentage.

 D has effectively inverted that, and almost requires the adoption of a
 different, and somewhat confusing, idiom to do what has been tradition 
 for a
 rather long time. The alternative is potentially error-prone code.

 There's ostensibly nothing wrong with change, but it's not clear what the
 benefit is here ~ if any?

 At the very least, one has to mentally shift gears to perform identity 
 tests
 on classes and structs instead of native types. This would be OK if such
 things were in the minority, but they're not. In the case noted above, 
 one
 has to continually shift gears for the overwhelming majority of tests.

 Those of you who avoid OO like the plague will likely not be bothered by
 such trivialities. For the rest, is it best to full embrace "is" and just
 stick with it?

 What sayeth ye?

 - Kris


Apr 09 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Andrew Fedoniouk wrote:
 Hi, Charon, :)

 And for IsNot there is a US patent :)
 
 http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220040230959%22.PGNR.&OS=DN/20040230959&RS=DN/20040230959

Does not apply to D. So we can use isnot (or even IsNot) if we please.
Apr 09 2005
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Kris wrote:
 What sayeth ye?
 
 - Kris

I'm not sure that I got the use of these operators wrapped up correctly, but I like 'is', so I hope that it succeds (and possibly get a negative cousin into the language). Lars Ivar Igesund
Apr 09 2005
parent reply "Kris" <fu bar.com> writes:
That's a good point, Lars Ivar. I was also somewhat confused over the
distinction until this exercise. Perhaps I still am. I was, however,
relieved to discover "is" behaves in an equivalent manner for all types (as
it should; at least /one/ of 'em should :)

Can't help but feel something so fundamental should surely be trivial to
grasp, and be thoroughly consistent in its usage. Compared to Java, I think
D fails this sniff test quite badly WRT '==' and '!='. On the other hand,
"is" does pass that test.

Perhaps the real issue here, though, is whether 'is' should exist at all. I
personally like it, but then the continued and parallel existence of the
traditional '==' & '!=' confuses the waters badly; as you indicate.

I'll probably make an effort to provide equals() methods within library
classes and structs, to make usage clear, and to avoid user-mistakes over
'=='. At the very least, a deliberate avoidance of opEquals() will help to
alleviate common errors?

Is it perhaps better to /add/ opEquals() with a "static assert(0);" in it?
At least the intention would be made thoroughly clear, and the compiler
would catch those easy-to-make 'mistakes'?

That's a genuine question ...

Of course, such classes could not be used where opEquals() usage is implied
by D "built-in" functionality (things that should perhaps be in the library
instead). Messy.

- Kris


"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:d37unm$1buv$1 digitaldaemon.com...
 Kris wrote:
 What sayeth ye?

 - Kris

I'm not sure that I got the use of these operators wrapped up correctly, but I like 'is', so I hope that it succeds (and possibly get a negative cousin into the language). Lars Ivar Igesund

Apr 09 2005
parent Sean Kelly <sean f4.ca> writes:
In article <d380r6$1enu$1 digitaldaemon.com>, Kris says...
That's a good point, Lars Ivar. I was also somewhat confused over the
distinction until this exercise. Perhaps I still am. I was, however,
relieved to discover "is" behaves in an equivalent manner for all types (as
it should; at least /one/ of 'em should :)

Personally, I always use 'is' rather than '===.' I find the latter form just a bit too easy to misread, though I don't think I'm in much danger of mistyping one when I mean the other. I would love if there were an 'isnt' or something similar in the language.
Can't help but feel something so fundamental should surely be trivial to
grasp, and be thoroughly consistent in its usage. Compared to Java, I think
D fails this sniff test quite badly WRT '==' and '!='. On the other hand,
"is" does pass that test.

Perhaps the real issue here, though, is whether 'is' should exist at all. I
personally like it, but then the continued and parallel existence of the
traditional '==' & '!=' confuses the waters badly; as you indicate.

I think the traditional operators should stay as-is for the sake of consistency. If '==' were changed to be an identity comparison then the other comparison operators would need to change as well (<, >, etc). And I don't see a reason to have all those operators compare addresses instead of object contents. As an aside, how are address comparisons handled on NUMA machines? I know std::less in C++ is required to work for pointers, but I don't have any experience with machines where such comparisons might be a tad odd.
I'll probably make an effort to provide equals() methods within library
classes and structs, to make usage clear, and to avoid user-mistakes over
'=='. At the very least, a deliberate avoidance of opEquals() will help to
alleviate common errors?

Probably a good idea for the Java folks, though I'm not likely to use them. But as a library programmer I'm probably more likely to use equivalence comparisons than identity comparisons anyway.
Is it perhaps better to /add/ opEquals() with a "static assert(0);" in it?
At least the intention would be made thoroughly clear, and the compiler
would catch those easy-to-make 'mistakes'?

It would be better IMO to remove opEquals from Object if it's there. Compile-time errors are always preferable to run-time errors. Sean
Apr 09 2005
prev sibling next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Kris wrote:
 Food for thought:
 
 Java is explicit about the distinction between equality and identity,
 just as D is. However, where D uses '==' as an equivalence operator,
 Java uses an equals() method. Where D uses (triple) '===' and 'is'
 for identity purposes, Java uses the traditional double '==' instead.
 
 
 So, what's that got to do with the price of tea in China?
 
 While porting 125,000 lines of Java to D, and an interesting thing
 happened. You'll perhaps not be surprised to hear Java identity style
 tests are far more prevalent than equivalence tests, but you may be
 surprised to know that the former comprised 98.75% of all explicit
 tests within those 125,000 lines. To embellish, equals() was applied
 just 1.25% of the time.
 
 Please note that we're talking about high-quality Java code that
 makes extensive use of OO practices, and does indeed use equals()
 appropriately when doing class comparisons. It's just that there's
 relatively little call for that kind of thing once you get beyond
 writing sorting-algorithms, containers, and so on. What I'd classify
 as "user-level code" appears to apply equivalence testing rather
 seldom.

This does make one think. Traditionally, the problem with new languages is, they are discussed and tested with relatively small programs or snippets. The _problem_ here is that small programs are both structurally and statistically different from large programs. People tend to not ponder these possible differences -- at all. The same phenomenon is markedly visible when teaching programming languages. The new coder's first largish program tends to have the same overall structure (stretched out) as the homework programs. (This results in only a few bloated classes, or overly long procedures / functions.) Small programs use proportionally less OO (in general). The smaller the program, or the less OO it contains, the larger the proportion of equality tests compared to identity tests. This naturally leads to myopia that hampers judgment when discussing, say, choice of operators.
 The Java code was converted mechanically, so it was thankfully easy
 to change all identity tests into the D equivalent, which is the word
 'is', or the triplet '==='. Likewise, the inversion was converted
 from '!=' to the D triplet '!=='. Each equals() instance was
 translated into the more traditional twin '==' equivalence operator.
 
 This has some notable ramifications; of which I'll attempt to be
 brief:
 
 1) The converted Java code now has reams of  'is' statements
 throughout the code, which makes it look 'interesting', to say the
 least. Quite nice, actually; and eminantly readable, even vaguely
 amusing at times. The '!==' instances look suitably alien by
 comparison. This amplifies the need for a sibling for the word 'is',
 such as the oft proposes 'not' or the colloquial 'aint'.
 
 BTW, using 'is' generates optimal code for that 98.75% of tests
 within that large body of code. That is absolutely not the case when
 applying the traditional operators instead. Look at the emitted
 codegen.
 
 2) Anyone used to C or Java will habitually use the traditional '=='
 and '!=' all over their D code. This is actually the *wrong* thing to
 do, since those operators in D are for equivalence testing instead of
 identity testing. This has implications for both performance and for
 "expectations of behaviour". For example, the subsequent addition of
 an opEquals() to some aggregate may break the overall system in all
 manner of subtle and unexpected ways, where the original developer
 used '==' by force of habit.
 
 3) Just as importantly, this highlights a significant divergence of D
 from C and, IMO, in a rather fundamental manner. Think about this:
 you should actually be using 'is' most of the time instead of (twin)
 '=='. How many of you even use 'is' at all?
 
 One might perhaps argue the numbers above are artificially inflated
 since many of those test are applied to native types rather than to
 classes and structs ~ that may be true. But we're talking about
 something that's already well-developed as a habit in the community
 (the double '==') and we're talking about consistency in the majority
 case.
 
 I think D has perhaps made a serious blunder here. IMO, Java has the
 right approach by maintaining compatability for the vast majority of
 usage, whilst providing an option for testing "deep equivalence" via
 the equals() method for the remaining small percentage.

A problem with bringing this up is, that to most, this may seem like an unimportant issue. So, why bother to change, or even think hard enough about this -- there are "more practical" things open at the moment. It's good you brought it up now, before it's too late to even discuss this. Since we aim for D to become used in large projects, this really is important. While I personally don't here present an explicit opinion on the issue itself, I do think this should be carefully discussed, right now, before D1.0. When discussing, we should keep in mind, that the audience here may not represent the D programmers 3 years from now. If D succeeds, then most will be doing "user level coding" in large projects, and D should become superior in that use. But today, many of us do one-person projects, library writing, compiler writing [ ;-) ], or lab experiments on syntax and semantics, or compiler bugs. This biases our opinions, and whenever one does not notice it himself, it exacerbates the difficulties of really seeing where we should be going with D.
 D has effectively inverted that, and almost requires the adoption of
 a different, and somewhat confusing, idiom to do what has been
 tradition for a rather long time. The alternative is potentially
 error-prone code.
 
 There's ostensibly nothing wrong with change, but it's not clear what
 the benefit is here ~ if any?
 
 At the very least, one has to mentally shift gears to perform
 identity tests on classes and structs instead of native types. This
 would be OK if such things were in the minority, but they're not. In
 the case noted above, one has to continually shift gears for the
 overwhelming majority of tests.

There's so much legacy in this room, it begs for explanation why this difference was introduced in D. If the explanation is good, then fine, let's keep it -- but definitely not for "just because".
 Those of you who avoid OO like the plague will likely not be bothered
 by such trivialities. For the rest, is it best to full embrace "is"
 and just stick with it?
 
 What sayeth ye?
 
 - Kris
 
 
 

Apr 09 2005
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
To me it's not confusing.  I've worked with Java fairly little, and with 
other languages such as C and PHP more.

PHP implements many things in a very similar way to D.  I actually 
expect this to be a good thing for D, considering both PHP's popularity 
and relative slowness compared to D.

A good example is concatenation, as PHP also uses a separate operator - 
although, it uses . instead of ~, and forces the use of -> for 
OOP/structs/etc.  That said, PHP is not as OOP friendly as the languages 
you're likely used to, and most people either don't use it or use it 
incorrectly (overlord classes are too common.)

For this, which is my point (sorry), PHP is also similar.  It's 
different, because PHP is weakly typed, but consider the following code:

function func($test)
{
    static $i;

    if ($test == '+')
       return ++$i;
    else
       return $i + (int) $test;
}

Surely, you can see the immediate differences between PHP and most other 
langauges right away.  But, because of this, you won't see the *MISTAKE* 
I made in the above code (purposefully, though.)  It is the subject of 
your post - ==.

Why?  Because if I call func() with 0 as an argument here, the test will 
return TRUE.  You'll remember that in weakly typed languages, this:

$test == '+'

Will cast down to the following if $test is an int:

$test == (int) '+'

Which is clearly true (since casting, in weakly typed languages, 
converts) when $test is zero (as PHP has no NaN.)

The solution here is, again, ===.  It means "equal without conversion". 
  Since PHP has no pointers, this is the strictest way to test.  It's 
also - according to benchmarks - much faster.

The way I write PHP code, at least, I'm always aware of the type of any 
given variable (or, if not, I know the type is unknown.)  As such, the 
operator I want to use is not ==.  Most of the time, I should be using 
=== - it's error checking, for one thing.

Now, as someone heavily indoctrinated into OOP, I can imagine you saying 
this has absolutely nothing to do with your post.  I disagree.  Your 
post has nothing to do with OOP, but rather with operators, their 
meanings, and the use thereof.

You're saying that the "change" D has made is wrong.  Thus, you're also 
saying that the order for the symbols PHP took is wrong, since it took 
the same order (even though they mean different things.)  Again, I disagree.

D is not a child of Java.  D isn't necessarily expecting a throng of 
Java programmers to convert their code from Java to D.  Indeed, 
considering it has bugs in its OOP this is unlikely imho.  No, D came 
from C.  PHP, also, as weakly typed as it is, came from C.

And thus, they both made the right choices.  Seems to have paid off for 
the language used on over 30% of webservers on the internet (I think it 
was mroe, can't remember.)

Clearly, it would have been a horrible mistake if PHP had been looking 
for programmers to come out of the woodwork from Java and switch to PHP. 
  I don't think that was their intention.  Is it D's?

-[Unknown]


 D has effectively inverted that, and almost requires the adoption of a
 different, and somewhat confusing, idiom to do what has been tradition for a
 rather long time. The alternative is potentially error-prone code.
 
 There's ostensibly nothing wrong with change, but it's not clear what the
 benefit is here ~ if any?
 
 At the very least, one has to mentally shift gears to perform identity tests
 on classes and structs instead of native types. This would be OK if such
 things were in the minority, but they're not. In the case noted above, one
 has to continually shift gears for the overwhelming majority of tests.
 
 Those of you who avoid OO like the plague will likely not be bothered by
 such trivialities. For the rest, is it best to full embrace "is" and just
 stick with it?
 

Apr 09 2005
parent reply "Kris" <fu bar.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message
<snip>
 The way I write PHP code, at least, I'm always aware of the type of any
 given variable (or, if not, I know the type is unknown.)  As such, the
 operator I want to use is not ==.  Most of the time, I should be using
 === - it's error checking, for one thing.

Excellent!
 Now, as someone heavily indoctrinated into OOP, I can imagine you saying
 this has absolutely nothing to do with your post.  I disagree.

Eh? You're making some truly wild assertions there. You might as well claim I'm currently sitting in the air on the sharp end of a twenty foot pole, with a chicken strapped to my head and a dancing-bear performing the can-can on my shoulder. I mean, really ...
Your
 post has nothing to do with OOP, but rather with operators, their
 meanings, and the use thereof.

Duh. The point I raised is particularly noticeable with aggregates, in that one often has to mentally switch gears to use "is", rather than just using '= =' as one would with native types. You may have missed the postulation entirely, WB, so I'll spell it out to you again ~ it's perhaps easier, from the point of consistency, to just adopt the usage of "is" /all of the time/, with native types too, rather than switching back and forth between "is" and '= =' (98.75% of the time, in the example given). If so, that begs the question: why have both forms? (there's a further, implied, postulation. But we'll ignore that). If you don't use aggregates, or you are someone who never, ever, makes a mistake, then you can happily ignore the post in its entirety. However, there's almost 8000 explicit tests in that particular body of code. When one has to constantly think about which operator to use in which context, to get the /same/ job done, how many mistakes will be made? The fact that '= = =' is so close to '= =' just serves to amplify the issue (not to mention that some printers make them look almost identical). This is why I wonder (aloud) whether just using "is", for everything, is ultimately a better way to go. If you just don't like "is" then simply state so.
 You're saying that the "change" D has made is wrong.  Thus, you're also
 saying that the order for the symbols PHP took is wrong, since it took
 the same order (even though they mean different things.)  Again, I

Given the tenuous and questionable context you pose, I truly don't give a rat's ass what PHP did or does. You're more than welcome to draw such conclusions and comparisons for yourself. The point was that of potential confusion. Again, the postulation was that it's perhaps better to just use "is" (and its as-yet non-existing companion) for the overwhelming majority of cases (98.75% in the example given) and use either '= =' (or perhaps even an equals() method) for the remaining cases where a true "deep equivalence" is required. Lest ye forget, the post was directed towards a final question mark ("fully embrace 'is' ?"). In addition, the post was clearly marked as "food for thought". If you wish to extract vast quantities of coal from there, go right ahead. The reason for posting was to give pause for a wee bit of reflection. Instead, (given your earlier assertions upon my personal intent, preferences, and likely answers) you appear to be somewhat upset and taking it as flame bait. That's too bad, so I'll ask you to read it again with a touch more levity. Or don't bother. Your choice. Additionally, you're focusing on just one aspect. There's more to that post than just some thoughts on whether D did the right thing or not when introducing five (somewhat overlapping) operators to do exactly the same job that three can do. Think about it.
 D is not a child of Java.  D isn't necessarily expecting a throng of
 Java programmers to convert their code from Java to D.  Indeed,
 considering it has bugs in its OOP this is unlikely imho.  No, D came
 from C.  PHP, also, as weakly typed as it is, came from C.

Seems to me like you seriously misread the post, since you apparently just veered off the road and into the ocean. Java just happened to be the comparison point since it was the source of the example (it also happens to be considerably closer to D than you may care to admit. But just exactly who cares if it is?)
 And thus, they both made the right choices.  Seems to have paid off for
 the language used on over 30% of webservers on the internet (I think it
 was mroe, can't remember.)
 Clearly, it would have been a horrible mistake if PHP had been looking
 for programmers to come out of the woodwork from Java and switch to PHP.
   I don't think that was their intention.  Is it D's?

Hmmm. You're off on an entirely different topic than I. Would be happy to join your new thread on that particular subject, if you like.
Apr 09 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I'll try to be short, since then there's less to misconstrue:

Firstly, I said:
 Now, as someone heavily indoctrinated into OOP, I can imagine...

This means, "knowing that you like OOP, I am worried that you will believe the above...". It was not an assertion, not a poke, not anything more than an admittance of fear (that you would not understand my meaning.) My fear, not yours - the statement had little to do with you, indeed. I'm sorry you took me wrong. Now, let me try again with my example. PHP: $x = 'test'; $y = 'test'; $x == $y; C++: x = new string("test"); y = new string("test"); x == y; D: x = "test"; y = "test"; x == y; Java: x = "test"; y = "test"; x.equals(y); Which one is different? My childhood experience with Sesame Street allows me to point immediately to Java. Do I get a gold star? I agree that comparing, in very very many cases especially with aggregates - and even in some with strings, is the Right Thing (tm). I am not arguing about that, in any way, shape, or form. Please do not misunderstand me. I'm simply saying that as much as this is the Right Thing (tm), it's wrong because other languages don't do it, and clearly that means it would be confusing if D reversed their meanings. Of course, it's true that the following are equivalent: 5 == 5 5 === 5 So, it wouldn't be *that* bad, but it would still be different from C++. I agree that D is a movement toward Java, and again please do not misunderstand or misconstrue my meaning when I say that I don't frankly care. That's not the point. I am trying to say that D came from C++, and so it makes sense to act more like C++ if there's a possibly confusing point. And, surely, this is not something you would propose for after 1.0, is it? I mean, obviously it would break code.... so you mean it for 1.0, then, right? -[Unknown]
Apr 09 2005
parent reply "Kris" <fu bar.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org>
 Firstly, I said:
  > Now, as someone heavily indoctrinated into OOP, I can imagine...

 This means, "knowing that you like OOP, I am worried that you will
 believe the above...".  It was not an assertion, not a poke, not
 anything more than an admittance of fear (that you would not understand
 my meaning.)  My fear, not yours - the statement had little to do with
 you, indeed.

Thanks for the clarification.
 Now, let me try again with my example.

All clear and understood :)
 And, surely, this is not something you would propose for after 1.0, is
 it?  I mean, obviously it would break code.... so you mean it for 1.0,
 then, right?

This explains a lot. I was quite careful not to propose any change to D at all, other than noting further evidence for a companion to "is" (such as "not", or whatever). It was "food for thought" only, and a reflection of one persons experience porting a rather significant chunk of what I consider high-quality "user level code" to D. If you, and others, feel D should change in some related way then I'll likely support that. But, frankly, I'm really tired of trying to foster change in D itself. This was merely a "Hey! Did you know?", since it was clear to me I'd had a certain quality of snow-blindness WRT this particular area of D. There was big question-mark as to whether it was even worth bothering to post. If you're asking my opinion whether a change should be made pre-release, then I'll repeat what was noted earlier: D has five operators to do exactly the same job of three. That, alone, should give us all some pause. - Kris
Apr 09 2005
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
I hope you'll forgive me then; when I see things like this:

 I think D has perhaps made a serious blunder here.

I read "please change the above." So, it seems we both jumped to conclusions and read what did not exist between the lines... Personally, and call me crazy, I like the way it's done here. If I was used to === instead of ==, I might want to reverse it, but I've already explain that at length. To me, it just seems silly when you can do this: if (instance + 5 > 0) But you have to do this: if (instance.equals(5)) If we're not to have an operator for "equal in value", why bother with +, -, >, <, or others? We could have instance.add, subtract, isLessThan, and similar... and they'd be more readable, too, just like equals. As much as you described that is/=== was used more than ==, how much were they used in comparison to other operators? I say this only because those other operators work on the value of the variable just as clearly as == does, at least in D. When would you ever use them if they worked on the pointer or some such? A counterargument there, I think, is that while an aggregate could theoretically be easily/efficiently identified as less than or greater than another, it might be a bit more "heavy" to check if it is, completely, equal to a peer aggregate. Just food for thought, as well - sorry again for my misunderstanding. And, as for == when there's no instance, I feel pretty strongly (although I haven't mentioned it prior) that - especially as you note that value checks are often uncommon - they should have an error message, except in release mode. Meaning, this: if (instance == 5) Would be equivalent to: if (instance === null) throw new UninitializedReferenceException(); // e.g. if (instance == 5) Not even necessarily for other operators/method calls, because that would get slow. But, it seems as if it might be a common error. Of course, this likely won't float (or rather rock) anyone's, least of all Walter's, boat. And... I likely only want that, admittedly, because I've worked with C# and it does roughly this. But, it would be much easier for those new to the language, and if it send along its filename and line possibly even easier to debug. -[Unknown]
 This explains a lot.
 
 I was quite careful not to propose any change to D at all, other than noting
 further evidence for a companion to "is" (such as "not", or whatever).
 
 It was "food for thought" only, and a reflection of one persons experience
 porting a rather significant chunk of what I consider high-quality "user
 level code" to D. If you, and others, feel D should change in some related
 way then I'll likely support that. But, frankly, I'm really tired of trying
 to foster change in D itself.
 
 This was merely a "Hey! Did you know?", since it was clear to me I'd had a
 certain quality of snow-blindness WRT this particular area of D. There was
 big question-mark as to whether it was even worth bothering to post.
 
 If you're asking my opinion whether a change should be made pre-release,
 then I'll repeat what was noted earlier: D has five operators to do exactly
 the same job of three. That, alone, should give us all some pause.
 
 - Kris

Apr 09 2005
prev sibling next sibling parent reply Ben Hinkle <Ben_member pathlink.com> writes:
What sayeth ye?

I agree Java, C and C++ programmers will get burned often in porting code and using == when they should use "is". I've caught myself typing "is" and !== in C++ code so I've started to go to the D side :-) It would be nice to somehow make == so that it doesn't seg-v on a null object reference. I started to feel a little better about == after realizing a dlint can flag "obj == null". Still, it is annoying to catch my fingers coding in the wrong language, though. -Ben
Apr 09 2005
parent "Kris" <fu bar.com> writes:
"Ben Hinkle" <Ben_member pathlink.com> wrote in message
news:d3a3bv$107b$1 digitaldaemon.com...
What sayeth ye?

I agree Java, C and C++ programmers will get burned often in porting code

 using == when they should use "is". I've caught myself typing "is" and !==

 C++ code so I've started to go to the D side :-)

Me too :-) I had someone looking over my shoulder the other day, whilst writing some Java, and was asked just what the heck was I typing ... Anyway. Thanks for reading and 'getting' the point of the post.
 It would be nice to somehow make == so that it doesn't seg-v on a null

 reference. I started to feel a little better about == after realizing a

 can flag "obj == null".

(does it still do that? I tried briefly a week or two ago, and it seemed to catch the null correctly. But looking at the codegen is when I realized my own personal blindness on this subject, and just how badly I needed to use "is" everywhere instead)
Apr 09 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kris wrote:

 This has some notable ramifications; of which I'll attempt to be brief:
 
 1) The converted Java code now has reams of  'is' statements throughout the
 code, which makes it look 'interesting', to say the least. Quite nice,
 actually; and eminantly readable, even vaguely amusing at times. The '!=='
 instances look suitably alien by comparison. This amplifies the need for a
 sibling for the word 'is', such as the oft proposes 'not' or the colloquial
 'aint'.

And something tells me that it didn't look very tempting to rewrite the "x !== y" with the officially sanctioned workaround "!(x is y)", right ? (like the equally ugly "version (Foo) {} else" workaround for #ifndef) Wonder that if there wasn't a "!==" already, if "isnot" would be all that popular ? For instance, there is no negative alternative for "in" ? (And for some reason, the Perl construct "unless" is still not popular) Anyway, like you say - mixing "is" and "!==" does look outlandish.... But I'm in the "why not have all four of them" camp myself, as usual. Adding "isnot" keyword for TOKnotidentity is trivial, I posted a patch ? The only uncertaintanty was the spelling thereof, but that might be big enough of an issue to kill the entire keyword... I also suggested the alternative "~is", in celebration of the D destructor syntax. :-)
 2) Anyone used to C or Java will habitually use the traditional '==' and
 '!=' all over their D code. This is actually the *wrong* thing to do, since
 those operators in D are for equivalence testing instead of identity
 testing. This has implications for both performance and for "expectations of
 behaviour". For example, the subsequent addition of an opEquals() to some
 aggregate may break the overall system in all manner of subtle and
 unexpected ways, where the original developer used '==' by force of habit.

I think the "problem" is that D mixes two different paradigms into one ? C: x = "test"; // const pointer y = "test"; strcmp(x,y) == 0; // equality x == y; // identity Java: x = "test"; // String object y = "test"; x.equals(y); // equality x == y; // identity D: x = "test"; // dynamic array y = "test"; x == y; // equality x is y; // identity Perhaps this was a lame example, since "x.equals(y)" in all - due to string pooling, and that it doesn't show the similarity to primitives ? i = 1; j = 1; assert(i == j); // equality Or if one checks for "less than" instead ? C: strcmp(x,y) < 0; Java: x.compareTo(y) < 0; D: x < y; Since D mixes two paradigms, it has some extra traps than C / Java... For instance, "struct", "struct*" and "Object" works very differently ? (the exception to the rule being the pointer type, not too surprisingly) Regular structs => http://www.digitalmars.com/d/ctod.html#structcmp, where as pointers or references work as C (memcmp) or Java (equals) But in *isolation*, the D approach is very short and clean - compared... And one can still use "is" with pointers too in D, just be consistant.
 I think D has perhaps made a serious blunder here. IMO, Java has the right
 approach by maintaining compatability for the vast majority of usage, whilst
 providing an option for testing "deep equivalence" via the equals() method
 for the remaining small percentage.

I think D has made a good choice, but you are right - it is not very "compatible". (at least not to Java, it should be compatible with C) Guess it boils down to how important this compatibility is, for D ? In my opinion (and code), the most common use of identity is "!== null", and that has already been beaten to death - with the widespread use of "assert(x);" or "if (y) { }" - I think ? (due to the lack of booleans). It would also be good if the compiler could catch "== null", "!= null", and other constructs that are a runtime NullError waiting to happen... (or re-define the meaning of equals for null, as is discussed below) But changing D to make it behave like Java ? Not sure it's a good idea. Since people confuse equality and identity all the time there, too ? And, by accident, I stumbled upon this interesting proposal via Google: http://cdsmith.twu.net/professional/java/pontifications/comparison.html (from 2001, suggesting to add a '===' operator to the Java language...) It featured the good suggestion of making '==' *not* throw Exceptions: # return true if both references are null. # return false if one and only one of the references is null. # delegate to the first object's equals(Object) method if both objects are non-null. AFAIK, that in theory/pseudo-code is done by modifying "_d_obj_eq" ? dmd/src/phobos/internal/obj.d: -13,6 +13,7 int _d_obj_eq(Object o1, Object o2) { + if (o2 is null) return o1 is null; else return o1 is o2 || (o1 && o1.opEquals(o2)); } I'm *not* sure whether that's all the DMD change that is needed... (it probably needs some more internal code-gen changes, as well) But it would be nice if comparisions with null were *defined* in D, other than to instead invoke a implementation-defined behaviour... ? (segfault / bus error, or throw RuntimeError("access violation")) http://www.digitalmars.com/d/expression.html#EqualExpression: "For class objects, equality is defined as the result of calling Object.opEquals(). If one or the other or both objects are null, an exception is raised." Avoiding this null-dereference would be a nice change to D, I think. I'm not sure if it would have any negative sides ? Does anyone else ? (it seems to be working just fine for "null" D strings and arrays...) --anders
Apr 10 2005
next sibling parent reply novice3 <novice3_member pathlink.com> writes:
hello all

whats the problem with !is instead of isnot ?
of course it looks better with the syntax highlighting...
Apr 10 2005
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
novice3 wrote:

 whats the problem with !is instead of isnot ?
 of course it looks better with the syntax highlighting...

"!" is not usually part of such words, but "~is" could work ? (where ~/tilde is the binary "not" symbol, used in destructor) Both would need a extension of the allowed keyword characters. I just think that ~ would look more like part of the keyword ? And I guess most people would prefer reading "is!", than "!is", ("is not" versus "not is") and is! does have parsing problems... Save ! for the (ugly) recommended "!(x is y)" syntax, perhaps ? <http://www.digitalmars.com/d/expression.html#EqualExpression> Binary (bitwise) not: (the "one's complement") unary ~ : ~0 == -1 Array concatenation: (combines the two arrays) binary ~ : "a" ~ "b" Constructor: this(); Destructor: ~this(); // "not constructor" Then again, I'm not sure how it works out in practice ? writef("%s",foo ~ bar); assert(param ~is null); data[bitnum >> 5] &= ~(1L << (bitnum & 31)); Hmm... Perhaps not all *that* great, but it limps along ? And it *would* avoid all the spelling issues of "isnot"... (isnt, isnot, aint, "isn't", "ain't", "is not", iSnot, etc) Assuming that ~/tilde is added to the allowed id characters, and '!==' commented out just like '===' is, it would be like: { "is", TOKidentity }, // ===, '≡' { "~is", TOKnotidentity }, // !==, '≢' So I think I will change my current (ignored) feature suggestion of "isnot", into the even more obscure "~is" keyword instead... http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList Assuming for a second that the D "this" and "~this" syntax was better than adding new keywords, like "construct" / "destruct" ? And I don't think that the '===' and '!==' should be removed, just that 'is' (possibly '~is') should be the preferred form. It would of course be possible to add "~in" too, but with the current pointer syntax I'm not not sure what it would return ? --anders
Apr 10 2005
next sibling parent reply spock (ex novice3) <spock_member pathlink.com> writes:
In article <d3bea0$2ijr$1 digitaldaemon.com>,
=?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= says...
novice3 wrote:

 whats the problem with !is instead of isnot ?
 of course it looks better with the syntax highlighting...

"!" is not usually part of such words, but "~is" could work ? (where ~/tilde is the binary "not" symbol, used in destructor) Both would need a extension of the allowed keyword characters. I just think that ~ would look more like part of the keyword ? And I guess most people would prefer reading "is!", than "!is", ("is not" versus "not is") and is! does have parsing problems... Save ! for the (ugly) recommended "!(x is y)" syntax, perhaps ? <http://www.digitalmars.com/d/expression.html#EqualExpression> Binary (bitwise) not: (the "one's complement") unary ~ : ~0 == -1 Array concatenation: (combines the two arrays) binary ~ : "a" ~ "b" Constructor: this(); Destructor: ~this(); // "not constructor" Then again, I'm not sure how it works out in practice ? writef("%s",foo ~ bar); assert(param ~is null); data[bitnum >> 5] &= ~(1L << (bitnum & 31)); Hmm... Perhaps not all *that* great, but it limps along ? And it *would* avoid all the spelling issues of "isnot"... (isnt, isnot, aint, "isn't", "ain't", "is not", iSnot, etc) Assuming that ~/tilde is added to the allowed id characters, and '!==' commented out just like '===' is, it would be like: { "is", TOKidentity }, // ===, '≡' { "~is", TOKnotidentity }, // !==, '≢' So I think I will change my current (ignored) feature suggestion of "isnot", into the even more obscure "~is" keyword instead... http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList Assuming for a second that the D "this" and "~this" syntax was better than adding new keywords, like "construct" / "destruct" ? And I don't think that the '===' and '!==' should be removed, just that 'is' (possibly '~is') should be the preferred form. It would of course be possible to add "~in" too, but with the current pointer syntax I'm not not sure what it would return ? --anders

ok "~" (bitwise negation) is less appropriate than "!" (logical negation) "~" is used in destructor too but in method header: it's readable as you notice, "~" is used for concatenation... things are going complicated so i understand mixing "!" with keyword is not usual, but it should be since we need it for at least too keyword, is & in and the workaround are not practical for a non english like me, aint isn't or ain't is just shocking in a computer language == --> != is --> !is in --> !in any other way seems illogical to me captain kirk
Apr 10 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
spock (ex novice3) wrote:

 "~" (bitwise negation) is less appropriate than "!" (logical negation)

Since D uses "bit" for booleans, they're not all that different... ;-) Seriously, any of them would do. Just thought it would be less likely to be mixed up with the normal use, since it's "out of context" here ? So just the fact that it is less apropriate, actually makes it "better".
 so i understand mixing "!" with keyword is not usual, but it should be since
 we need it for at least too keyword, is & in and the workaround are not
 practical

The workaround is just that, a way around the missing feature... (unfortunate in this case, since it's about a deprecated feature) In this case, it looks better to continue with '===' and '!==' instead of switching to an "is" operator that lacks a negative. But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky ? Either way, it needs *some* kind of new token for the not variant! Both of '!' and '~' needs changes to the current lexer, though... (and then one might as well add "is not", and be done with it ?)
 for a non english like me, aint isn't or ain't is just shocking in a computer
 language

I don't think they're going to make it, either... But "isn't" is (just a little) better than "isnt".
 ==  -->  !=

 is  -->  !is
 in  -->  !in
 
 any other way seems illogical to me captain kirk

What's the "not" of a pointer ? (like the "in" operator returns now) For the boolean "in" it makes perfect sense. Just not for the D one. Or do you mean that the "not in" operator should make the D lack of booleans the preferred way, and behave the same as (!(key in hash)) ? It would be nice if there could be a *good* solution to the current "isnot" (TOKnotidentity) and possibly "notin" (much less used, though), and why not the AA problems of "delete" (remove a key from an AA) too. Currently all changes to them, seem stopped by fear of new D keywords ? I have "submitted" two horrible puns and hacks, in lack of any others i.e. "~is" and "out", to match the "is" and "in" expressions... :-) They're a little better than the old ones, IMHO, but not very much ? Then again, I didn't have much problems with the old '===' syntax. Just thought that mixing use of 'is' and '!==' was somewhat strange. --anders
Apr 10 2005
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Bjrklund wrote:
 spock (ex novice3) wrote:
 
 "~" (bitwise negation) is less appropriate than "!" (logical
 negation)

Since D uses "bit" for booleans, they're not all that different... ;-)

AAARRGHHHHHHHHH!!!!!!! >:-Q "A one bit boolean makes a two-bit language." :-(
Apr 11 2005
next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:425A5E89.70605 nospam.org...
 Anders F Bjrklund wrote:
 spock (ex novice3) wrote:

 "~" (bitwise negation) is less appropriate than "!" (logical
 negation)

Since D uses "bit" for booleans, they're not all that different... ;-)

AAARRGHHHHHHHHH!!!!!!! >:-Q "A one bit boolean makes a two-bit language." :-(

No argument from me there.
Apr 11 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 Since D uses "bit" for booleans, they're not all that different...
 ;-)

AAARRGHHHHHHHHH!!!!!!!

Hey, it wasn't the meaning to ruin your morning or anything... (seems like those battle scars haven't healed enough for a joke) Let's just pretend that D now *has* a boolean type called "bool", which can take the values "true" and "false". It's near enough. One day, hopefully soon, Walter will see the light - and then the code will be all ready for it. Let's lead by example here ? It's just a missed opportunity, not the end of world or anything... And if it was good enough for C and C++, I guess D can limp along ? // this is perfectly legal code already: assert(false); Let's talk about something else, shall we ? Like adding "isnot" and be done with that discussion too. There's real stuff to do :-) --anders
Apr 11 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Bjrklund wrote:
 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky ?
 Either way, it needs *some* kind of new token for the not variant!

Damn, folks! What's so horribly wrong with isnot?????? We have foreach, and nobody seems to jump in the river Styx!
Apr 11 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 11 Apr 2005 14:28:53 +0300, Georg Wrede <georg.wrede nospam.org>  
wrote:
 Anders F Bjrklund wrote:
 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky ?
 Either way, it needs *some* kind of new token for the not variant!

Damn, folks! What's so horribly wrong with isnot??????

i-snot perhaps?
 We have foreach, and nobody seems to jump in the river Styx!

Personally, I have no problem with isnot, aint, isnt.. Regan
Apr 11 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:425A5F75.3060405 nospam.org...
 Anders F Bjrklund wrote:
 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky 
 ?
 Either way, it needs *some* kind of new token for the not 
 variant!

Damn, folks! What's so horribly wrong with isnot??????

Nothing at all. I think there's a fear that the M$ patent for IsNot is scaring people. Maybe ...
Apr 11 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Matthew wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message 
 news:425A5F75.3060405 nospam.org...
 
Anders F Bjrklund wrote:

But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky 
?
Either way, it needs *some* kind of new token for the not 
variant!

Damn, folks! What's so horribly wrong with isnot??????

Nothing at all. I think there's a fear that the M$ patent for IsNot is scaring people. Maybe ...

Damn squared! First, I've read the application, and it does not apply to D. Second, folks are getting paranoid. In another post somebody opposed the usage "version(unix)" on the grounds that we may get sued. That's about as intelligent as if I wrote a novel about a housewife, in which she says "I'll hoover the living room". And then some nitwit says I can't publish the novel because then the vacuum firm would sue. (Hell, maybe I'll get sued right now, by both!) LIke "POSIX" were less of a registered trade mark, huh! To top it all, this "version(unix)" guy (IIRC) had no problem with "version(windows)". Go figure. ----------- PS, if everybody isn't nice to me, I'll patent every single word there is. That'd be the end of programming. And if not, then I'll patent every single character combination. I'd live on the Bahamas with 50 virgins, and G. Bush would have to come crawling to me, asking "Pretty please, Mr. Wrede, Sir! May we licence words from you Sir? The NSA, Echelon, IRS, and others really need it!" Oops. Maybe G. Bush has registered his name? Eeeek, he's coming to sue me for usage! I better quit while ahead.
Apr 11 2005
parent Sean Kelly <sean f4.ca> writes:
In article <425A8760.9080206 nospam.org>, Georg Wrede says...
Second, folks are getting paranoid. In another post somebody opposed the 
usage "version(unix)" on the grounds that we may get sued. That's about 
as intelligent as if I wrote a novel about a housewife, in which she 
says "I'll hoover the living room". And then some nitwit says I can't 
publish the novel because then the vacuum firm would sue.

-----------

PS, if everybody isn't nice to me, I'll patent every single word there 
is.

FWIW, you can't patent words, only processes. Words can be trademarked, so long as they aren't in common usage (ie. you couldn't trademark "and"). And I haven't read the patent, but there's no way someone could patent an inverse identity comparison. That would be like trying to patent long division. Finally, the burden of proof for patent violations is on the patent holder, not the potential violator. ie. you're much better off not researching whether something has been patented than vice-versa, especially when you're not spending a bundle on research. If someone has a complaint then it can be dealt with at the time they bring it up. Sean
Apr 11 2005
prev sibling next sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Georg Wrede wrote:

 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky ?
 Either way, it needs *some* kind of new token for the not variant!

Damn, folks! What's so horribly wrong with isnot??????

Nothing... Just waiting for the Word from the W. since DMD 111 ? digitalmars.D/14705 It would also be interesting to know whether '===' and '!==' are going to remain in the language, or eventually be torn out ? I think all of them are useful, but that's just me. Anyway, I would rather have four than just one: "is" Pretty straightforward and universal (math), too: ASCII - Unicode == = (http://www.fileformat.info/info/unicode/char/003d/) != ≠ (http://www.fileformat.info/info/unicode/char/2260/) === ≡ (http://www.fileformat.info/info/unicode/char/2261/) !== ≢ (http://www.fileformat.info/info/unicode/char/2262/) But the english operator "is" isn't too bad either :-) (once this "issue" with the negative form is sorted out) Just wonder if it is going to spread to the others too ? ("equals" ==, "and" &&, "or" ||) Or if this "is" it... ? Just be careful, or we will end up with something like: http://developer.apple.com/documentation/AppleScript/ Conceptual/AppleScriptLangGuide/AppleScript.103.html With the "isn't less than or equal to" operator... (>) --anders
Apr 11 2005
prev sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:425A5F75.3060405 nospam.org...
 Anders F Bjrklund wrote:
 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky ?
 Either way, it needs *some* kind of new token for the not variant!

Damn, folks! What's so horribly wrong with isnot??????

To me the only problem with isnot is that the contraction of "is not" isn't "isnot".
 We have foreach, and nobody seems to jump in the river Styx!

There is no standard contraction of "for each" so foreach is ok.
Apr 11 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:

Damn, folks! What's so horribly wrong with isnot??????

To me the only problem with isnot is that the contraction of "is not" isn't "isnot".

The "isnot" was only used to avoid changing the D lexer. If it *was* to be changed, I guess "is not" is as likely as "is!" or "!is" or "~is" or anything... (which also makes it the most desirable version) I think Walter will get to decide which one it is. Just hope that it isn't the current "!(is)" form ? Seems like most will continue to use '!==', if so. Only problem with "is not" is that it looks like Python :-) --anders
Apr 11 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Anders F Bjrklund" <afb algonet.se> wrote in message 
news:d3e4tn$2nv0$1 digitaldaemon.com...
 Ben Hinkle wrote:

Damn, folks! What's so horribly wrong with isnot??????

To me the only problem with isnot is that the contraction of "is not" isn't "isnot".

The "isnot" was only used to avoid changing the D lexer. If it *was* to be changed, I guess "is not" is as likely as "is!" or "!is" or "~is" or anything... (which also makes it the most desirable version) I think Walter will get to decide which one it is. Just hope that it isn't the current "!(is)" form ? Seems like most will continue to use '!==', if so. Only problem with "is not" is that it looks like Python :-) --anders

IMHO "isnt" is better than "isnot".
Apr 11 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:

 IMHO "isnt" is better than "isnot". 

Might as well use "is not", or there will be endless fights over which one was the best to use... Of course, that's two tokens - which might pose a problem in itself ? At least I *think* it's a problem, or why was e.g. "unsigned int" contracted into "uint" ? Something else ? But both the "isnot" and "isnt" forms does look like typos... Let's hope it can be resolved swiftly, like float literals. (i.e. we debate it here for ages, and W. says: "it's done") As long as *something* is added, "isnt" isnt all that bad. :-) But I think that it's been a "while" with !(foo is null) now: digitalmars.D/826 W: "I'd like to run with the current scheme for a while longer first." It's time to do something about this wart *now*. It not(is pretty)... --anders
Apr 11 2005
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <d3e3jj$2mel$1 digitaldaemon.com>, Ben Hinkle says...
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:425A5F75.3060405 nospam.org...
 Anders F Bjrklund wrote:
 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky ?
 Either way, it needs *some* kind of new token for the not variant!

Damn, folks! What's so horribly wrong with isnot??????

To me the only problem with isnot is that the contraction of "is not" isn't "isnot".
 We have foreach, and nobody seems to jump in the river Styx!

There is no standard contraction of "for each" so foreach is ok.

You should take a trip to West Virginia some time. Folks out that way would probably have this shortened to "for'ch" or "ferch" in no time. (I once had a friend who did construction in those mountains. He said that one guy on the job site had managed to contract "Could I please have another one?" to "'nothern?". True story.) - EricAnderton at yahoo
Apr 11 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"pragma" <pragma_member pathlink.com> wrote in message 
news:d3e8ea$2sh1$1 digitaldaemon.com...
 In article <d3e3jj$2mel$1 digitaldaemon.com>, Ben Hinkle says...
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:425A5F75.3060405 nospam.org...
 Anders F Bjrklund wrote:
 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get 
 lucky ?
 Either way, it needs *some* kind of new token for the not 
 variant!

Damn, folks! What's so horribly wrong with isnot??????

To me the only problem with isnot is that the contraction of "is not" isn't "isnot".
 We have foreach, and nobody seems to jump in the river Styx!

There is no standard contraction of "for each" so foreach is ok.

You should take a trip to West Virginia some time. Folks out that way would probably have this shortened to "for'ch" or "ferch" in no time. (I once had a friend who did construction in those mountains. He said that one guy on the job site had managed to contract "Could I please have another one?" to "'nothern?". True story.)

Tha m'no n'naught 'bart t'nth 'r'England, s'll a'cn se
Apr 11 2005
prev sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:d3e3jj$2mel$1 digitaldaemon.com...
 "Georg Wrede" <georg.wrede nospam.org> wrote in message 
 news:425A5F75.3060405 nospam.org...
 Anders F Bjrklund wrote:
 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky 
 ?
 Either way, it needs *some* kind of new token for the not 
 variant!

Damn, folks! What's so horribly wrong with isnot??????

To me the only problem with isnot is that the contraction of "is not" isn't "isnot".
 We have foreach, and nobody seems to jump in the river Styx!

There is no standard contraction of "for each" so foreach is ok.

'course there is: freach. I believe I have the singular honour of introducing that one. (It'll go in the book, along with death tractor <g>)
Apr 11 2005
prev sibling parent brad domain.invalid writes:
Why not do what python does?
if (a is b) ...
if (a is not b) ...

I'm guessing it is harder on the compiler to do it this way?

Brad
Apr 10 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Bjrklund wrote:
 Since people confuse equality and identity all the time there, too ?

If one of them was keywords only and the other not, then that would remove this confusion, once and for all. In general, anytime there are two concepts "too near each other" (be it in pros' or uninitiateds' minds), they should be made very dissimilar in appearance. -- This is just common sense, and applies to scores of other things outside programming languages, too.
Apr 11 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 Since people confuse equality and identity all the time there, too ?

If one of them was keywords only and the other not, then that would remove this confusion, once and for all.

In Java they are called "equals()" and "==", and people confuse them ? People would still confuse "==" and "is" too, but perhaps less than "==" and "===" when using some weird font unsuitable for programming. Oops, it seems like some bias might have crept into that last sentence. --anders
Apr 11 2005
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <d37pdo$179t$1 digitaldaemon.com>, Kris says...
Food for thought:

I'm thinking constantly, thanks for the brainfood! My home system died a horrible death last Saturday, so I am sans computer on the weekends. My, did this thread *explode* with comments. So my thoughts are going to seem a touch retrograde with respect to the rest of the thread... I'm still catching up.
I think D has perhaps made a serious blunder here. IMO, Java has the right
approach by maintaining compatability for the vast majority of usage, whilst
providing an option for testing "deep equivalence" via the equals() method
for the remaining small percentage.

D has effectively inverted that, and almost requires the adoption of a
different, and somewhat confusing, idiom to do what has been tradition for a
rather long time. The alternative is potentially error-prone code.

There's ostensibly nothing wrong with change, but it's not clear what the
benefit is here ~ if any?

I had to ponder this for a bit. I think that D makes it *more* clear than java in that it tries to make objects more like scalars where Java makes /references/ more like scalars. The difference seems trival at first, but has serious ramifications for generic programming and consistency. Java's operators assume that a reference is really another scalar type. You use '==' to compare two integers so likewise you use it to compare the address stored in two references. This is just like with C pointers. But it introduces the 'equals()' wart for object-value tests just to work around the already-occupied '==' operator. On the other hand, D allows the programmer to treat the reference as a full-fledged type. By this, it assumes that you want to use objects as value-types, so it caters to the value-comparison nature of '=='. Identity tests, which belong wholly to OOP, are evaluated by the 'extra' operators: '===' or 'is'. D has one added advantage: the 'is' operator applies to scalars as well, as it compiles down to a value comparison (since scalar identity and value are one-in-the-same). So when you look at it, D is vastly more consistent: Java: int a,b; Integer c,d; if(a == b){} // value comparsion if(a == b){} // identity comparsion if(c.equals(d)){} // value comparison if(c == d){} // identity comparision D: int a,b; Integer c,d; if(a == b){} // value comparsion if(a is b){} // identity comparsion (same as '==' in this case) if(c == d){} // value comparison (opEquals) if(c is d){} // identity comparision (compare references) .. since the meaning of '==' is context-sensitive in D only to make the semantics of the operator the same in all cases; same goes for 'is'. Java makes the reverse tradeoff, which makes it easier for the compiler-writer (references are scalars unless followed by '.') and harder on the programmer. As for littering one's code with 'is' all over the place: I think its a good thing. For starters, 'is' cannot be confused with '=' whereas '==' can (don't get me started on '==='). It can be used freely on any type, and is anything but ambiguous as to what it means. If for no other reason, it has a rather cosmetic affect on code: Integer a,b; bit result1 = a === b; bit result2 = a is b; // easier to read. I'm on the fence when it comes to depricating '===' and '!==', although I'm leaning more towards deprication. IMO, it just seems inconsistent to have two sets of operators for one task only. Since object-identity tests are in their own category, they might as well get a different treatment just so they're not confused with value-style tests. Furthermore on consistency: we need a word to represent '!=='. In order of preference, I'd like to see any one of the following: 1) isnot 2) is not * 3) isnt 4) !is 5) notis 6) not is 7) is! .. 998) aint 999) iSnot (/imagines a G4 cube-style kleenex box) (* 'not' should also be considered for an alternative to '!') - EricAnderton at yahoo
Apr 11 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
pragma wrote:

 I'm on the fence when it comes to depricating '===' and '!==', although I'm
 leaning more towards deprication.  IMO, it just seems inconsistent to have two
 sets of operators for one task only. 

You shouldn't listen to everything that Guido (van Rossum) says... :-) http://c2.com/cgi/wiki?TimTowTdi Seriously, I think we might have gotten ourselves another Religious War. And I'm with Larry (Wall) here... --anders
Apr 11 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Bjrklund wrote:
 
 http://c2.com/cgi/wiki?TimTowTdi

Ahhh, that made me remember why we never got anywhere with "isnot". It wasn't that most were against it, it was only that everyone and their dog had to have their own word to propose. "Another way to defeat democracy: have 4000 candidates for the presidency."
Apr 11 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:425AB303.9090407 nospam.org...
 Anders F Bjrklund wrote:
 http://c2.com/cgi/wiki?TimTowTdi

Ahhh, that made me remember why we never got anywhere with "isnot". It wasn't that most were against it, it was only that everyone and their dog had to have their own word to propose. "Another way to defeat democracy: have 4000 candidates for the presidency."

What's de-mo-cra-cy? (Did I say it right?)
Apr 11 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 1) isnot

Fine
 2) is not *

 (* 'not' should also be considered for an alternative to '!')

Do you mean we should consider reserving "not" as a keyword in an of itself, and therefore avoid mixing it with is for identity? If so, I agree
 3) isnt

Less good that isnot, but I can live with it without a murmur of disquiet.
 4) !is

Hopelessly crap
 5) notis

Unreadable
 6) not is

Somewhat unreadable
 7) is!

Definitely not
 ..
 998) aint

Horrid. I agree with Walter that D has a nice (albeit ambiguous) ring, and Phobos does not smack of amateur hour, but aint most certainly would.
 999) iSnot (/imagines a G4 cube-style kleenex box)

:-) (I'm still entertaining getting a Mac - the end of financial year beckons - and I reckon an iSnot would go quite well)
Apr 11 2005
parent reply pragma <pragma_member pathlink.com> writes:
In article <d3f0i7$q3o$1 digitaldaemon.com>, Matthew says...
 1) isnot

Fine
 2) is not *

 (* 'not' should also be considered for an alternative to '!')

Do you mean we should consider reserving "not" as a keyword in an of itself, and therefore avoid mixing it with is for identity? If so, I agree

I think we're on the same page here, but let me clarify all the same. :) To sum up, 'not' could be used interchangably with '!'. I can see this having some ramifications for the lexer and lexer, and then again perhaps !; that's for Walter do decide if its doable. I for one feel !like some others in that !using '!', and replacing it with a readable word, would keep some expressions from being !readable. Perhaps deciding what is or !is readable is best left for a new thread?
 ..
 998) aint

Horrid. I agree with Walter that D has a nice (albeit ambiguous) ring, and Phobos does not smack of amateur hour, but aint most certainly would.

Agreed. I guess we could always leave that for a "localized" version of D:
 Foobar[] x;
 forch(Foobar a; x){
   if(x aint nuthin){
      a.gitSomethin();
   }
   else nothern;
 }

- EricAnderton at yahoo
Apr 12 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"pragma" <pragma_member pathlink.com> wrote in message 
news:d3gqmg$2sg5$1 digitaldaemon.com...
 In article <d3f0i7$q3o$1 digitaldaemon.com>, Matthew says...
 1) isnot

Fine
 2) is not *

 (* 'not' should also be considered for an alternative to '!')

Do you mean we should consider reserving "not" as a keyword in an of itself, and therefore avoid mixing it with is for identity? If so, I agree

I think we're on the same page here, but let me clarify all the same. :) To sum up, 'not' could be used interchangably with '!'. I can see this having some ramifications for the lexer and lexer, and then again perhaps !; that's for Walter do decide if its doable. I for one feel !like some others in that !using '!', and replacing it with a readable word, would keep some expressions from being !readable. Perhaps deciding what is or !is readable is best left for a new thread?

I buy that
Apr 12 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just how far could this be carried though.
For example...

If (true xor false and (a lessthan c) and not (a equals b))...

any thoughts?  :)

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3i8oj$s5n$1 digitaldaemon.com...
 "pragma" <pragma_member pathlink.com> wrote in message
 news:d3gqmg$2sg5$1 digitaldaemon.com...
 In article <d3f0i7$q3o$1 digitaldaemon.com>, Matthew says...


 To sum up, 'not' could be used interchangably with '!'.  I can see
 this having
 some ramifications for the lexer and lexer, and then again perhaps
 !; that's for
 Walter do decide if its doable. I for one feel !like some others
 in that !using
 '!', and replacing it with a readable word, would keep some
 expressions from
 being !readable.  Perhaps deciding what is or !is readable is best
 left for a
 new thread?

I buy that

Apr 13 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
TechnoZeus wrote:

 I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.
 Gets me thinking, just how far could this be carried though. For example...
 
 If (true xor false and (a lessthan c) and not (a equals b))...
 
 any thoughts?  :)

Score one more for "isnt"... Since "is !" is very different from "!==" ? Actually, "xor" seems to still be missing from D too (i.e. ^^ operator) "if left parenthesis true exclusive or false and left parenthesis a... </hawking>. Please, let's avoid those keywords. What's wrong with math ? Think I know why Walter didn't want to leave "!(a is b)". Can of worms. --anders
Apr 13 2005
prev sibling next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d3ihmm$13ru$1 digitaldaemon.com...
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just how 
far could this be carried though. For example...

 If (true xor false and (a lessthan c) and not (a equals b))...

 any thoughts?  :)

All fine to me. But one must ask whether there's any advantage to it, I guess.
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3i8oj$s5n$1 digitaldaemon.com...
 "pragma" <pragma_member pathlink.com> wrote in message
 news:d3gqmg$2sg5$1 digitaldaemon.com...
 In article <d3f0i7$q3o$1 digitaldaemon.com>, Matthew says...


 To sum up, 'not' could be used interchangably with '!'.  I can see
 this having
 some ramifications for the lexer and lexer, and then again perhaps
 !; that's for
 Walter do decide if its doable. I for one feel !like some others
 in that !using
 '!', and replacing it with a readable word, would keep some
 expressions from
 being !readable.  Perhaps deciding what is or !is readable is best
 left for a
 new thread?

I buy that


Apr 13 2005
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ik9s$167k$1 digitaldaemon.com...
 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d3ihmm$13ru$1 digitaldaemon.com...
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just how 
far could this be carried though. For example...

 If (true xor false and (a lessthan c) and not (a equals b))...

 any thoughts?  :)

All fine to me. But one must ask whether there's any advantage to it, I guess.

Bobdamnit, I changed my mind and deleted it from the outbox. And yet here it is. Belay that opinion, ye black-hearted blaggards!
Apr 13 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ikh2$169m$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ik9s$167k$1 digitaldaemon.com...
 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d3ihmm$13ru$1 digitaldaemon.com...
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just how
far could this be carried though. For example...

 If (true xor false and (a lessthan c) and not (a equals b))...

 any thoughts?  :)

All fine to me. But one must ask whether there's any advantage to it, I guess.

Bobdamnit, I changed my mind and deleted it from the outbox. And yet here it is. Belay that opinion, ye black-hearted blaggards!

Yes, there would be potential advantages... but to my knowledge they haven't been explored, or weighed against the potential disadvantages. For example, there is no good way to search for the "=" operator in a text file, without also finding every "==" and "+=" and so on. Also, a newbie could easily see the diggerence between "a equals b" and "a becomes b" where the difference between "a == b" and "a = b" isn't so obvious. Don't get me wrong here. I'm not advocating the use of "equals" or "becomes" or any specific keywords at this point. I'm simply pointing out that there are "potential" benefits of development along this line of thinking. I do like the idea of boolean comparator keywords (including "not") and the "isnt" keyword... but I haven't thought through their potential disadvantages, if any, so I'm not advocating them as of yet... just stating my opinion, that the idea is worth further discussion. TZ
Apr 13 2005
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d3im12$17es$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ikh2$169m$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ik9s$167k$1 digitaldaemon.com...
 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d3ihmm$13ru$1 digitaldaemon.com...
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just 
how
far could this be carried though. For example...

 If (true xor false and (a lessthan c) and not (a equals b))...

 any thoughts?  :)

All fine to me. But one must ask whether there's any advantage to it, I guess.

Bobdamnit, I changed my mind and deleted it from the outbox. And yet here it is. Belay that opinion, ye black-hearted blaggards!

Yes, there would be potential advantages... but to my knowledge they haven't been explored, or weighed against the potential disadvantages. For example, there is no good way to search for the "=" operator in a text file, without also finding every "==" and "+=" and so on. Also, a newbie could easily see the diggerence between "a equals b" and "a becomes b" where the difference between "a == b" and "a = b" isn't so obvious. Don't get me wrong here. I'm not advocating the use of "equals" or "becomes" or any specific keywords at this point. I'm simply pointing out that there are "potential" benefits of development along this line of thinking. I do like the idea of boolean comparator keywords (including "not") and the "isnt" keyword... but I haven't thought through their potential disadvantages, if any, so I'm not advocating them as of yet... just stating my opinion, that the idea is worth further discussion.

Fair enough btw, you can search for a single equals by "[^=]=[^=]" btw2: I tried to respond to your emails today, but got your funny email defense thing. Although I don't mind getting into a challenge response once in order to register, I'm not going to be bothered to have to append a keyword to the subject line of every email I send. Do you have a secret undefended email address, which you could let me know by email me on my not-so-private email matthew hat synesis dot com dotility-dot-dot au? Cheers Matthew
Apr 13 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
What program were you doing your searching in?  I'm writing code in Notepad and
Wordpad at the moment, and neither one of them support that sort of search to
my knowledge.

As for my e-mail, I'll check the box that catches unexpected e-mails and look
for your e-mail there.  Expect a reply if I find it.

TechnoZeus

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ipmv$1ai1$1 digitaldaemon.com...
 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d3im12$17es$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ikh2$169m$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ik9s$167k$1 digitaldaemon.com...
 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d3ihmm$13ru$1 digitaldaemon.com...
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just
how
far could this be carried though. For example...

 If (true xor false and (a lessthan c) and not (a equals b))...

 any thoughts?  :)

All fine to me. But one must ask whether there's any advantage to it, I guess.

Bobdamnit, I changed my mind and deleted it from the outbox. And yet here it is. Belay that opinion, ye black-hearted blaggards!

Yes, there would be potential advantages... but to my knowledge they haven't been explored, or weighed against the potential disadvantages. For example, there is no good way to search for the "=" operator in a text file, without also finding every "==" and "+=" and so on. Also, a newbie could easily see the diggerence between "a equals b" and "a becomes b" where the difference between "a == b" and "a = b" isn't so obvious. Don't get me wrong here. I'm not advocating the use of "equals" or "becomes" or any specific keywords at this point. I'm simply pointing out that there are "potential" benefits of development along this line of thinking. I do like the idea of boolean comparator keywords (including "not") and the "isnt" keyword... but I haven't thought through their potential disadvantages, if any, so I'm not advocating them as of yet... just stating my opinion, that the idea is worth further discussion.

Fair enough btw, you can search for a single equals by "[^=]=[^=]" btw2: I tried to respond to your emails today, but got your funny email defense thing. Although I don't mind getting into a challenge response once in order to register, I'm not going to be bothered to have to append a keyword to the subject line of every email I send. Do you have a secret undefended email address, which you could let me know by email me on my not-so-private email matthew hat synesis dot com dotility-dot-dot au? Cheers Matthew

Apr 13 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message 
news:d3j529$1l27$1 digitaldaemon.com...
 What program were you doing your searching in?  I'm writing code 
 in Notepad and Wordpad at the moment, and neither one of them 
 support that sort of search to my knowledge.

Desist immediately, and get GVIM (http://vim.org/). Sure, if you're unfamiliar with vi keystrokes, it'll seem quite weird at first, but I _promise_ that once you get used to it you'll be a very happy puppy. (Caveat: I actually do my D editing in Visual Studio '98, but I do edit make scripts, Ruby, Python, C & C++ in GVIM both on Win32 and Linux, it's really cool. Others on this ng have specific expertiese on using it with D, and they can help out, I'm sure.) I also recommend the book "Vi IMproved - Vim", by Steve Oualline.
Apr 13 2005
next sibling parent reply "Kris" <fu bar.com> writes:
"John Demme" <me teqdruid.com> wrote in message
 Don't listen to him! He's mad!

 Get yourself a nice copy of emacs.

 (heh heh heh)

Yes, Yes! Matthew has entirely lost control of his faculties. Emacs is the one, the true, the Holy Shoe! (ahem ... *cough*)
Apr 13 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Kris" <fu bar.com> wrote in message 
news:d3kc9h$2ns6$1 digitaldaemon.com...
 "John Demme" <me teqdruid.com> wrote in message
 Don't listen to him! He's mad!

 Get yourself a nice copy of emacs.

 (heh heh heh)

Yes, Yes! Matthew has entirely lost control of his faculties. Emacs is the one, the true, the Holy Shoe! (ahem ... *cough*)

But - and I am 100% ignorant of Emacs - doesn't it take like a whole-system-approach, i.e. you have to give your brain up to Lisp, and "the Emacs way"? At least that's the impression I've gotten from people - such as Raymond - who've written about the two. (Bear in mind that I've been hanging on to VS98 for 7 years now, so reluctant am I to have to get productive in another editor. So I might not be sane ...)
Apr 13 2005
next sibling parent reply "Kris" <fu bar.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3kch3$2o1r$1 digitaldaemon.com...
 "Kris" <fu bar.com> wrote in message
 news:d3kc9h$2ns6$1 digitaldaemon.com...
 "John Demme" <me teqdruid.com> wrote in message
 Don't listen to him! He's mad!

 Get yourself a nice copy of emacs.

 (heh heh heh)

Yes, Yes! Matthew has entirely lost control of his faculties. Emacs is the one, the true, the Holy Shoe! (ahem ... *cough*)

But - and I am 100% ignorant of Emacs - doesn't it take like a whole-system-approach, i.e. you have to give your brain up to Lisp, and "the Emacs way"? At least that's the impression I've gotten from people - such as Raymond - who've written about the two.

No more than the "VI way" :-) Yes, Emacs wields a mighty sword, but you can use just what you need and no more. I use it only as an editor, nowadays. A changing world. Lisp is just one flavour of cutomization langauges used by various versions of Emacs. Back in the day, I used one of the originals on TOPS-20 (DEC-20), where the underlying language was TECO (TECO put APL to shame). http://en.wikipedia.org/wiki/Emacs
 (Bear in mind that I've been hanging on to VS98 for 7 years now, so
 reluctant am I to have to get productive in another editor. So I
 might not be sane ...)

VS98 probably has a keyboard mapping for Epsilon. This is about as close as many people get to Emacs, and the MSVC mappings are sometimes a bit bogus (I first used Epsilon about 20 years ago, and was truly happy with it for at least a decade). T'was a productive IDE at that time. But (as you know), editors are like religion. People both applaud and defend them in the most irrational manner. Hence the reference to Montly Pythons "Grail".
Apr 13 2005
parent "Kris" <fu bar.com> writes:
Whoops; meant to note that Epsilon uses a small dialect of C as the
customization language instead (called EEL: Epsilon Extension Language). An
editor that arrived with its very own compiler used to be considered
something very special :-)

- Kris
Apr 13 2005
prev sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Hmmm.  I have a copy of Microsoft Visual Studio version 6 someplace around
here... although not currently installed.  Isn't that like 92 versions before
VS98?  Hehe.

Oh, I tried that vim.org site and it wouldn't open.  Is there an alternative
address, or a mirror site?  As for Emacs, I tried downloading that once a while
back, hoping to use it to read some LaTex files, but the download said it was
going to take something like 7 days, so I canceled it.

TZ

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3kch3$2o1r$1 digitaldaemon.com...
 "Kris" <fu bar.com> wrote in message
 news:d3kc9h$2ns6$1 digitaldaemon.com...
 "John Demme" <me teqdruid.com> wrote in message
 Don't listen to him! He's mad!

 Get yourself a nice copy of emacs.

 (heh heh heh)

Yes, Yes! Matthew has entirely lost control of his faculties. Emacs is the one, the true, the Holy Shoe! (ahem ... *cough*)

But - and I am 100% ignorant of Emacs - doesn't it take like a whole-system-approach, i.e. you have to give your brain up to Lisp, and "the Emacs way"? At least that's the impression I've gotten from people - such as Raymond - who've written about the two. (Bear in mind that I've been hanging on to VS98 for 7 years now, so reluctant am I to have to get productive in another editor. So I might not be sane ...)

Apr 13 2005
prev sibling parent reply jicman <jicman_member pathlink.com> writes:
Matthew is right.  Vim is the junk...!

jic

Matthew says...
"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message 
news:d3j529$1l27$1 digitaldaemon.com...
 What program were you doing your searching in?  I'm writing code 
 in Notepad and Wordpad at the moment, and neither one of them 
 support that sort of search to my knowledge.

Desist immediately, and get GVIM (http://vim.org/). Sure, if you're unfamiliar with vi keystrokes, it'll seem quite weird at first, but I _promise_ that once you get used to it you'll be a very happy puppy. (Caveat: I actually do my D editing in Visual Studio '98, but I do edit make scripts, Ruby, Python, C & C++ in GVIM both on Win32 and Linux, it's really cool. Others on this ng have specific expertiese on using it with D, and they can help out, I'm sure.) I also recommend the book "Vi IMproved - Vim", by Steve Oualline.

Apr 13 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"jicman" <jicman_member pathlink.com> wrote in message 
news:d3knb8$2uov$1 digitaldaemon.com...
 Matthew is right.  Vim is the junk...!

Oh Bob! Have I become old? I don't know whether junk is good or bad. I'm guessing .... good ... ?? :-(
Apr 13 2005
parent reply jicman <jicman_member pathlink.com> writes:
Sorry, trying to use some of the new lingo I've heard on the street, the other
day.  It means good.  Like, "vim is the bomb!" Which is really good.  I used to
use emacs, but... Long story...  But I have been using vim for the last 4 years
and it rocks!  Ahem, it's really swell. :-)

jic

Matthew says...
"jicman" <jicman_member pathlink.com> wrote in message 
news:d3knb8$2uov$1 digitaldaemon.com...
 Matthew is right.  Vim is the junk...!

Oh Bob! Have I become old? I don't know whether junk is good or bad. I'm guessing .... good ... ?? :-(

Apr 13 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
There are reasons such terms are common "on the streets" and usually
coincidence isn't one of them.  Hehe.  Personally, I try to stay away from
using ambiguous language.  Hard enough to be understood sometimes without
adding the element of ambiguity.

TZ

"jicman" <jicman_member pathlink.com> wrote in message
news:d3kret$13b$1 digitaldaemon.com...
 Sorry, trying to use some of the new lingo I've heard on the street, the other
 day.  It means good.  Like, "vim is the bomb!" Which is really good.  I used to
 use emacs, but... Long story...  But I have been using vim for the last 4 years
 and it rocks!  Ahem, it's really swell. :-)

 jic

 Matthew says...
"jicman" <jicman_member pathlink.com> wrote in message
news:d3knb8$2uov$1 digitaldaemon.com...
 Matthew is right.  Vim is the junk...!

Oh Bob! Have I become old? I don't know whether junk is good or bad. I'm guessing .... good ... ?? :-(


Apr 13 2005
prev sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <d3ihmm$13ru$1 digitaldaemon.com>, TechnoZeus says...
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just how far could this be carried though.
For example...

If (true xor false and (a lessthan c) and not (a equals b))...

any thoughts?  :)

Yes. ColdFusion has three-to-four letter shorthand operator names to replace the typical comparison operators. They also have a longhand form that, IMO, nobody really uses: http://www.intermedia.net/support/ColdFusion/CF5docs/CFML_Reference/Expressions5.html Their motivation for operators like "gte", "lte" and so forth was simple. ColdFusion is a markup-based language, so symbols like '<' and '>' have implications for parsing the language as a whole. (it'd be like using "[" or "{" as operators in D). I for one would love to see such operators in place, but I'm also biased. DSP (or anyplace else that D is embedded in markup) could benefit hugely from such an addition as "<[CDATA[...]]>" tags wouldn't be needed for code blocks. It is far and away better than using entities (eg. "if(x &lt;= y){}"), a hideous looking workaround, even if its commonplace to so in XPATH and XSLT. To me the gain seems minimal at best, although it would cause the bare minimum of headache for developers. I seriously doubt anyone is using "and", "or", "gte" or "eq" as identifiers in their programs. - EricAnderton at yahoo
Apr 13 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <d3jhio$20jr$1 digitaldaemon.com>, pragma says...
In article <d3ihmm$13ru$1 digitaldaemon.com>, TechnoZeus says...
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just how far could this be carried though.
For example...

If (true xor false and (a lessthan c) and not (a equals b))...

any thoughts?  :)

Yes. ColdFusion has three-to-four letter shorthand operator names to replace the typical comparison operators. They also have a longhand form that, IMO, nobody really uses: http://www.intermedia.net/support/ColdFusion/CF5docs/CFML_Reference/Expressions5.html

FWIW, this exists in C++ as well, though nobody seems to use them. Check section 2.5 of the C++ standard--Alternative tokens. Here's the table from that section: <% { and && and_eq &= _ %> } bitor | or_eq |= <: [ or || xor_eq ^= :> ] xor ^ not ! %: # compl ~ not_eq != %:%: ## bitand &
Apr 13 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:d3jn59$25vi$1 digitaldaemon.com...
 In article <d3jhio$20jr$1 digitaldaemon.com>, pragma says...
In article <d3ihmm$13ru$1 digitaldaemon.com>, TechnoZeus says...
I agree also.  Adding a "not" keyword as an equivilant of the "!" 
operator would be nice.  Gets me thinking, just how far could 
this be carried though. For example...

If (true xor false and (a lessthan c) and not (a equals b))...

any thoughts?  :)

Yes. ColdFusion has three-to-four letter shorthand operator names to replace the typical comparison operators. They also have a longhand form that, IMO, nobody really uses: http://www.intermedia.net/support/ColdFusion/CF5docs/CFML_Reference/Expressions5.html

FWIW, this exists in C++ as well, though nobody seems to use them. Check section 2.5 of the C++ standard--Alternative tokens. Here's the table from that section: <% { and && and_eq &= _ %> } bitor | or_eq |= <: [ or || xor_eq ^= :> ] xor ^ not ! %: # compl ~ not_eq != %:%: ## bitand &

Indeed. And it can catch you out in quite vexing ways. ;)
Apr 13 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
I actually kindof like it.  :)  Then again, when I read what Walter had written
in http://digitalmars.com/d/sdwest/paper.html about the "researcher who wore
special goggles that turned the world upside down" my first thought was that it
sounded like something I would do.  In fact, I have thought about such
experiments, but simply lacked the means to try them.  I do have sun-glasses
that I've made with different color lenses though, and ones that I made
specifically to train my brain to have better control over which eye it pays
the most attention to the input from at any given time, as well as defractive
glasses that I use to see the difference between various composite lightings
such as halogen or florescent.

But a point that I would like to state clearly is that in the same way that
having several ways to do a single task in Windows allows each user to find the
one that best fits their way of thinking, whether it's keyboard shortcuts or
fly-out menus or context menus or icons, or whatever... it could increase the
ease of getting started if alternatives are available that are intuitive enough
for some people to "guess" them.

The use of "not" as an alternative to "!" would be a good example of something
that would probably be that intuitive.  Few people would have trouble
understanding things like "a and not b" or not(a<b) for example.  Again, I'm
not advocating the use of "not" specifically, but simply using it as an example
to make my point.  What it intuitive shouldn't be decided by one person, if
there is any opportunity to have more than one person colaborate on the
effort... and the more diverse their ways of thinking, the better.

TZ

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3kanv$2mu4$2 digitaldaemon.com...
 "Sean Kelly" <sean f4.ca> wrote in message
 news:d3jn59$25vi$1 digitaldaemon.com...
 In article <d3jhio$20jr$1 digitaldaemon.com>, pragma says...
In article <d3ihmm$13ru$1 digitaldaemon.com>, TechnoZeus says...
I agree also.  Adding a "not" keyword as an equivilant of the "!"
operator would be nice.  Gets me thinking, just how far could
this be carried though. For example...

If (true xor false and (a lessthan c) and not (a equals b))...

any thoughts?  :)

Yes. ColdFusion has three-to-four letter shorthand operator names to replace the typical comparison operators. They also have a longhand form that, IMO, nobody really uses: http://www.intermedia.net/support/ColdFusion/CF5docs/CFML_Reference/Expressions5.html

FWIW, this exists in C++ as well, though nobody seems to use them. Check section 2.5 of the C++ standard--Alternative tokens. Here's the table from that section: <% { and && and_eq &= _ %> } bitor | or_eq |= <: [ or || xor_eq ^= :> ] xor ^ not ! %: # compl ~ not_eq != %:%: ## bitand &

Indeed. And it can catch you out in quite vexing ways. ;)

Apr 14 2005
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
pragma wrote:

...

 Furthermore on consistency: we need a word to represent '!=='.  

I agree.
 In order of preference, I'd like to see any one of the following:

1) isnt 2) isnot 3) is not* 4) !is 5) ~is 6) not is 7) notis 8) is! ... 998) aint 999) iSnot I feel like the first two are really by far the strongest candidates, but in the spirit of consensus, I extended out my list. I think it's much more important to have a reasonable counterpart to !== than to have my personal favorite. :) -- jcc7 http://jcc_7.tripod.com/d/
Apr 11 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
J C Calvarese wrote:

 Furthermore on consistency: we need a word to represent '!=='.  

I agree.
 In order of preference, I'd like to see any one of the following:

1) isnt 2) isnot

 I feel like the first two are really by far the strongest candidates, 
 but in the spirit of consensus, I extended out my list. I think it's 
 much more important to have a reasonable counterpart to !== than to have 
 my personal favorite. :)

They also have the advantage of being very simple to add to D... digitalmars.D/14705 So, what now ? Will there be mutiny on the Mars starship "Bounty" or will Walter pick one and just silently drop it into DMD 0.121 ? I'll just go with '!==' now, and "s/\!\=\=/$TOKnotidentity/g" later. It's not the that name of the operator is a big deal, just the fight. --anders
Apr 12 2005
prev sibling parent reply "Kris" <fu bar.com> writes:
Some additional thoughts (inline):

"pragma" <pragma_member pathlink.com> wrote in message
 In article <d37pdo$179t$1 digitaldaemon.com>, Kris says...
Food for thought:

I'm thinking constantly, thanks for the brainfood! My home system died a horrible death last Saturday, so I am sans computer

 weekends.  My, did this thread *explode* with comments.

 So my thoughts are going to seem a touch retrograde with respect to the

 the thread... I'm still catching up.

I think D has perhaps made a serious blunder here. IMO, Java has the


approach by maintaining compatability for the vast majority of usage,


providing an option for testing "deep equivalence" via the equals()


for the remaining small percentage.

D has effectively inverted that, and almost requires the adoption of a
different, and somewhat confusing, idiom to do what has been tradition


rather long time. The alternative is potentially error-prone code.

There's ostensibly nothing wrong with change, but it's not clear what the
benefit is here ~ if any?

I had to ponder this for a bit. I think that D makes it *more* clear than

 in that it tries to make objects more like scalars where Java makes

 more like scalars.  The difference seems trival at first, but has serious
 ramifications for generic programming and consistency.

 Java's operators assume that a reference is really another scalar type.

 '==' to compare two integers so likewise you use it to compare the address
 stored in two references.  This is just like with C pointers.  But it

 the 'equals()' wart for object-value tests just to work around the
 already-occupied '==' operator.

 On the other hand, D allows the programmer to treat the reference as a
 full-fledged type.  By this, it assumes that you want to use objects as
 value-types, so it caters to the value-comparison nature of '=='.

 tests, which belong wholly to OOP, are evaluated by the 'extra' operators:

 or 'is'.

 D has one added advantage: the 'is' operator applies to scalars as well,

 compiles down to a value comparison (since scalar identity and value are
 one-in-the-same).

Absolutely. This is why the original post was suggesting fully adopting 'is'. And is partly why it warned against blanket use of the '= =' operator ~ if you're not actually trying to do a deep copy, the codegen is truly inefficient where aggregates are concerned. I think the quote from the original post is perhaps being taken out of context a little? The issue that quote focuses upon is not one of which operator is best for the job ~ instead, the focus is one of consistently with long-term habits in the community. The point being made was that Java caters to those habits for the overwhelming majority of cases, whereas D almost does the opposite (when we're talking about aggregates). I'll expand on this later on.
 So when you look at it, D is vastly more consistent:

 Java:
 int a,b;
 Integer c,d;
 if(a == b){} // value comparsion
 if(a == b){} // identity comparsion
 if(c.equals(d)){} // value comparison
 if(c == d){} // identity comparision

 D:
 int a,b;
 Integer c,d;
 if(a == b){} // value comparsion
 if(a is b){} // identity comparsion (same as '==' in this case)
 if(c == d){} // value comparison (opEquals)
 if(c is d){} // identity comparision (compare references)

 .. since the meaning of '==' is context-sensitive in D only to make the
 semantics of the operator the same in all cases; same goes for 'is'.  Java

 the reverse tradeoff, which makes it easier for the compiler-writer

 are scalars unless followed by '.') and harder on the programmer.

Disagree here, Eric. I think Java tried to cater to the most widely used cases of '= =' such that it rarely conflicts with established use (per the original example given). Don't forget that Java was attempting to pick up C/C++ users, just like D ;-)
 As for littering one's code with 'is' all over the place: I think its a

 thing.  For starters, 'is' cannot be confused with '=' whereas '==' can

 get me started on '===').  It can be used freely on any type, and is

 but ambiguous as to what it means.

 If for no other reason, it has a rather cosmetic affect on code:

 Integer a,b;
 bit result1 = a === b;
 bit result2 = a is b; // easier to read.

Couldn't agree more.
 I'm on the fence when it comes to depricating '===' and '!==', although

 leaning more towards deprication.  IMO, it just seems inconsistent to have

 sets of operators for one task only.  Since object-identity tests are in

 own category, they might as well get a different treatment just so they're

 confused with value-style tests.

Simplicity of use is preferable in my book. If there were a counterpart to "is", these two triplet-operators would be completely redundant. Not to mention the issues of confusion regarding certain Fonts.
 Furthermore on consistency: we need a word to represent '!=='.  In order

 preference, I'd like to see any one of the following:

 1) isnot
 2) is not *
 3) isnt
 4) !is
 5) notis
 6) not is
 7) is!
 ..
 998) aint
 999) iSnot (/imagines a G4 cube-style kleenex box)

 (* 'not' should also be considered for an alternative to '!')

Something should certainly be added as a counterpart to 'is'. So, let's speculate briefly: suppose we have "is" and "isnot". Further, let us suppose the usage of "is" becomes the recommended idiom in D; due to its handy "universal" nature. The situation we'd thus be in is as follows: if (x is y) {} if (x isnot y) {} for all types of 'x' and 'y' (aggregates and primitives). This is in rather sharp contrast to the picture in the C/C++/Java world, don't you think? Not that such a notion is bad in and of itself, but it is still a distinct change for such a fundamental operation. This is what the original post was getting at. You make a good point about the consistency of 'is', for the same reasons I favoured it for the mechanical translation. Having said that, the now-generic usage of 'is' has somewhat switched its role from an "identity" operator, and has <gasp> suddenly become identical to the Java '= =' :-) Testing for "deep equivalence" would still be performed using the '= =' and "!=" pair. It could be argued these should be restricted to aggregate types only, since the generic, and consistent, usage of 'is' would be applied to non-aggregate types. But, whatever ~ let's suppose there's still the overlap. Given that, '= =' is now actually the equivalent of the Java equals() method, but with the twist that it can be applied to primitive types also. Confused? No. But you can imagine how many people will feel? The kicker here, if there isn't already one or two, is that unsuspecting C/Java users will apply the twin '= =' anyway, which will do the wrong thing in many, many cases. This is also one of the points made in the original post, given the percentage figures of the example illustrated there. In summation, here's a potential approach: - drop the triplet operators (to help limit confusion) - add a companion to "is", such as "isnot" - indicate "is" and "isnot" are the equivalent of '= =' & '!=' in related languages - indicate very clearly that '= =' does a deep comparison wherever that might apply If these were to happen, I think it would become much more obvious what D is all about in this respect. Finally, I really do think the "is" operator should become defacto-standard for D. But it does take the place of the '= =' operator in related languages, whereas the D '= =' operator is somewhat different. Therein lies significant confusion potential, which brings us back to the quote you highlighted earlier. - Kris
Apr 11 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kris wrote:

 Disagree here, Eric. I think Java tried to cater to the most widely used
 cases of '= =' such that it rarely conflicts with established use (per the
 original example given). Don't forget that Java was attempting to pick up
 C/C++ users, just like D ;-)

Since all strings in Java are objects, the "hidden pointer" in '==' in Java usually trips up the beginner - like already the first week or so: "No, you must use equals() to compare strings in Java." "Well, == does work for string literals. That's special" "No, you can't use the same equals() on number literals." "They are primitive types, you must use Object wrappers" BTW; Did you read the text about adding '===' to Java, instead of '==' to D ? http://cdsmith.twu.net/professional/java/pontifications/comparison.html I thought it provided an interesting read regarding this ? [...]
 Having said that, the now-generic usage of 'is' has somewhat switched its
 role from an "identity" operator, and has <gasp> suddenly become identical
 to the Java '= =' :-)

Interesting point of view. You seem to think that checking identity for primitive types is a natural operation (hadn't even occured to me) I always thought that C checked the equality of the pointers, and that the memcmp/equals had to be added as a call to check to the contents ? (seeing as how the Java references are just "virtual" pointers anyway) I guess your approach does make sense. Just find it somewhat alien :-) And it doesn't offer much help for comparisons, except calling "compare"
 Testing for "deep equivalence" would still be performed using the  '= =' and
 "!=" pair. It could be argued these should be restricted to aggregate types
 only, since the generic, and consistent, usage of 'is' would be applied to
 non-aggregate types.

You mean that (i == j) should be deprecated ? That's pretty "huge"... And that identity should be promoted to the primary operation, with the "equals" offered as a method for the aggregate types ? Q: What if you want to order two things ? i.e. < > >= <=, and so on ? Now those would not be connected to the == and != operators anymore ?
 But, whatever ~ let's suppose there's still the
 overlap. Given that, '= =' is now actually the equivalent of the Java
 equals() method, but with the twist that it can be applied to primitive
 types also. Confused? No. But you can imagine how many people will feel?

I think D has the pretty solution. It's just not the compatible one. (i.e. it does "change" the meaning of '==' for references, which is even more confusing due to the presence of pointers with C-style '==') Also, Java does not have overloaded operators. One reason for "equals" ?
 The kicker here, if there isn't already one or two, is that unsuspecting
 C/Java users will apply the twin '= =' anyway, which will do the wrong thing
 in many, many cases. This is also one of the points made in the original
 post, given the percentage figures of the example illustrated there.
 
 In summation, here's a potential approach:
 
 - drop the triplet operators (to help limit confusion)

Wouldn't it be possible to "recommend" the new and keep the old ? (is this another one of those "consistancy" things fought earlier ?)
 - add a companion to "is", such as "isnot"

Or perhaps "isnt", that doesn't have the same nasal connection... (and does not have the same begging for "is_not" or "isNot", etc)
 - indicate "is" and "isnot" are the equivalent of '= =' & '!=' in related
 languages

It is mentioned on the "C to D" and "Java to D" pages, as a start ? http://www.digitalmars.com/d/ctod.html http://www.prowiki.org/wiki4d/wiki.cgi?JavaToD
 - indicate very clearly that '= =' does a deep comparison wherever that
 might apply

I would add: define '==' in a way that it works with null references... Having "== null" and "null ==" runtime-segfault is not very friendly. If this was fixed, then using '==' instead of '===' would most of the time just be slower - not have the same "crash factor" as now ? (ignoring the special case where you first run with the default/identity opEquals, and then add an member-cmp implementation of opEquals later)
 If these were to happen, I think it would become much more obvious what D is
 all about in this respect.
 
 Finally, I really do think the "is" operator should become defacto-standard
 for D. But it does take the place of the '= =' operator in related
 languages, whereas the D '= =' operator is somewhat different. Therein lies
 significant confusion potential, which brings us back to the quote you
 highlighted earlier.

You mean that the '==' operator in D does not have the same confusion as it currently does in Java ? (i.e. there it works very differently for primitive types and for reference types). Yeah, that's "different". However, I do think it is the Java (and C) method that needs explaining. And I for one do not think that promoting identity is the way to go... --anders
Apr 12 2005
parent reply "Kris" <fu bar.com> writes:
Good points. Thoughts inline:

"Anders F Bjrklund" <afb algonet.se> wrote in message
news:d3g1t4$23l3$1 digitaldaemon.com...
 Kris wrote:

 Disagree here, Eric. I think Java tried to cater to the most widely used
 cases of '= =' such that it rarely conflicts with established use (per


 original example given). Don't forget that Java was attempting to pick


 C/C++ users, just like D ;-)

Since all strings in Java are objects, the "hidden pointer" in '==' in Java usually trips up the beginner - like already the first week or so: "No, you must use equals() to compare strings in Java." "Well, == does work for string literals. That's special" "No, you can't use the same equals() on number literals." "They are primitive types, you must use Object wrappers" BTW; Did you read the text about adding '===' to Java, instead of '==' to D ? http://cdsmith.twu.net/professional/java/pontifications/comparison.html I thought it provided an interesting read regarding this ?

I didn't, but will.
 [...]
 Having said that, the now-generic usage of 'is' has somewhat switched


 role from an "identity" operator, and has <gasp> suddenly become


 to the Java '= =' :-)

Interesting point of view. You seem to think that checking identity for primitive types is a natural operation (hadn't even occured to me) I always thought that C checked the equality of the pointers, and that the memcmp/equals had to be added as a call to check to the contents ? (seeing as how the Java references are just "virtual" pointers anyway) I guess your approach does make sense. Just find it somewhat alien :-) And it doesn't offer much help for comparisons, except calling "compare"

So we get to the third installment, and perhaps logical conclusion of this meandering path: If the assigned role of '= =' and 'is' were flipped, D would be just like C/Java ~ with the aforementioned twist regarding the equals() working with primitives as well as aggregates. That is, since '= =' is currently the same as a Java equals(), but works with primitives also, and 'is' currently plays the identical role of the Java '= =' operator, switching the D operators around makes D equivalent to Java in the usage of '= =' and equivalent to C for the largest percentage of uses (given the original illustration). The use of 'is' would thus be relegated to "deep equivalence" testing instead. This is all to do with compatability vis-a-vis accepted usage. It is not a proposition for the ideal usage of these operators.
 Testing for "deep equivalence" would still be performed using the  '= ='


 "!=" pair. It could be argued these should be restricted to aggregate


 only, since the generic, and consistent, usage of 'is' would be applied


 non-aggregate types.

You mean that (i == j) should be deprecated ? That's pretty "huge"...

Just food for thought, Anders. But it would never come to that, if the D operators '= =' and 'is' were role-reversed :-)
 And that identity should be promoted to the primary operation,
 with the "equals" offered as a method for the aggregate types ?

 Q: What if you want to order two things ? i.e. < > >= <=, and so on ?
 Now those would not be connected to the == and != operators anymore ?

And if the roles of '= =' and 'is' were reversed ...? Again, this meandering path is about compatability with the majority of use cases. I'm not paying much attention to the value of various theoretical aspects, but more to the general usage of the operators in question.
 But, whatever ~ let's suppose there's still the
 overlap. Given that, '= =' is now actually the equivalent of the Java
 equals() method, but with the twist that it can be applied to primitive
 types also. Confused? No. But you can imagine how many people will feel?

I think D has the pretty solution. It's just not the compatible one. (i.e. it does "change" the meaning of '==' for references, which is even more confusing due to the presence of pointers with C-style '==')

Absolutely. Here we agree fully. The compatability aspect is the one of concern, for all the reasons noted in posts gone by.
 Also, Java does not have overloaded operators. One reason for "equals" ?

Undoubtedly. But that does make it rather easy to negate (since it's a boolean method) and it's easily overloadable. That's one less operator used, and the method-call overhead will typically be drowned by the deep comparison. Don't forget that D has both opEquals() and opCmp() methods. The latter is the despised one, not the former.
 The kicker here, if there isn't already one or two, is that unsuspecting
 C/Java users will apply the twin '= =' anyway, which will do the wrong


 in many, many cases. This is also one of the points made in the original
 post, given the percentage figures of the example illustrated there.

 In summation, here's a potential approach:

 - drop the triplet operators (to help limit confusion)

Wouldn't it be possible to "recommend" the new and keep the old ? (is this another one of those "consistancy" things fought earlier ?)

Sometimes it's better to just let go? Have you noticed I've been adding a space between the '= =' so that it wouldn't be mistaken for '===' ?
 - add a companion to "is", such as "isnot"

Or perhaps "isnt", that doesn't have the same nasal connection... (and does not have the same begging for "is_not" or "isNot", etc)

The suggestion was for purposes of clarity only. Personally I think it's perhaps better to just use "not" as the inverse. It's a logical "not" as opposed to a bitwise "not". e.g. if (x is y) {} if (x not y) {} Once one has adopted 'is', it's a very small step to relate it directly to 'not'. But, whatever (I can already hear some shouting "that reads like if x but not y!")
 - indicate "is" and "isnot" are the equivalent of '= =' & '!=' in


 languages

It is mentioned on the "C to D" and "Java to D" pages, as a start ? http://www.digitalmars.com/d/ctod.html http://www.prowiki.org/wiki4d/wiki.cgi?JavaToD
 - indicate very clearly that '= =' does a deep comparison wherever that
 might apply

I would add: define '==' in a way that it works with null references... Having "== null" and "null ==" runtime-segfault is not very friendly. If this was fixed, then using '==' instead of '===' would most of the time just be slower - not have the same "crash factor" as now ? (ignoring the special case where you first run with the default/identity opEquals, and then add an member-cmp implementation of opEquals later)

Yep; thoughtless application of '= =' currently leads to inefficient codegen (and likely increases the cost of maintenance). But I think the compiler does hande null comparisons recently? Maybe not.
 If these were to happen, I think it would become much more obvious what


 all about in this respect.

 Finally, I really do think the "is" operator should become


 for D. But it does take the place of the '= =' operator in related
 languages, whereas the D '= =' operator is somewhat different. Therein


 significant confusion potential, which brings us back to the quote you
 highlighted earlier.

You mean that the '==' operator in D does not have the same confusion as it currently does in Java ? (i.e. there it works very differently for primitive types and for reference types). Yeah, that's "different".

Sarcasm aside, the D '= =' operator currently /does/ work quite differently for both primitive and reference types. It just a matter of perspective. There's no question that this is a sticky area, and perhaps there will always have to be compromises made regardless of compatability concerns? I don't question that at all. What I do question is the break in backward compatability, which you (and others) acknowledge. However if the D operators '= =' and 'is' were role-reversed, the C & Java compatability would be restored for the majority case (98.75% in the use-case given). There's still compromise going on there, naturally. But, shouldn't one optimize for the majority case?
 However, I do think it is the Java (and C) method that needs explaining.

That may be so (and I agree that they're all somewhat confusing in specific areas), but shouldn't the alienation of current practice be performed with extreme care?
 And I for one do not think that promoting identity is the way to go...

Wasn't promoting 'identity' as a concept, but would operator flipping make things better? It's just a thought. - Kris
Apr 12 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kris wrote: (and I cut it down heavily)

 This is all to do with compatability vis-a-vis accepted usage. It is not a
 proposition for the ideal usage of these operators.

It does sound like a compatibility kludge, that much is certain.
You mean that (i == j) should be deprecated ? That's pretty "huge"...

Just food for thought, Anders. But it would never come to that, if the D operators '= =' and 'is' were role-reversed :-)

Considering there is no identity for primitives, they both map to the same thing anyway. Normally called "equals" (eq). >>Q: What if you want to order two things ? i.e. < > >= <=, and so on ?
Now those would not be connected to the == and != operators anymore ?

And if the roles of '= =' and 'is' were reversed ...?

As in: < is > ? That does look more than a little strange. "less than", "is", "greater than" would be better - although I would still prefer to use "equal to" for the middle one... (or the Swedish equivalent, if I ever read them out aloud)
 Absolutely. Here we agree fully. The compatability aspect is the one of
 concern, for all the reasons noted in posts gone by.

Especially since '==' and null is defined in D to segfault. If it hadn't been for that, it would merely be slower... (again, ignoring "now you opEquals, now you don't" thing)
 Undoubtedly. But that does make it rather easy to negate (since it's a
 boolean method) and it's easily overloadable. That's one less operator used,
 and the method-call overhead will typically be drowned by the deep
 comparison. Don't forget that D has both opEquals() and opCmp() methods. The
 latter is the despised one, not the former.

They're both good, and both available in Java too under different names. And like stated in the D specification, the equals one is pretty often easy to do "faster" than the compare - that might not even be available. Although Java makes it an interface that you implement, (i.e. java.lang.Sortable), whether as D adds the opCmp to Object and has non-sortable classes throw up at runtime instead...
Wouldn't it be possible to "recommend" the new and keep the old ?
(is this another one of those "consistancy" things fought earlier ?)

Sometimes it's better to just let go? Have you noticed I've been adding a space between the '= =' so that it wouldn't be mistaken for '===' ?

"Been annoyed by", yes. :-) Wonder what dumb font would mix the two up ? Surely people aren't using Helvetica or Arial to program in ? <horrors>
You mean that the '==' operator in D does not have the same confusion
as it currently does in Java ? (i.e. there it works very differently
for primitive types and for reference types). Yeah, that's "different".

Sarcasm aside, the D '= =' operator currently /does/ work quite differently for both primitive and reference types. It just a matter of perspective.

The sarcasm was all mine, sorry about that. But I do think if that I have a int, a struct, and a class - that D's '==' works similar for all? (assuming that the class defines opEquals, instead of using the default)
 That may be so (and I agree that they're all somewhat confusing in specific
 areas), but shouldn't the alienation of current practice be performed with
 extreme care?

I'm not sure, there seems to be too many locked positions and legacy considerations to make the ultimate solution come out of this anyway... Funny how D is pinned down by history, before it has even been released?
 Wasn't promoting 'identity' as a concept, but would operator flipping make
 things better? It's just a thought.

Well, '==' IS equals and '===' IS identity... Thus, promoting the 'is' expression is promoting identity. The "equality" of '==' in C and Java is between the pointers (or references), not the contents of them. Maybe it would have been easier if D had used Object*, like suggested by someone else already on this thread. --anders
Apr 12 2005
next sibling parent reply brad domain.invalid writes:
I don't profess to know what I am talking about - so I am going to "ring 
the bell" on this topic - hopefully someone will explain the problem 
like I am a two year old.

I have read this whole thread with interest though, here is what I have 
taken from it
1) Kris ported a significant Java project to D, and found that 99% of 
time Java programmers use == rather than equals(), which in D means that 
99% of the time you will use "is" rather than "=="
  - What exactly is the significance of this finding?  People generally 
want to shallow compare objects rather than deep compare.
2) Generally everybody hates === and !===
3) "is" is good, and needs a counterpart - "isnot" for want of a keyword
4) Does making "==" a reference (shallow) compare break consistancy with 
the other operators, which are effectively deep compares?

I got to thinking about what languages try to achieve with allowing 
operator overloading, I think that they try to make user defined types 
behave exactly as intrinsics.  This is especially important for a 
language that allows templates, as your templates should work with built 
in types and user defined types.  A while ago Derek ran across a problem 
   (thread title "opValue()") where his templates wouldn't work with 
aggregates because "=" does a reference copy, when he infact wanted a 
deep copy.
I think that this is a similar problem - do programmers want their 
operators to do a reference compare, or a deep compare?

In thinking along these lines I realised that D (at the moment) does not 
allow you to create user defined types that behave exactly as built in 
types, because user defined types (ie classes) are references, and built 
in types are not.  It looks to me like there is a huge change in 
thinking required between using built in types and user defined types.
Now, for most objects I think that references are correct and efficient. 
  However for the objects that are designed to look at act like built in 
types (ie, BigNum implementation), then they will NEVER behave exactly 
like built ins.

So I think the real question might be - how do we bridge the gap between 
user defined types and built in types?  This gap doesn't only show up in 
operators, but in passing values/references to functions.

Am I making sense, or being the Village Idiot?  If I am being an Idiot - 
please, please enlighten me.

Brad
Apr 12 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
<brad domain.invalid> wrote in message 
news:d3hc44$5lt$1 digitaldaemon.com...
I don't profess to know what I am talking about - so I am going to 
"ring the bell" on this topic - hopefully someone will explain the 
problem like I am a two year old.

I'm with you 100% on this one. A clarification/summarisation would be most useful at this point
Apr 12 2005
parent reply "Kris" <fu bar.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 <brad domain.invalid> wrote in message
 news:d3hc44$5lt$1 digitaldaemon.com...
I don't profess to know what I am talking about - so I am going to
"ring the bell" on this topic - hopefully someone will explain the
problem like I am a two year old.

I'm with you 100% on this one. A clarification/summarisation would be most useful at this point

OK. I'll attempt to clarify the picture: This topic is, first and foremost, a heads' up about the use of '==' and 'is' within D. It is also about compatability with established practice and habit, borne through the use of D's predecessors. The topic is /not/ a campaign to change the language. I'll repeat that: it is NOT a campaign, since it's been shown such causes, however well intentioned, and/or well supported, are naught but exercises in futility. So, with the preamble out of the way: ------------ D supports the notions of equality and identity. Equality can be thought of as a test to see if two individual entities have equivalent 'value', whereas identity can be thought of as a test whether two entities are, in fact, one and the same. Identity is rarely discussed for primitive types (int, long, bool, etc) since they are typically dealt with via equality. However, pointers to primitive types are covered by the identity umbrella. D supports equality via the '==' operator, and supports identity via the 'is' operator. D has a second operator for identity, which uses a triplet '===' token, plus its inverse '!=='. The problem, if it indeed exists, is one of confusion. Firstly: having two distinct operators to represent identity is surely redundant. I understand Walter has noted problems with misinterpretation between '==' and '===', particularly with certain printer fonts, and there's been past suggestions made to remove that token. There has also been ongoing suggestions to add an inverse companion for 'is' ... many such candidates have been put forward, such as 'isnot', 'aint', and 'is not'. I ran into a situation which tended to amplify a need for such a companion, which is why it's mentioned here. I'll reiterate said situation further on. Secondly: the terms 'identity' and 'equality' are applied in D with significant overlap between the two, and it can be hard to get these terms straight when they are interchanged. For example, the D 'is' identity operator becomes an equality operator when used with primitive types. The D '==' equality operator morphs into an identity operator when used with Objects that don't override the default opEquals() method. Because of this confusing duality I'll, instead, use the terms "shallow equality" and "deep equality" for the rest of this post. Shallow equality does a simple comparison of primitive hardware types, including byte, short, long, float, double, pointers/references, etc. Deep equality performs whatever test are necessary to determine whether one entity is equivalent to another. In extreme cases, the latter might result in a visit to the internet, or to a database. In other cases, the equivalent of a C memcmp() might be performed. Thirdly: D uses the '==' operator in a manner that conflicts with traditional/habitual use (particularly for C & Java users). That is, the operator is traditionally used for shallow equality, whereas D purportedly uses it for deep equality. This can only breed confusion, in that those new to D will invariably apply '==' where they should not. Indeed, habitual use of '==' for shallow comparison is handled in D via the 'is' operator instead. Summary point 1: newcomers to D should likely use 'is' instead of '==', since those two are "equivalent" from a traditional standpoint (both perform a shallow test). Fourthly: the duality of the D '==' operator can lead to unexpected circumstance. For example, the default behavior of '==' is actually a shallow test for primitives, a deep test for arrays (such as char[]), a shallow test for Objects (via the default opEquals), a deep test for structs instances, and a shallow test for struct pointers. Those who blindly call this 'equality' should question their faith. The confusion here is amplified by the conflict with traditional use of '=='. Suppose I, through force of habit, have applied '==' throughout my code and get it debugged and operating correctly. Let's further suppose some maintenance engineer comes along and adds an opEquals() to some existing class, for whatever purpose. Suddenly my code breaks. Why? The original code was operating using the default shallow comparison performed by Object and now that has been changed, by the maintenance engineer, to be some kind of deep comparison. One can argue the original developer (me) should have been explicit about using a shallow test in the first place. Indeed, this is true. Which is partly why Summary Point 1 is worth considering seriously. However, D does not currently lend itself to avoiding this sort of thing. In fact, D seems to embrace exactly this bug by making the default behaviour of '==' be of the shallow variety. A combination of changing tradition, yet not really, can actually increase maintenance costs. Summary point 2: The default shallow test for '==' tends to exaggerate the potential for confusion. Not only because it does a role-defying shallow- rather than deep- comparison, but because it can lead directly to fragile maintenance builds via its changing behaviour. Let's move onto the scenario painted by the original post. I'm going to cut and paste a large chunk of the original here, because the points are, IMO, still valid. Additionally, it's worth getting back to the point, since this thread seems to have fallen into the grasp of ideaologists: <quote> Food for thought: Java is explicit about the distinction between equality and identity, just as D is. However, where D uses '==' as an equivalence operator, Java uses an equals() method. Where D uses (triple) '===' and 'is' for identity purposes, Java uses the traditional double '==' instead. So, what's that got to do with the price of tea in China? While porting 125,000 lines of Java to D, and an interesting thing happened. You'll perhaps not be surprised to hear Java identity style tests are far more prevalent than equivalence tests, but you may be surprised to know that the former comprised 98.75% of all explicit tests within those 125,000 lines. To embellish, equals() was applied just 1.25% of the time. Please note that we're talking about high-quality Java code that makes extensive use of OO practices, and does indeed use equals() appropriately when doing class comparisons. It's just that there's relatively little call for that kind of thing once you get beyond writing sorting-algorithms, containers, and so on. What I'd classify as "user-level code" appears to apply equivalence testing rather seldom. The Java code was converted mechanically, so it was thankfully easy to change all identity tests into the D equivalent, which is the word 'is', or the triplet '==='. Likewise, the inversion was converted from '!=' to the D triplet '!=='. Each equals() instance was translated into the more traditional twin '==' equivalence operator. This has some notable ramifications; of which I'll attempt to be brief: 1) The converted Java code now has reams of 'is' statements throughout the code, which makes it look 'interesting', to say the least. Quite nice, actually; and eminantly readable, even vaguely amusing at times. The '!==' instances look suitably alien by comparison. This amplifies the need for a sibling for the word 'is', such as the oft proposes 'not' or the colloquial 'aint'. BTW, using 'is' generates optimal code for that 98.75% of tests within that large body of code. That is absolutely not the case when applying the traditional operators instead. Look at the emitted codegen. 2) Anyone used to C or Java will habitually use the traditional '==' and '!=' all over their D code. This is actually the *wrong* thing to do, since those operators in D are for equivalence testing instead of identity testing. This has implications for both performance and for "expectations of behaviour". For example, the subsequent addition of an opEquals() to some aggregate may break the overall system in all manner of subtle and unexpected ways, where the original developer used '==' by force of habit. 3) Just as importantly, this highlights a significant divergence of D from C and, IMO, in a rather fundamental manner. Think about this: you should actually be using 'is' most of the time instead of (twin) '=='. How many of you even use 'is' at all? One might perhaps argue the numbers above are artificially inflated since many of those test are applied to native types rather than to classes and structs ~ that may be true. But we're talking about something that's already well-developed as a habit in the community (the double '==') and we're talking about consistency in the majority case. </quote> As you can hopefully see, the illustrative example performs shallow tesing for the overwhelming majority of cases. Deep testing is used for a meager 1.25%. To put this into perspective, there are almost 8000 equivalence tests made within that body of code. Given all that, this thread has noted D would become backward-compatible if the functionality of '==' and 'is' were to be role-reversed. That is, if '==' were to fully retain its shallow heritage (like 'is' does), newcomers would not have to even consider switching to using 'is' for the majority case. This would naturally eliminate the concern over both Summary Points 1 & 2 above. Of course, there's zero expectation that would ever happen to D -- this role reversal notion is pure speculation, and exists simply a means of clarifying the current situation. I hope this summarizes the thread content thus far. I haven't touched on the subject brought up by Brad ("how to bridge the gap between user defined types and built in types?"), which could use some exploration. - Kris ------------------- A few personal notes. This thread was started as an observation. A reflection on interaction with D. With a tip of the hat to GW, I'll point out again that this is not about making a case for change in D. And it is most certainly nothing to do with blind ideological perspective, as one individual appears to have showered upon it. I think this just highlights the difficulties surrounding clear communication in an NG environment. There's language barriers, proximity-cue barriers, social and educational barriers, along with barriers of purpose and intent. The fact that not each and every thread is filled with antagonism can be surprising to some, but many of them are. I find it to be an increasingly painful and fruitless exercise to both read and initiate threads here; even those relating my trivial experiences with D (such as this one). Further, attempting to keep a thread on track is truly becoming an impossible task (hence, the request for a summary). I can't imagine I'm the only one who feels this way ~ which prompts a question: what, if anything, can be done about it?
Apr 13 2005
next sibling parent reply brad domain.invalid writes:
..big snip..
Kris - thank you for taking the time to explain that - very well done. 
I see your point, and agree with you to an extent.  My view is that "==" 
must be consistant with the other compare operators (<,>, etc).  Sp if 
x<y is false and x>y is false then x==y should be true.  Depending on 
the class we are comparing this may not hold - but for sortable classes 
I think that it really should.  To me that is the least surprising result.

To me (I don't program in Java), I expect "==" to be a deep compare.  In 
  C if I compare structs, I get a (admittedly broken) deep compare.  If 
I compare pointers to structs, well I compare pointers - but the type is 
destinguished.  The same goes for C++, if I compare pointers I know my 
type, if I compare objects I expect a deep copy.

Ha!  Perhaps the solution is to drop "is" and "===", make "==" always a 
deep compare, and if you want to compare references, do
if (&a == &b) {} ...
I'm not serious :)

For me it feels more natural to keep D the way it is, and encourage a D 
idiom of "use 'is' to compare references".  To encourage that idiom, 
perhaps the default Object.opEquals() should be dropped, so you cannot 
compare objects with the == operator until you explicity define it.

Cheers
Brad
Apr 13 2005
parent reply "Kris" <fu bar.com> writes:
<brad domain.invalid> wrote in message
 ..big snip..
 Kris - thank you for taking the time to explain that - very well done.
 I see your point, and agree with you to an extent.  My view is that "=="
 must be consistant with the other compare operators (<,>, etc).  Sp if
 x<y is false and x>y is false then x==y should be true.  Depending on
 the class we are comparing this may not hold - but for sortable classes
 I think that it really should.  To me that is the least surprising result.

Where compatability is not an issue, I fully agree. Concern over sorting is certainly warranted.
 To me (I don't program in Java), I expect "==" to be a deep compare.  In
   C if I compare structs, I get a (admittedly broken) deep compare.  If
 I compare pointers to structs, well I compare pointers - but the type is
 destinguished.  The same goes for C++, if I compare pointers I know my
 type, if I compare objects I expect a deep copy.

 Ha!  Perhaps the solution is to drop "is" and "===", make "==" always a
 deep compare, and if you want to compare references, do
 if (&a == &b) {} ...
 I'm not serious :)

But there /is/ merit there :-) I think a large part of of the confusion stems from the deep/shallow flip-flopping of '=='.
 For me it feels more natural to keep D the way it is, and encourage a D
 idiom of "use 'is' to compare references".  To encourage that idiom,
 perhaps the default Object.opEquals() should be dropped, so you cannot
 compare objects with the == operator until you explicity define it.

I've been deliberately avoiding suggesting that, but it would /really/ help the situation. Of course, it's in the same boat as opCmp() since Objects should not be comparable until the developer explicitly say's so, either. I wish you good luck in getting that changed. Aye; - Kris
 Cheers
 Brad

Apr 13 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kris wrote:

For me it feels more natural to keep D the way it is, and encourage a D
idiom of "use 'is' to compare references".  To encourage that idiom,
perhaps the default Object.opEquals() should be dropped, so you cannot
compare objects with the == operator until you explicity define it.

I've been deliberately avoiding suggesting that, but it would /really/ help the situation. Of course, it's in the same boat as opCmp() since Objects should not be comparable until the developer explicitly say's so, either. I wish you good luck in getting that changed.

Walter prefers to have the non-Sortable classes throw up at runtime. http://www.digitalmars.com/d/operatoroverloading.html: "For some objects, testing for less or greater makes no sense. For these, override opCmp() with: class A { int opCmp(Object o) { assert(0); // comparison makes no sense return 0; } }" I kinda like the java.lang.Comparable approach better, myself... http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Comparable.html Especially since the default opCmp() sorts by *reference value* ! ("hmm, let's see, when did I last wanted them sorted by pointer?") --anders
Apr 13 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Anders F Bjrklund" <afb algonet.se> wrote in message 
news:d3k8iu$2kse$1 digitaldaemon.com...
 Kris wrote:

For me it feels more natural to keep D the way it is, and 
encourage a D
idiom of "use 'is' to compare references".  To encourage that 
idiom,
perhaps the default Object.opEquals() should be dropped, so you 
cannot
compare objects with the == operator until you explicity define 
it.

I've been deliberately avoiding suggesting that, but it would /really/ help the situation. Of course, it's in the same boat as opCmp() since Objects should not be comparable until the developer explicitly say's so, either. I wish you good luck in getting that changed.

Walter prefers to have the non-Sortable classes throw up at runtime. http://www.digitalmars.com/d/operatoroverloading.html: "For some objects, testing for less or greater makes no sense. For these, override opCmp() with: class A { int opCmp(Object o) { assert(0); // comparison makes no sense return 0; } }"

Perhaps we should drop all strong typing, have a variant type, and just do all checks at runtime?
Apr 13 2005
next sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Not all comparators are as simple as linear ones.

An ordered pair complex number implementation of a comparator operator should
return a pair of floating point numbers in the range of -1..1 such that both
are zero if the compared values are equal and the location of the ordered pair
has an absolute value of one in the direction of the difference, if the
compared values are not equal.

A vector based complex number comparator operator would give more useful
information by simply returning the difference between the two vectors as an
angle and a scalar, resulting in the scalar being zero if the compared values
are equal and positive otherwise while the angle would represent the direction
of the difference within the complex number plain.

Perhaps it would be a good idea to include an editor with the D compiler, that
color codes the difference between assignment operators, comparators that
compare the "contents" of things (when available to compare) and comparators
that compare the "identities" of things, so that common mistakes would be
easier to avoid or correct.

It is a well known that mix-ups between the "=" and "==" operators are
responsable for a huge number of errors in languages that use both of them.  In
fact, I can barely "see" the difference between them here in Outlook Express
where I'm typing this note, because there is absolutely no gap between the
characters on my screen so it looks like one is simple a slightly stretched
version of the other.

It is even harder to see the difference between "==" and "===" here, and I find
myself constantly selecting small sections of text to count the characters just
to be able to read this thread because of it.  It's unfortunate that the
mathematical identity symbol isn't on most (if any) keyboards, and that also
that it is missing from so many fonts.

Perhaps "===" could be replaced with "_=_" just to make it easier to tell from
"==" but then again, that would reduce the intuitiveness of it.  Personally
though, although I think it is important that the language be as intuitive as
practical, I also think that if a choice has to be made between intuitive and
trustworthy, being intuitive takes a back seat.

Okay, so let's look at this from another angle.   Perhaps it would be better to
have "is" should be returning "(is.equal && is.identical)" and "==" should be
returning "(is.equal || is.identical)" such that "is.equal" always returns true
if the contents or values represented are the same, and "is.identical" always
returns true is the identities are the same.  The other comparator operators
would still be handled by "opCmp()" and would work as they do now.  Okay, so
it's a compromise... but then again, what isn't?

Hmmm.... maybe start by adding something like "opCmp.identities()" and
"opCmp.values()" or "opCmp.contents()" and build on that?  This raises the
question.... is it too late?

TZ

 Kris wrote:


 http://www.digitalmars.com/d/operatoroverloading.html:


Apr 14 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:

Walter prefers to have the non-Sortable classes throw up at 
runtime.


 Perhaps we should drop all strong typing, have a variant type, and 
 just do all checks at runtime?

Hooray, it'll all be JavaScript then! :-) Seriously, I liked the "Comparable" interface myself - even if has the downside of requiring "Object" params ? But that's for another discussion - on opCmp() itself. --anders
Apr 14 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 For me it feels more natural to keep D the way it is, and 
 encourage a D
 idiom of "use 'is' to compare references".  To encourage that 
 idiom,
 perhaps the default Object.opEquals() should be dropped, so you 
 cannot
 compare objects with the == operator until you explicity define 
 it.

I've been deliberately avoiding suggesting that, but it would /really/ help the situation. Of course, it's in the same boat as opCmp() since Objects should not be comparable until the developer explicitly say's so, either. I wish you good luck in getting that changed.

I don't see there's any avoiding it, since it's the answer.
Apr 13 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
 "Kris" <fu bar.com> wrote in message news:d3k82r$2ktg$1 digitaldaemon.com...
 I've been deliberately avoiding suggesting that, but it would
 /really/ help
 the situation. Of course, it's in the same boat as opCmp() since
 Objects
 should not be comparable until the developer explicitly say's so,
 either. I
 wish you good luck in getting that changed.


"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d3kpif$304m$1 digitaldaemon.com...
 I don't see there's any avoiding it, since it's the answer.

There is one other possibility that comes to mind. An identity comparison could be performed "first" and cause "true" to be returned if the objects are one and the same, but rather than simply returning "false" otherwise, a second comparison could be done between the sizes of the objects being compared, and if they don't match, then return false. If the sizes do match, then the contents could be compared to see if they are the same, and of so, true would be returned. If not, false would be returned. It's a bit more involved, but it's not ambiguous. The result would be logically the same as comparing the contents, but much faster in cases where the objects either are identical, or are different sizes. A further speedup could be done by returning false durring the comparison of contents at the first sign of any difference. This would result in the worst case being that where the two objects are not the same object but do in fact have completely matching contents. Of course, this solution doesn't take into account the other comparator operators, but a simple conversion from boolean (bit) to numeric (int) could go something like... Compare identities and return 0 (equals) if identical. Compare sizes and scan for the first difference within the smaller size number of bytes. If no differences are found, return the sign of the difference between the sizes. Otherwise return the sign of the difference at that location where the first difference was found. This would allow all of the comparator operators to function predictably on any object with a default opCmp() function in an efficient manor that does not duplicate the functionality of the "is" operator. TZ
Apr 14 2005
parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <d3l51c$8m5$3 digitaldaemon.com>, TechnoZeus says...
 "Kris" <fu bar.com> wrote in message news:d3k82r$2ktg$1 digitaldaemon.com...
 I've been deliberately avoiding suggesting that, but it would
 /really/ help
 the situation. Of course, it's in the same boat as opCmp() since
 Objects
 should not be comparable until the developer explicitly say's so,
 either. I
 wish you good luck in getting that changed.


"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d3kpif$304m$1 digitaldaemon.com...
 I don't see there's any avoiding it, since it's the answer.

There is one other possibility that comes to mind. An identity comparison could be performed "first" and cause "true" to be returned if the objects are one and the same, but rather than simply returning "false" otherwise, a second comparison could be done between the sizes of the objects being compared, and if they don't match, then return false. If the sizes do match, then the contents could be compared to see if they are the same, and of so, true would be returned. If not, false would be returned. It's a bit more involved, but it's not ambiguous. The result would be logically the same as comparing the contents, but much faster in cases where the objects either are identical, or are different sizes. A further speedup could be done by returning false durring the comparison of contents at the first sign of any difference. This >would result in the worst case being that where the two objects are not the same object but do in fact have completely matching contents. Of course, this solution doesn't take into account the other comparator operators, but a simple conversion from boolean (bit) to numeric (int) could go something like... Compare identities and return 0 (equals) if identical. Compare sizes and scan for the first difference within the smaller size number of bytes. If no differences are found, return the sign of the difference between the sizes. Otherwise return the sign of the difference at that location where the first difference was found. This would allow all of the comparator operators to function predictably on any object with a default opCmp() function in an efficient manor that does not duplicate the functionality of the "is" operator. TZ

This would be misleading though. Let's say you have a class with a char[] and a doubly linked list. class foo { char[] a; SomeDLListClass foo; } The char[] is effectively /struct { char * data; int length; }/, which means that your 'bytewise comparison' would be an identity comparison, ie identical strings would not compare equal unless the address (char * data) of the text was the same. You could change it to 'follow' these objects, and compare string data. But the doubly linked list would not be followable, because it is a cyclical data structure. Following pointers would cause a cycle, and thus an infinite loop. You can fix this too. Follow pointers, keeping track of all the "marked" objects and comparing them. Compare the nonpointer regions of every referenced object bytewise, but compare the pointer regions by following pointers. Never check the same conceptual "pair" of objects twice, because you are tracking all the examined pointers. This would work - it defines a deep comparison for any pair of structures. But, it is also essentially the same algorithm a garbage collector uses, so its probably too heavy for a default deep compare. (But it might make a nice "deep dup" if such as thing was desired.) Now... the above deep compare can be made feasible again - each class has to define a method that does a deep compare, and knows which pointers to follow and which not to follow. ..... But we already have that; that's exactly how people usually write the opCmp() method. (Round and round we go....) I think this debate is simply an exercize in "I'm used to this" and "I'm used to that". For primitives, everyone uses == for primitive (intrinsic) equality. Java and C (mostly) use "==" for object identity. D and C++ use == for object value. (C doesn't have struct equality, but everyone uses pointers everywhere, so it's almost the same.) As for me, I like C++ and D's way, and D's way better; the only thing I would do is maybe create "isnt". It might be nice to have "floating" comparisons for objects, ie. objects that can act like NaN. Not to throw gasoline on this thread... Kevin
Apr 14 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Yes, if part of the "contents" of an item is in fact a pointer, then that
pointer would be part of the comparison for the default "==" as well as for
comparisons like ">" or "<" as I have proposed it... but such an item isn't
really equal unless all of it's contents are equal, including the pointer
portion.  As for "what you are used to" keep in mind that this would be only a
"default" built in comparison, which you could still override.  The idea is to
have "is" compare zero levels deep and "==" compare 1 level deep by default...
consistantly.

It's not a matter of who's used to what, in my opinion, so much as the
importance of making it so that what someone "becomes used to" in their early
experience with D can be trusted to work with other parts of D without having
to re-learn in opposition to what they have already learned in the same
language simply because they are dealing with a different kind of items.

TZ

"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:d3nl2b$2joc$1 digitaldaemon.com...
 In article <d3l51c$8m5$3 digitaldaemon.com>, TechnoZeus says...
 "Kris" <fu bar.com> wrote in message news:d3k82r$2ktg$1 digitaldaemon.com...
 I've been deliberately avoiding suggesting that, but it would
 /really/ help
 the situation. Of course, it's in the same boat as opCmp() since
 Objects
 should not be comparable until the developer explicitly say's so,
 either. I
 wish you good luck in getting that changed.


"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d3kpif$304m$1 digitaldaemon.com...
 I don't see there's any avoiding it, since it's the answer.

There is one other possibility that comes to mind. An identity comparison could be performed "first" and cause "true" to be returned if the objects are one and the same, but rather than simply returning "false" otherwise, a second comparison could be done between the sizes of the objects being compared, and if they don't match, then return false. If the sizes do match, then the contents could be compared to see if they are the same, and of so, true would be returned. If not, false would be returned. It's a bit more involved, but it's not ambiguous. The result would be logically the same as comparing the contents, but much faster in cases where the objects either are identical, or are different sizes. A further speedup could be done by returning false durring the comparison of contents at the first sign of any difference. This >would result in the worst case being that where the two objects are not the same object but do in fact have completely matching contents. Of course, this solution doesn't take into account the other comparator operators, but a simple conversion from boolean (bit) to numeric (int) could go something like... Compare identities and return 0 (equals) if identical. Compare sizes and scan for the first difference within the smaller size number of bytes. If no differences are found, return the sign of the difference between the sizes. Otherwise return the sign of the difference at that location where the first difference was found. This would allow all of the comparator operators to function predictably on any object with a default opCmp() function in an efficient manor that does not duplicate the functionality of the "is" operator. TZ

This would be misleading though. Let's say you have a class with a char[] and a doubly linked list. class foo { char[] a; SomeDLListClass foo; } The char[] is effectively /struct { char * data; int length; }/, which means that your 'bytewise comparison' would be an identity comparison, ie identical strings would not compare equal unless the address (char * data) of the text was the same. You could change it to 'follow' these objects, and compare string data. But the doubly linked list would not be followable, because it is a cyclical data structure. Following pointers would cause a cycle, and thus an infinite loop. You can fix this too. Follow pointers, keeping track of all the "marked" objects and comparing them. Compare the nonpointer regions of every referenced object bytewise, but compare the pointer regions by following pointers. Never check the same conceptual "pair" of objects twice, because you are tracking all the examined pointers. This would work - it defines a deep comparison for any pair of structures. But, it is also essentially the same algorithm a garbage collector uses, so its probably too heavy for a default deep compare. (But it might make a nice "deep dup" if such as thing was desired.) Now... the above deep compare can be made feasible again - each class has to define a method that does a deep compare, and knows which pointers to follow and which not to follow. ..... But we already have that; that's exactly how people usually write the opCmp() method. (Round and round we go....) I think this debate is simply an exercize in "I'm used to this" and "I'm used to that". For primitives, everyone uses == for primitive (intrinsic) equality. Java and C (mostly) use "==" for object identity. D and C++ use == for object value. (C doesn't have struct equality, but everyone uses pointers everywhere, so it's almost the same.) As for me, I like C++ and D's way, and D's way better; the only thing I would do is maybe create "isnt". It might be nice to have "floating" comparisons for objects, ie. objects that can act like NaN. Not to throw gasoline on this thread... Kevin

Apr 15 2005
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <d3k3tl$2hmq$1 digitaldaemon.com>, Kris says...
I think this just highlights the difficulties surrounding clear
communication in an NG environment. There's language barriers, proximity-cue
barriers, social and educational barriers, along with barriers of purpose
and intent. The fact that not each and every thread is filled with
antagonism can be surprising to some, but many of them are. I find it to be
an increasingly painful and fruitless exercise to both read and initiate
threads here; even those relating my trivial experiences with D (such as
this one). Further, attempting to keep a thread on track is truly becoming
an impossible task (hence, the request for a summary).

I can't imagine I'm the only one who feels this way ~ which prompts a
question: what, if anything, can be done about it?

Good question. I only read moderated C++ newsgroups for this very reason. But moderation means moderators which I suspect is unlikely here. I also find it increasingly difficult to separate signal from noise on this NG. I tried skipping threads once they started degrading but it wasn't uncommon for me to read something interesting a few days later that references a post I'd skipped. It might be bad to say so, but the best approach I've found is to just filter by author. That might be restricting myself to a subset of folks with a similar background or experience, but I simply don't have the time to wade through reams of antagonism for the few gems that lurk therein. Perhaps it would be sufficient to offer a few more newsgroups to separate interests: language, library, advocacy, etc? Mailing lists work as well, but I can understand the desire to avoid such exclusivity. Sean
Apr 13 2005
parent reply brad domain.invalid writes:
Sean Kelly wrote:
 In article <d3k3tl$2hmq$1 digitaldaemon.com>, Kris says...
 
I think this just highlights the difficulties surrounding clear
communication in an NG environment. There's language barriers, proximity-cue
barriers, social and educational barriers, along with barriers of purpose
and intent. The fact that not each and every thread is filled with
antagonism can be surprising to some, but many of them are. I find it to be
an increasingly painful and fruitless exercise to both read and initiate
threads here; even those relating my trivial experiences with D (such as
this one). Further, attempting to keep a thread on track is truly becoming
an impossible task (hence, the request for a summary).

I can't imagine I'm the only one who feels this way ~ which prompts a
question: what, if anything, can be done about it?


<>Snip<> I've also noticed it physically tiring reading threads recently. People on this NG tend (IMHO) to be overly verbose, overly sensitive, and overly abrasive. Anyone else notice that Walter doesn't get involved in these discussions anymore? Perhaps he is tired also. I would prefer shorter, more on topic messages - a 300 word max perhaps? :) Brad
Apr 13 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Newsgroup threads do tend to drift.  It's a fact that even moderation and
careful attention to staying on topic can't eliminate.  This point comming up
in this thread is a good example.  If your newsgroup viewer can arrange posts
according to their sub-thread hierarchy (which post someone responded to) you
can choose to simply skip branches that go off in a direction that you don't
care to follow.

As for keeping the posts short, I personally find it harder to communicate
clearly in few words... but I do like the idea of having a sort of "to the
point" newsgroup that would only allow posts of a certain number of characters
or less... in order to make sure that nothing in that newsgroup would take long
to read, and people who post there would have to choose carefully what is most
worth squeezing into the available space.

Maybe Walter would be able to find time to follow along in a group like that. 
In fact, when he first asked me to post some of my thoughts in here, I
expressed that same concern to him... following newsgroups and lacking time
generally don't go well together.

TZ

<brad domain.invalid> wrote in message news:d3k6v1$2k09$1 digitaldaemon.com...
 Sean Kelly wrote:
 In article <d3k3tl$2hmq$1 digitaldaemon.com>, Kris says...

I think this just highlights the difficulties surrounding clear
communication in an NG environment. There's language barriers, proximity-cue
barriers, social and educational barriers, along with barriers of purpose
and intent. The fact that not each and every thread is filled with
antagonism can be surprising to some, but many of them are. I find it to be
an increasingly painful and fruitless exercise to both read and initiate
threads here; even those relating my trivial experiences with D (such as
this one). Further, attempting to keep a thread on track is truly becoming
an impossible task (hence, the request for a summary).

I can't imagine I'm the only one who feels this way ~ which prompts a
question: what, if anything, can be done about it?


<>Snip<> I've also noticed it physically tiring reading threads recently. People on this NG tend (IMHO) to be overly verbose, overly sensitive, and overly abrasive. Anyone else notice that Walter doesn't get involved in these discussions anymore? Perhaps he is tired also. I would prefer shorter, more on topic messages - a 300 word max perhaps? :) Brad

Apr 14 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kris wrote:

 The topic is /not/ a campaign to change the language. I'll repeat that: it
 is NOT a campaign, since it's been shown such causes, however well
 intentioned, and/or well supported, are naught but exercises in futility.

It does seem to be a campaign about preferring how '==' is done in Java? (even if doing it not by a language change, but switching '==' for 'is')
 D supports the notions of equality and identity. Equality can be thought of
 as a test to see if two individual entities have equivalent 'value', whereas
 identity can be thought of as a test whether two entities are, in fact, one
 and the same. Identity is rarely discussed for primitive types (int, long,
 bool, etc) since they are typically dealt with via equality. However,
 pointers to primitive types are covered by the identity umbrella.

Pointers are being compared as integers, actually. Thus: equality ? But I agree, it's pretty confusing in D that has both kinds (p/r).
 Firstly: having two distinct operators to represent identity is surely
 redundant. I understand Walter has noted problems with misinterpretation
 between '==' and '===', particularly with certain printer fonts, and there's
 been past suggestions made to remove that token. There has also been ongoing
 suggestions to add an inverse companion for 'is' ... many such candidates
 have been put forward, such as 'isnot', 'aint', and 'is not'. I ran into a
 situation which tended to amplify a need for such a companion, which is why
 it's mentioned here. I'll reiterate said situation further on.

Both '===' and 'is' map to TOKidentity, so it is the SAME thing. I'm assuming that both '!==' and 'isnt' would be TOKnotidentity. (I'm talking about the actual tokens used by the DMD lexer, here)
 Secondly: the terms 'identity' and 'equality' are applied in D with
 significant overlap between the two, and it can be hard to get these terms
 straight when they are interchanged. For example, the D 'is' identity
 operator becomes an equality operator when used with primitive types. The D
 '==' equality operator morphs into an identity operator when used with
 Objects that don't override the default opEquals() method.

The same definition of "equals()" is being implemented in java.lang.Object. It doesn't mean the operator morphs, IMHO. However, the identity operator does "morph" with primitives.
 Because of this confusing duality I'll, instead, use the terms "shallow
 equality" and "deep equality" for the rest of this post. Shallow equality
 does a simple comparison of primitive hardware types, including byte, short,
 long, float, double, pointers/references, etc. Deep equality performs
 whatever test are necessary to determine whether one entity is equivalent to
 another. In extreme cases, the latter might result in a visit to the
 internet, or to a database. In other cases, the equivalent of a C memcmp()
 might be performed.

That's OK, "shallow equality" is normally used as a synonym for identity and likewise "deep equality" is used for equality. As you say above: identity/shallow is seldom used with primitive types, it's normally called equality (which would be "deep" here!) Without the drama, the deep equality normally calls opEquals. (or does the memcmp, for structs/arrays/strings "primitives")
 Thirdly: D uses the '==' operator in a manner that conflicts with
 traditional/habitual use (particularly for C & Java users). That is, the
 operator is traditionally used for shallow equality, whereas D purportedly
 uses it for deep equality. This can only breed confusion, in that those new
 to D will invariably apply '==' where they should not. Indeed, habitual use
 of '==' for shallow comparison is handled in D via the 'is' operator
 instead.

How would an operator that only affects Objects cause problems for C users, that doesn't have any objects ? It's only a problem if the D references are regarded as being the *same* as C pointers ? If they are instead regarded as types or something, they work the same as the primitives do - when it comes to doing equality tests ? i.e. an Int wrapper class would behave similiar to an int primitive The pointers work the same way in D as in C: integer comparison.
 Summary point 1: newcomers to D should likely use 'is' instead of '==',
 since those two are "equivalent" from a traditional standpoint (both perform
 a shallow test).

We disagree in terminology here. Primitive types should use '==', which I instead would classify as doing a "deep equality" test. To me, a shallow equality test would be more like comparing &i and &j for the fictional case of "int i,j;". But again, one does not normally talk about the identity of primitives ? (even if it's fully OK for the 'is' operator to fall back on it)
 Fourthly: the duality of the D '==' operator can lead to unexpected
 circumstance. For example, the default behavior of '==' is actually a
 shallow test for primitives, a deep test for arrays (such as char[]), a
 shallow test for Objects (via the default opEquals), a deep test for structs
 instances, and a shallow test for struct pointers. Those who blindly call
 this 'equality' should question their faith.

Pointers are an exception, that is true. The rest is terminology.
 The confusion here is amplified by the conflict with traditional use of
 '=='. Suppose I, through force of habit, have applied '==' throughout my
 code and get it debugged and operating correctly. Let's further suppose some
 maintenance engineer comes along and adds an opEquals() to some existing
 class, for whatever purpose. Suddenly my code breaks. Why? The original code
 was operating using the default shallow comparison performed by Object and
 now that has been changed, by the maintenance engineer, to be some kind of
 deep comparison. One can argue the original developer (me) should have been
 explicit about using a shallow test in the first place. Indeed, this is
 true. Which is partly why Summary Point 1 is worth considering seriously.
 However, D does not currently lend itself to avoiding this sort of thing. In
 fact, D seems to embrace exactly this bug by making the default behaviour of
 '==' be of the shallow variety. A combination of changing tradition, yet not
 really, can actually increase maintenance costs.

But not defining the opEquals, you are saying that the state of your objects does not make them into equal (i.e. that they are all unique) If the "maintenance engineer" redefines this into adding state, say by comparing the name of your class or whatever - he changes this... And it breaks, since now all the objects with the same name are equal ? (and again, we seem to be having a disagreement on Summary Point 1)
 Summary point 2: The default shallow test for '==' tends to exaggerate the
 potential for confusion. Not only because it does a role-defying shallow-
 rather than deep- comparison, but because it can lead directly to fragile
 maintenance builds via its changing behaviour.

I'm not sure how this is a change from Java... Both have the same implementation of equality for the top-level Object (i.e identity) As someone else posted in this thread: it's somewhat confusing at first, but it is also the only sane default that Object could have ? [...snipped out the original post...]
 As you can hopefully see, the illustrative example performs shallow tesing
 for the overwhelming majority of cases. Deep testing is used for a meager
 1.25%. To put this into perspective, there are almost 8000 equivalence tests
 made within that body of code.

Q: Do you include equality between primitives into that number for "shallow" ? That would explain their high number, at least to me. And how many of those are compares with null ? Those numbers would be interesting to know (you said the translation was machine done)
 Given all that, this thread has noted D would become backward-compatible if
 the functionality of '==' and 'is' were to be role-reversed. That is, if
 '==' were to fully retain its shallow heritage (like 'is' does), newcomers
 would not have to even consider switching to using 'is' for the majority
 case. This would naturally eliminate the concern over both Summary Points 1
 & 2 above. Of course, there's zero expectation that would ever happen to
 D -- this role reversal notion is pure speculation, and exists simply a
 means of clarifying the current situation.

I think the only backwards compatibility involved here is with Java... But that's mostly because our definitions differ, including SP 1 and 2.
 I hope this summarizes the thread content thus far. I haven't touched on the
 subject brought up by Brad ("how to bridge the gap between user defined
 types and built in types?"), which could use some exploration.

Thanks for summarizing this post up. Now I know what our difference is. It seems to boil down to whether an Object is a regular type (like a "struct" is), or if it's a hidden pointer type (like a "struct*" is) And that's also why I said earlier that you wanted D to "treat the references as pointers". Since that is what Java ends up doing ? (that is: when talking about the '==' operator, nothing else here) I like C, and I like Java. And, for the most part, I like D *a lot*. And I would not want any of them to change their '==' operators... (well, it's just a wee bit too late for Java to introduce '===' now) As for the name of the tokens: if '===' and '!==' are causing confusion and are hard to print, then they can be replaced by 'is' and 'isnt' ? I would prefer if the old ones were left in, but can live without them. But for what they do, *I* find it to be pretty straight-forward in D: == , Equality Expression, "deep equality" (primitive,memcmp,opEquals) != === , Identity Expression, "shallow equality" (pointer/reference) !== And it doesn't seem much to argue about? Like you said all along, it's not like Walter is going to change the D language on this point... As for introducing "isnt", it's a trivial patch for an Open Source D compiler. But it would be sad to have to translate it to '!==' for DMD ? --anders PS. Speaking of barriers, this timezone and I now bids you good night.
Apr 13 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Anders F Bjrklund" <afb algonet.se> wrote in message 
news:d3k7jp$2jg7$1 digitaldaemon.com...
 Kris wrote:

 The topic is /not/ a campaign to change the language. I'll repeat 
 that: it
 is NOT a campaign, since it's been shown such causes, however 
 well
 intentioned, and/or well supported, are naught but exercises in 
 futility.

It does seem to be a campaign about preferring how '==' is done in Java? (even if doing it not by a language change, but switching '==' for 'is')

I don't think that's valid. Kris has pointed out a very disturbing design flaw in the syntax of the language, and has suggested _what he sees_ as the most pragmatic solution, based on his experience I happen to disagree with his solution, and favour a full and proper addressing of the flaw, but I agree with his main thesis nonetheless.
 Secondly: the terms 'identity' and 'equality' are applied in D 
 with
 significant overlap between the two, and it can be hard to get 
 these terms
 straight when they are interchanged. For example, the D 'is' 
 identity
 operator becomes an equality operator when used with primitive 
 types. The D
 '==' equality operator morphs into an identity operator when used 
 with
 Objects that don't override the default opEquals() method.

The same definition of "equals()" is being implemented in java.lang.Object. It doesn't mean the operator morphs, IMHO.

But Java does not allow operator overloading, so it cannot come up. The only problem with Java is, as you say "the identity operator does "morph" with primitives".
 Summary point 2: The default shallow test for '==' tends to 
 exaggerate the
 potential for confusion. Not only because it does a role-defying 
 shallow-
 rather than deep- comparison, but because it can lead directly to 
 fragile
 maintenance builds via its changing behaviour.

I'm not sure how this is a change from Java... Both have the same implementation of equality for the top-level Object (i.e identity)

opEquals() again. Or am I missing something in your point?
Apr 13 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:

The same definition of "equals()" is being implemented in 
java.lang.Object. It doesn't mean the operator morphs, IMHO.

But Java does not allow operator overloading, so it cannot come up.

I'm not sure I follow ? If I call equals() on two Java objects - both using the default implementation of java.lang.Object.equals, I get identity. To get something else, equals() must be overridden.
 The only problem with Java is, as you say "the identity operator 
 does "morph" with primitives".

Java does not have the '===' identity operator, so that "problem" is all D's. It's pretty common to have such an identity silently fall back on equality, though ? Just as the default equality being identity ?
I'm not sure how this is a change from Java... Both have the same
implementation of equality for the top-level Object (i.e identity)

opEquals() again. Or am I missing something in your point?

Not at all. D's opEquals and Java's equals are pretty much equivalent. (including the default implementation of each, which calls on identity) Will go ahead and read those CUJ articles and the longer responses now. --anders
Apr 13 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
I think we're slipping past each other's understandings here. Let me 
try and get back on your rail, or you on mine. :-)

Basically, I understood you to have said that D and Java had 
identical issues wrt opEquals().

I was pointing out that, because D supports operator overloading, 
and specifically of == to translate to calls to opEquals() on class 
types, D suffers from the same problem as C#, which is that robust 
client code can be undermined by (non-compile-breaking) changes to a 
class's interface.

Thus, Java code saying obj1 == obj2 will always mean compare 
identity. With D, however, it can mean compare identity, unless and 
until the type of obj1/obj2 is overridden with opEquals().



"Anders F Bjrklund" <afb algonet.se> wrote in message 
news:d3l3iu$6ov$1 digitaldaemon.com...
 Matthew wrote:

The same definition of "equals()" is being implemented in 
java.lang.Object. It doesn't mean the operator morphs, IMHO.

But Java does not allow operator overloading, so it cannot come up.

I'm not sure I follow ? If I call equals() on two Java objects - both using the default implementation of java.lang.Object.equals, I get identity. To get something else, equals() must be overridden.
 The only problem with Java is, as you say "the identity operator 
 does "morph" with primitives".

Java does not have the '===' identity operator, so that "problem" is all D's. It's pretty common to have such an identity silently fall back on equality, though ? Just as the default equality being identity ?
I'm not sure how this is a change from Java... Both have the same
implementation of equality for the top-level Object (i.e 
identity)

opEquals() again. Or am I missing something in your point?

Not at all. D's opEquals and Java's equals are pretty much equivalent. (including the default implementation of each, which calls on identity) Will go ahead and read those CUJ articles and the longer responses now. --anders

Apr 13 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:

 I think we're slipping past each other's understandings here. Let me 
 try and get back on your rail, or you on mine. :-)
 
 Basically, I understood you to have said that D and Java had 
 identical issues wrt opEquals().

That was kinda obvious from reading article http://www.cuj.com/documents/cuj0310wilson/, but I'm afraid I can't use that material here. Anyway, it's understood here too.
 I was pointing out that, because D supports operator overloading, 
 and specifically of == to translate to calls to opEquals() on class 
 types, D suffers from the same problem as C#, which is that robust 
 client code can be undermined by (non-compile-breaking) changes to a 
 class's interface.

Assuming that you do use equals() to check two objects, you have the same problem there. And if you don't, well: couldn't you just check for identity in D too, then ? It seems we differ in our view in the importance of opEquals. (to me, it's an important part of the object / interface design) But agree that Java decided to "flip" operators for reference types.
 Thus, Java code saying obj1 == obj2 will always mean compare 
 identity. With D, however, it can mean compare identity, unless and 
 until the type of obj1/obj2 is overridden with opEquals().

It's just semantics, and choice of "operators". (or lack of, in Java) In D code, saying obj1 === obj2 will always mean compare identity. With Java, when you use obj1.equals(obj2) it can mean compare identity, unless and until the default implementation of equals is overridden. Potato, Potatoh. --anders PS. It *would* be simpler if "null == this" did not segfault, as discussed in that other thread. On the other hand, so does "null.equals(this)" ? I haven't isolated all cases *when* "this == null" segv, but it does... (in Java, equals(null) is defined to return false. Part of the contract)
Apr 14 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Anders F Bjrklund" <afb algonet.se> wrote in message 
news:d3l5e5$8h8$1 digitaldaemon.com...
 I was pointing out that, because D supports operator overloading, 
 and specifically of == to translate to calls to opEquals() on 
 class types, D suffers from the same problem as C#, which is that 
 robust client code can be undermined by (non-compile-breaking) 
 changes to a class's interface.

Assuming that you do use equals() to check two objects, you have the same problem there.

Indeed.
 It seems we differ in our view in the importance of opEquals.
 (to me, it's an important part of the object / interface design)
 But agree that Java decided to "flip" operators for reference 
 types.

I don't like fat base classes, and, IMO, Object qualifies as such. The damnable bloated corpulent beast. One more waffer .... :-) Others naturally see it differently.
 In D code, saying obj1 === obj2 will always mean compare identity.
 With Java, when you use obj1.equals(obj2) it can mean compare 
 identity, unless and until the default implementation of equals is 
 overridden.

 Potato, Potatoh.

No, I think they are materially different. I think that, unless there is a move for a fix, diligent D instructors will have to recommend that people use only 'is' and opEquals(), and even that won't be perfect. :-( Kercrack! What was that? Oh, someone just shot themselves in the foot again. ;)
 --anders

 PS.
 It *would* be simpler if "null == this" did not segfault, as 
 discussed
 in that other thread. On the other hand, so does 
 "null.equals(this)" ?
 I haven't isolated all cases *when* "this == null" segv, but it 
 does...
 (in Java, equals(null) is defined to return false. Part of the 
 contract)

Agreed. And as for the platform-specific differences ... <g>
Apr 14 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:

 It *would* be simpler if "null == this" did not segfault, as 
 discussed in that other thread. On the other hand, so does 
 "null.equals(this)" ? I haven't isolated all cases *when* "this ==
 null" segv, but it does... (in Java, equals(null) is defined to
 return false. Part of the contract) >

Agreed. And as for the platform-specific differences ... <g>

I think it does segfault on Windows too ? And that the Windows runtime Exception is just Walter catching this and wrapping it ? I don't run Windows on a regular basis, but it does sound slow. ie. if (object !== null) do_stuff(object); vs. try { doStuff(object); } catch (NullError ex) {} Not sure which one is the worst to clean up after... ? (as GDB does point to the correct source line on *null) --anders
Apr 14 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Instead of talking about "D on windows" and "D on <unix, or linux or 
whatever>", could you be more specific in the future.

Like "DMD" and "GDC"? (If that's what you mean.)

And "DMD on windows" and "DMD on <unix, or linux or whatever>", when 
that's what you mean.

Anders F Bjrklund wrote:
 Matthew wrote:
 
 It *would* be simpler if "null == this" did not segfault, as 
 discussed in that other thread. On the other hand, so does 
 "null.equals(this)" ? I haven't isolated all cases *when* "this ==
 null" segv, but it does... (in Java, equals(null) is defined to
 return false. Part of the contract) >

Agreed. And as for the platform-specific differences ... <g>

I think it does segfault on Windows too ? And that the Windows runtime Exception is just Walter catching this and wrapping it ? I don't run Windows on a regular basis, but it does sound slow. ie. if (object !== null) do_stuff(object); vs. try { doStuff(object); } catch (NullError ex) {} Not sure which one is the worst to clean up after... ? (as GDB does point to the correct source line on *null) --anders

Apr 14 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 I think it does segfault on Windows too ? And that the Windows
 runtime Exception is just Walter catching this and wrapping it ?


 Instead of talking about "D on windows" and "D on <unix, or linux or 
 whatever>", could you be more specific in the future.

Will do, in this particular case I was talking about DMD however: Dereferencing null causes some kind of hardware action on all, be it called Access Violation, Segmentation Fault or Bus Error. And it's currently being caught and handled only under Windows, although there was a patch circulating to add it to Linux too ? With GDC, it is not being caught on any platform yet (AFAIK). --anders
Apr 14 2005
prev sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
right, but at the same time this is true of any function, and an operator is
afterall simply a function with an alternative syntax.

However, here is a good case for implicit importing.  Consider for example, if
it was decided somewhere along the way that then internal obj module should be
replaced by a new module named dobjects which handled such things as the opCmp
function differently.  The new module would be made internal, and it should
still be possible to explicitly import the older module to override it's
functionality.

Programs which call an explicit import to obj would therefore not run the risk
of getting broken when the new dobjects module supercedes it as an internal
module, but would also not benefit from the improvements made. Programs which
do not call an explicit import would benefit from the replacement module, but
would also run the risk of being broken by one or more of the changes.

Likewise, if a non-internal module isn't explicitly imported but is still used,
then it's functionality could be upgraded either through an upgrade to that
module, or by making a new and improved module the new default module for the
same functionality, but if a program explicitly imports a module, then only a
direct change to that module would effect it.

TZ

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3l4ab$7dm$1 digitaldaemon.com...
 I think we're slipping past each other's understandings here. Let me
 try and get back on your rail, or you on mine. :-)

 Basically, I understood you to have said that D and Java had
 identical issues wrt opEquals().

 I was pointing out that, because D supports operator overloading,
 and specifically of == to translate to calls to opEquals() on class
 types, D suffers from the same problem as C#, which is that robust
 client code can be undermined by (non-compile-breaking) changes to a
 class's interface.

 Thus, Java code saying obj1 == obj2 will always mean compare
 identity. With D, however, it can mean compare identity, unless and
 until the type of obj1/obj2 is overridden with opEquals().



 "Anders F Bjrklund" <afb algonet.se> wrote in message
 news:d3l3iu$6ov$1 digitaldaemon.com...
 Matthew wrote:

The same definition of "equals()" is being implemented in
java.lang.Object. It doesn't mean the operator morphs, IMHO.

But Java does not allow operator overloading, so it cannot come up.

I'm not sure I follow ? If I call equals() on two Java objects - both using the default implementation of java.lang.Object.equals, I get identity. To get something else, equals() must be overridden.
 The only problem with Java is, as you say "the identity operator
 does "morph" with primitives".

Java does not have the '===' identity operator, so that "problem" is all D's. It's pretty common to have such an identity silently fall back on equality, though ? Just as the default equality being identity ?
I'm not sure how this is a change from Java... Both have the same
implementation of equality for the top-level Object (i.e
identity)

opEquals() again. Or am I missing something in your point?

Not at all. D's opEquals and Java's equals are pretty much equivalent. (including the default implementation of each, which calls on identity) Will go ahead and read those CUJ articles and the longer responses now. --anders


Apr 14 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 Secondly: the terms 'identity' and 'equality' are applied in D 
 with
 significant overlap between the two, and it can be hard to get 
 these terms
 straight when they are interchanged. For example, the D 'is' 
 identity
 operator becomes an equality operator when used with primitive 
 types.

Ok, I didn't realise that. That's not good.
 The D
 '==' equality operator morphs into an identity operator when used 
 with
 Objects that don't override the default opEquals() method.

Yes, I knew that. It's been a longstanding source of criticism from many sources, including me.
 Because of this confusing duality I'll, instead, use the terms 
 "shallow
 equality" and "deep equality" for the rest of this post.

Not sure that's helpful. I'll have to be translating 'em back to identity and equality while reading. ;/
 Shallow equality
 does a simple comparison of primitive hardware types, including 
 byte, short,
 long, float, double, pointers/references, etc. Deep equality 
 performs
 whatever test are necessary to determine whether one entity is 
 equivalent to
 another. In extreme cases, the latter might result in a visit to 
 the
 internet, or to a database. In other cases, the equivalent of a C 
 memcmp()
 might be performed.

I'm pretty dubious about these definitions, but maybe it clears up further on. Reading on ...
 Thirdly: D uses the '==' operator in a manner that conflicts with
 traditional/habitual use (particularly for C & Java users). That 
 is, the
 operator is traditionally used for shallow equality, whereas D 
 purportedly
 uses it for deep equality. This can only breed confusion, in that 
 those new
 to D will invariably apply '==' where they should not. Indeed, 
 habitual use
 of '==' for shallow comparison is handled in D via the 'is' 
 operator
 instead.

I disagree with this, no doubt because C++/Python/Ruby do not do this.
 Summary point 1: newcomers to D should likely use 'is' instead of 
 '==',
 since those two are "equivalent" from a traditional standpoint 
 (both perform
 a shallow test).

Given what you say about 'is' being applicable to built-in types, that's arguable, I guess, but it seems like two wrongs not making a right to me.
 Fourthly: the duality of the D '==' operator can lead to 
 unexpected
 circumstance. For example, the default behavior of '==' is 
 actually a
 shallow test for primitives, a deep test for arrays (such as 
 char[]), a
 shallow test for Objects (via the default opEquals), a deep test 
 for structs
 instances, and a shallow test for struct pointers. Those who 
 blindly call
 this 'equality' should question their faith.

Agreed
 The confusion here is amplified by the conflict with traditional 
 use of
 '=='. Suppose I, through force of habit, have applied '==' 
 throughout my
 code and get it debugged and operating correctly. Let's further 
 suppose some
 maintenance engineer comes along and adds an opEquals() to some 
 existing
 class, for whatever purpose. Suddenly my code breaks. Why? The 
 original code
 was operating using the default shallow comparison performed by 
 Object and
 now that has been changed, by the maintenance engineer, to be some 
 kind of
 deep comparison. One can argue the original developer (me) should 
 have been
 explicit about using a shallow test in the first place. Indeed, 
 this is
 true. Which is partly why Summary Point 1 is worth considering 
 seriously.
 However, D does not currently lend itself to avoiding this sort of 
 thing. In
 fact, D seems to embrace exactly this bug by making the default 
 behaviour of
 '==' be of the shallow variety. A combination of changing 
 tradition, yet not
 really, can actually increase maintenance costs.

Strongly agreed. A very powerful point. Another good argument for the removal of opEquals() from Object. Note: I made some of these same points in "Identity and Equality: Syntax and Semantics" (CUJ, Oct 2003; http://www.cuj.com/articles/2003/0310/) and "Identity and Equality in .NET" (DDJ, June 2004; http://www.ddj.com/documents/ddj0406k/), though I discussed the dangerous behaviour you've outlined in terms of C#/.NET. If I may be so crass as to quote myself, it seems I said something that at least two of us would agree with: "As I said above, C# provides the facility to overload the == and != operators on a per-class basis. (In fact, it mandates that if you overload == then you must overload !=, and vice versa, which is probably a good idea.) However, this is an accident waiting to happen. If your class does not overload these operators, and does not inherit from one that does, then using == will be translated to an identity check, i.e. equivalent to a call to Object.ReferenceEquals(). However, if your class, or one of its ancestors, does overload these operators, use of == will result in a call to that overloaded operator which, as we see below, will be implemented as a call to the instance/non-static Equals() method for that class. (C# also requires you to provide overloads of Object.Equals() and Object.GetHashCode() if you overload == and !=. Again this is probably a good idea, though it does make writing simple test programs for article research somewhat tedious.) I don't know if I'm the only one who thinks so, but this situation seems crazy. Testing for identity and equality are completely different things conceptually [5]. To not know which you are getting when you type in == is nonsensical. Having to resort to the documentation (should there be any) or the assembler on a per-class basis to elicit the semantics of basic syntactic elements doesn't stand up. Even worse, the class(es) you are working with may be redefined after your first version of code is written and working, resulting in both semantic and probably performance changes to your code without you having altered a character. C# aficionados may counter that C++ (which is, perhaps obviously, my language of choice) provides the same dangers. But this does not really hold water. In C++, the semantics of == are only changed from meaning a test of equality by incompetent or malicious action. In C# they can be shifted from identity to equality, or vice versa, by the informed action of experienced developers. (Of course, the .NET version-locking mechanisms are designed in part to prevent such potentially destructive changes in semantics from affecting client code, but that can only work when they are used. During development, or when using publicly available binaries/source, it is impractical/undesirable to operate these mechanisms, hence the risk is real.) [5] Of course, equality testing is kind of a superset of identity testing in that when two object references refer to the same object it is axiomatic that the objects so referenced are equal."
 Summary point 2: The default shallow test for '==' tends to 
 exaggerate the
 potential for confusion. Not only because it does a role-defying 
 shallow-
 rather than deep- comparison, but because it can lead directly to 
 fragile
 maintenance builds via its changing behaviour.

Totally lost me on that one. Is it covered below? If not, will you rephrase?
 Let's move onto the scenario painted by the original post. I'm 
 going to cut
 and paste a large chunk of the original here, because the points 
 are, IMO,
 still valid. Additionally, it's worth getting back to the point, 
 since this
 thread seems to have fallen into the grasp of ideaologists:


 <quote>

 Food for thought:

 Java is explicit about the distinction between equality and 
 identity, just
 as D is. However, where D uses '==' as an equivalence operator, 
 Java uses an
 equals() method. Where D uses (triple) '===' and 'is' for identity 
 purposes,
 Java uses the traditional double '==' instead.

 So, what's that got to do with the price of tea in China?

 While porting 125,000 lines of Java to D, and an interesting thing 
 happened.
 You'll perhaps not be surprised to hear Java identity style tests 
 are far
 more prevalent than equivalence tests,

Well, yes, I am. Perhaps that's because I don't do much Java?
 but you may be surprised to know that
 the former comprised 98.75% of all explicit tests within those 
 125,000
 lines. To embellish, equals() was applied just 1.25% of the time.

Very surprised indeed. Is it plausible that this is skewed by application specificity? What is that code base doing? <snip>
 This has some notable ramifications; of which I'll attempt to be 
 brief:

 1) The converted Java code now has reams of  'is' statements 
 throughout the
 code, which makes it look 'interesting', to say the least. Quite 
 nice,
 actually; and eminantly readable, even vaguely amusing at times. 
 The '!=='
 instances look suitably alien by comparison. This amplifies the 
 need for a
 sibling for the word 'is', such as the oft proposes 'not' or the 
 colloquial
 'aint'.

Sure. No brainer. 'is' and '!==' are odd little bedfellows.
 BTW, using 'is' generates optimal code for that 98.75% of tests 
 within that
 large body of code. That is absolutely not the case when applying 
 the
 traditional operators instead. Look at the emitted codegen.

 2) Anyone used to C or Java will habitually use the traditional 
 '==' and
 '!=' all over their D code. This is actually the *wrong* thing to 
 do, since
 those operators in D are for equivalence testing instead of 
 identity
 testing.

Do you mean "since those operators in D are [sometimes, depending on the types of the comparands, used ]for equivalence testing instead of identity testing."? If not, what do you mean?
 This has implications for both performance and for "expectations 
 of
 behaviour". For example, the subsequent addition of an opEquals() 
 to some
 aggregate may break the overall system in all manner of subtle and
 unexpected ways, where the original developer used '==' by force 
 of habit.

Agree with the level of concern you're expressing with this. This all stems from the use of references without pointer syntax,
 3) Just as importantly, this highlights a significant divergence 
 of D from C
 and, IMO, in a rather fundamental manner. Think about this: you 
 should
 actually be using 'is' most of the time instead of (twin) '=='. 
 How many of
 you even use 'is' at all?

Essentially you're saying that use of == for class types, or in generic code that may be applied to class types, is subject to hidden and potentially destructive change. This was the crux of my article wrt C#, so I completely agree with its severity. (I'm somewhat bemused/baffled why I didn't see that it also applies to D, and quite chagrined now to see that it does. Huge blunder.)
 One might perhaps argue the numbers above are artificially 
 inflated since
 many of those test are applied to native types rather than to 
 classes and
 structs ~ that may be true. But we're talking about something 
 that's already
 well-developed as a habit in the community (the double '==') and 
 we're
 talking about consistency in the majority case.

It's irrelevant whether it's likely to happen 90% of the time or 0.9% of the time. It's a major design blunder in either case.
 </quote>

<snip>
 Given all that, this thread has noted D would become 
 backward-compatible if
 the functionality of '==' and 'is' were to be role-reversed. That 
 is, if
 '==' were to fully retain its shallow heritage (like 'is' does), 
 newcomers
 would not have to even consider switching to using 'is' for the 
 majority
 case. This would naturally eliminate the concern over both Summary 
 Points 1
 & 2 above. Of course, there's zero expectation that would ever 
 happen to
 D -- this role reversal notion is pure speculation, and exists 
 simply a
 means of clarifying the current situation.

I don't buy that. Or, rather, I don't think it's an attractive feature/change. Not sure what the answer is, as yet, but I am 100% with you that there's a problem that needs a solution.
 I hope this summarizes the thread content thus far. I haven't 
 touched on the
 subject brought up by Brad ("how to bridge the gap between user 
 defined
 types and built in types?"), which could use some exploration.

Also needs a full solution, IMO
 - Kris

 -------------------

 A few personal notes.

 This thread was started as an observation. A reflection on 
 interaction with
 D. With a tip of the hat to GW, I'll point out again that this is 
 not about
 making a case for change in D. And it is most certainly nothing to 
 do with
 blind ideological perspective, as one individual appears to have 
 showered
 upon it.

 I think this just highlights the difficulties surrounding clear
 communication in an NG environment. There's language barriers, 
 proximity-cue
 barriers, social and educational barriers, along with barriers of 
 purpose
 and intent. The fact that not each and every thread is filled with
 antagonism can be surprising to some, but many of them are. I find 
 it to be
 an increasingly painful and fruitless exercise to both read and 
 initiate
 threads here; even those relating my trivial experiences with D 
 (such as
 this one). Further, attempting to keep a thread on track is truly 
 becoming
 an impossible task (hence, the request for a summary).

 I can't imagine I'm the only one who feels this way ~ which 
 prompts a
 question: what, if anything, can be done about it?

Speaking for myself, I've certainly become far grumpier of late. It seems I take a break due to some pointless/bad experience, and foreswear any such future behaviour on my part or being sucked into fatuous debates by others, and yet within a couple of days of 'coming back' it's happening again. Needless to say, I find this truly uncharacteristic - honest! <G> - behaviour of mine both appalling and intriguing. (I often think how embarrassed I'll be if my sons become software engineers and go and look up some of their cranky old fart of a father's semi-lucid ranting and pompous condescension.) Why am I losing my temper? And why do I keep transgressing my otherwise golden rule of "Once the shouting starts, it's time to quit that job/friendship/debate/ ... /ng and remove the pain for all parties" ? Knowing that I'm running the risk of being called flamer again, I submit that the two answers are the two sides of the same coin. I keep coming back because I believe D has *great* promise, and I am increasingly (and evidently!) frustrated by D because (i) nothing seems to change, and (ii) the "good enough" attitude is neither something I can relate to nor something that I think is going to fulfil the promise. To be frank, I think that, apart from slices, the _only_ thing about D that is currently great is its promise; the reality is quite dissatisfying. So, yes, I'd like to see something change. Maybe it's moderation? Maybe it's a Phobos steering group? Maybe it's a language group? Maybe it's Walter participating in the threads criticising D, in which he seems perennially conspicuous by his absence? All of these are things that many different people have been asking for for literally years now. Maybe the answer's in there, maybe not? I really don't know.
Apr 13 2005
parent reply "Kris" <fu bar.com> writes:
Thanks for the considered repsonse, Matthew. More below:


"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote
 Secondly: the terms 'identity' and 'equality' are applied in D
 with
 significant overlap between the two, and it can be hard to get
 these terms
 straight when they are interchanged. For example, the D 'is'
 identity
 operator becomes an equality operator when used with primitive
 types.

Ok, I didn't realise that. That's not good.

But it certainly is handy ;-) Regardless, I think this one is small fry.
 Summary point 1: newcomers to D should likely use 'is' instead of
 '==',
 since those two are "equivalent" from a traditional standpoint
 (both perform
 a shallow test).

Given what you say about 'is' being applicable to built-in types, that's arguable, I guess, but it seems like two wrongs not making a right to me.

Yep: I fully agree. But the compatability aspect is still up in the air (more later)
 However, D does not currently lend itself to avoiding this sort of
 thing. In
 fact, D seems to embrace exactly this bug by making the default
 behaviour of
 '==' be of the shallow variety. A combination of changing
 tradition, yet not
 really, can actually increase maintenance costs.

Strongly agreed. A very powerful point. Another good argument for the removal of opEquals() from Object. Note: I made some of these same points in "Identity and Equality: Syntax and Semantics" (CUJ, Oct 2003; http://www.cuj.com/articles/2003/0310/) and "Identity and Equality in .NET" (DDJ, June 2004; http://www.ddj.com/documents/ddj0406k/), though I discussed the dangerous behaviour you've outlined in terms of C#/.NET. If I may be so crass as to quote myself, it seems I said something that at least two of us would agree with:

<snip> Hurrah! Yet you're still the the one and only person I know of on this NG who cares about such things. Sad, isn't it, that most of the group isn't up in arms over such things.
 Summary point 2: The default shallow test for '==' tends to
 exaggerate the
 potential for confusion. Not only because it does a role-defying
 shallow-
 rather than deep- comparison, but because it can lead directly to
 fragile
 maintenance builds via its changing behaviour.

Totally lost me on that one. Is it covered below? If not, will you rephrase?

That itself is a rephrase of the "dangerous behaviour" we both discuss. Just ignore it.
 While porting 125,000 lines of Java to D, and an interesting thing
 happened.
 You'll perhaps not be surprised to hear Java identity style tests
 are far
 more prevalent than equivalence tests,

Well, yes, I am. Perhaps that's because I don't do much Java?
 but you may be surprised to know that
 the former comprised 98.75% of all explicit tests within those
 125,000
 lines. To embellish, equals() was applied just 1.25% of the time.

Very surprised indeed. Is it plausible that this is skewed by application specificity? What is that code base doing?

In this original section, I made the mistake of not using deep vs shallow. This is because I wanted to isolate and compare the distinction between 'identity' and 'equality' operators in D and Java. That is, Java '==' is identical to D 'is'. Java equals() is almost identical to D '==', with the twist that D '==' is used with primitive types also. So, for clarification, the percentage distinction is actually Java '==' vs 'equals()'. Using a direct conversion route, in D this would be 'is' vs '==' ... 'identity' vs 'equality' :-) It is possible the results are skewed. But by that much? The code base is doing what I'd expect typical business code to do. Not in the exact manner, but in general terms. Lot's of branchy stuff, usage of containers, a few specialized classes, varying degrees of inheritance, etc. Quite bland, actually.
 2) Anyone used to C or Java will habitually use the traditional
 '==' and
 '!=' all over their D code. This is actually the *wrong* thing to
 do, since
 those operators in D are for equivalence testing instead of
 identity
 testing.

Do you mean "since those operators in D are [sometimes, depending on the types of the comparands, used ]for equivalence testing instead of identity testing."?

Yes.
 This has implications for both performance and for "expectations
 of
 behaviour". For example, the subsequent addition of an opEquals()
 to some
 aggregate may break the overall system in all manner of subtle and
 unexpected ways, where the original developer used '==' by force
 of habit.

Agree with the level of concern you're expressing with this. This all stems from the use of references without pointer syntax,

Thank you. I've been wrangling over a source for that one.
 Essentially you're saying that use of == for class types, or in
 generic code that may be applied to class types, is subject to
 hidden and potentially destructive change. This was the crux of my
 article wrt C#, so I completely agree with its severity. (I'm
 somewhat bemused/baffled why I didn't see that it also applies to D,
 and quite chagrined now to see that it does. Huge blunder.)

Yes.
 Given all that, this thread has noted D would become
 backward-compatible if
 the functionality of '==' and 'is' were to be role-reversed. That
 is, if
 '==' were to fully retain its shallow heritage (like 'is' does),
 newcomers
 would not have to even consider switching to using 'is' for the
 majority
 case. This would naturally eliminate the concern over both Summary
 Points 1
 & 2 above. Of course, there's zero expectation that would ever
 happen to
 D -- this role reversal notion is pure speculation, and exists
 simply a
 means of clarifying the current situation.

I don't buy that. Or, rather, I don't think it's an attractive feature/change. Not sure what the answer is, as yet, but I am 100% with you that there's a problem that needs a solution.

I'm not surprised, as it was never intended to be a "solution". It's a shame it got labeled as such.
 I hope this summarizes the thread content thus far. I haven't
 touched on the
 subject brought up by Brad ("how to bridge the gap between user
 defined
 types and built in types?"), which could use some exploration.

Also needs a full solution, IMO

Aye. -----------------
 Speaking for myself, I've certainly become far grumpier of late. It
 seems I take a break due to some pointless/bad experience, and
 foreswear any such future behaviour on my part or being sucked into
 fatuous debates by others, and yet within a couple of days of
 'coming back' it's happening again. Needless to say, I find this
 truly uncharacteristic - honest! <G> - behaviour of mine both
 appalling and intriguing. (I often think how embarrassed I'll be if
 my sons become software engineers and go and look up some of their
 cranky old fart of a father's semi-lucid ranting and pompous
 condescension.)

I'm totally with you, since I find the same thing happening.
 Knowing that I'm running the risk of being called flamer again, I
 submit that the two answers are the two sides of the same coin. I
 keep coming back because I believe D has *great* promise, and I am
 increasingly (and evidently!) frustrated by D because (i) nothing
 seems to change, and (ii) the "good enough" attitude is neither
 something I can relate to nor something that I think is going to
 fulfil the promise.

Exactly. It's truly frustrating, given the potential.
 So, yes, I'd like to see something change. Maybe it's moderation?
 Maybe it's a Phobos steering group? Maybe it's a language group?
 Maybe it's Walter participating in the threads criticising D, in
 which he seems perennially conspicuous by his absence? All of these
 are things that many different people have been asking for for
 literally years now.

 Maybe the answer's in there, maybe not? I really don't know.

Perhaps the NG (or D) is somehow better off without those who question the status-quo?
Apr 13 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 However, D does not currently lend itself to avoiding this sort 
 of
 thing. In
 fact, D seems to embrace exactly this bug by making the default
 behaviour of
 '==' be of the shallow variety. A combination of changing
 tradition, yet not
 really, can actually increase maintenance costs.

Strongly agreed. A very powerful point. Another good argument for the removal of opEquals() from Object. Note: I made some of these same points in "Identity and Equality: Syntax and Semantics" (CUJ, Oct 2003; http://www.cuj.com/articles/2003/0310/) and "Identity and Equality in .NET" (DDJ, June 2004; http://www.ddj.com/documents/ddj0406k/), though I discussed the dangerous behaviour you've outlined in terms of C#/.NET. If I may be so crass as to quote myself, it seems I said something that at least two of us would agree with:

<snip> Hurrah! Yet you're still the the one and only person I know of on this NG who cares about such things. Sad, isn't it, that most of the group isn't up in arms over such things.

But this is what I simply don't get. This 'industry' we're in is exactly what should attract people who genuinely care about the quality of their work. Lord knows, it's not for the chicks, or the money, or the doing-great-work-for-those-less-fortunate. Since it's somewhat related to maths, surely the "if it's not elegant, it's not correct/finished" ethos should pervade. And yet, the older I get, or certainly since the "heady days of the internet", it seems like more and more people care less and less about the elegance. (Short-term) goal-based gratification is king, and, despite this probably having the highest average IQ of just about any profession, few seem to grok the power of the underlying truths, such as orthogonality, simplicity, elegance, etc. It's kind of the like the modern world's approach to health and wellbeing: your lifestyle is 'good enough' and we'll operate when you get ill, rather than caring about environment, social structure, mental health, hours worked vs hours played, etc. etc. Baffling. Sometimes I think I was foolish not to take up my cousin's offer to go and work in The City (== London's financial community) when I got my PhD. He said he'd make me a millionnaire in less than 10 years. That was 10 years ago. ;/
 It is possible the results are skewed. But by that much? The code 
 base is
 doing what I'd expect typical business code to do. Not in the 
 exact manner,
 but in general terms. Lot's of branchy stuff, usage of containers, 
 a few
 specialized classes, varying degrees of inheritance, etc. Quite 
 bland,
 actually.

k. I am willing to take your word for it. Not doubting, just surprised. :-)
 This has implications for both performance and for 
 "expectations
 of
 behaviour". For example, the subsequent addition of an 
 opEquals()
 to some
 aggregate may break the overall system in all manner of subtle 
 and
 unexpected ways, where the original developer used '==' by 
 force
 of habit.

Agree with the level of concern you're expressing with this. This all stems from the use of references without pointer syntax,

Thank you. I've been wrangling over a source for that one.

"twas an honour.
 Given all that, this thread has noted D would become
 backward-compatible if
 the functionality of '==' and 'is' were to be role-reversed. 
 That
 is, if
 '==' were to fully retain its shallow heritage (like 'is' 
 does),
 newcomers
 would not have to even consider switching to using 'is' for the
 majority
 case. This would naturally eliminate the concern over both 
 Summary
 Points 1
 & 2 above. Of course, there's zero expectation that would ever
 happen to
 D -- this role reversal notion is pure speculation, and exists
 simply a
 means of clarifying the current situation.

I don't buy that. Or, rather, I don't think it's an attractive feature/change. Not sure what the answer is, as yet, but I am 100% with you that there's a problem that needs a solution.

I'm not surprised, as it was never intended to be a "solution". It's a shame it got labeled as such.

nw.
 Speaking for myself, I've certainly become far grumpier of late. 
 It
 seems I take a break due to some pointless/bad experience, and
 foreswear any such future behaviour on my part or being sucked 
 into
 fatuous debates by others, and yet within a couple of days of
 'coming back' it's happening again. Needless to say, I find this
 truly uncharacteristic - honest! <G> - behaviour of mine both
 appalling and intriguing. (I often think how embarrassed I'll be 
 if
 my sons become software engineers and go and look up some of 
 their
 cranky old fart of a father's semi-lucid ranting and pompous
 condescension.)

I'm totally with you, since I find the same thing happening.

Something's gotta change. I hope it'll be something organisationally with D, but I suspect it'll be my conscience making me leave in response to increasing number of reasonable complaints about my curmudgeon. :-(
 Knowing that I'm running the risk of being called flamer again, I
 submit that the two answers are the two sides of the same coin. I
 keep coming back because I believe D has *great* promise, and I 
 am
 increasingly (and evidently!) frustrated by D because (i) nothing
 seems to change, and (ii) the "good enough" attitude is neither
 something I can relate to nor something that I think is going to
 fulfil the promise.

Exactly. It's truly frustrating, given the potential.

This is what totally baffles me. Walter had a go at me some time back for being abstraction-obsessed. Ironically, he used as an example what IMO is the starkest example of the stupidity of the "gooD enough" attitude: the opApply() return value. He thinks I'm asking for something pointless, because no-one's yet fallen afoul of it. I want something that is meaningless (i.e. any-other-explicit-value-than-0) and _potentially_ dangerous and, importantly, incredibly simple to fix, to be fixed. My feeling is that such conflicts are just unresolveable, which doesn't attenuate the frustrations any.
 So, yes, I'd like to see something change. Maybe it's moderation?
 Maybe it's a Phobos steering group? Maybe it's a language group?
 Maybe it's Walter participating in the threads criticising D, in
 which he seems perennially conspicuous by his absence? All of 
 these
 are things that many different people have been asking for for
 literally years now.

 Maybe the answer's in there, maybe not? I really don't know.

Perhaps the NG (or D) is somehow better off without those who question the status-quo?

Am answering this with a new post.
Apr 13 2005
next sibling parent reply Brad Anderson <brad dsource.dot.org> writes:
Speaking for myself, I've certainly become far grumpier of late. 
It
seems I take a break due to some pointless/bad experience, and
foreswear any such future behaviour on my part or being sucked 
into
fatuous debates by others, and yet within a couple of days of
'coming back' it's happening again. Needless to say, I find this
truly uncharacteristic - honest! <G> - behaviour of mine both
appalling and intriguing. (I often think how embarrassed I'll be 
if
my sons become software engineers and go and look up some of 
their
cranky old fart of a father's semi-lucid ranting and pompous
condescension.)

I'm totally with you, since I find the same thing happening.

Something's gotta change. I hope it'll be something organisationally with D, but I suspect it'll be my conscience making me leave in response to increasing number of reasonable complaints about my curmudgeon. :-(

This would truly be a shame. The way a technology advances, IMO, is the conflict resolution between knowledgeable, passionate, and boisterous people who are fully engaged in the birthing of the technology. If the conflict is fully vetted, and reasonable compromises can be made, in addition to minds being kept open to future change, then advancement is realized. I hate to name names, and forgive me if I've omitted you, but for D and this NG to lose the voices of Matthew, Kris, Sean and others would be a HUGE loss. They've already been quiet recently as it is. This is a direct result of Walter not finding compromise or recognizing the value of other expert opinions that may differ from his own. Not sure who said this, but maybe ESR? and it's paraphrased... "Thrill your users. At first, it will be the early adopters. Make the experts / power users happy..." This would be a bit more powerful from someone writing a lot of D code on a consistent basis, but I've lurked for 2+ years, and have seen smart people jump up and volunteer some great ideas. I don't care if they get shot down ... to a point. Some of them are now gone because of the problem noted above. Over and over again, it's been proposed that some organization be formed to augment Walter's efforts, whether library or lang standard. Let me say this carefully: THIS IS NOT GOING TO HAPPEN. If it's not going to happen, then get David Friedman on board, or do it yourselves, but fork the damn language and fix the warts you guys want to fix! If you come up with something better, then maybe Walter will want to merge back with you. When he holds the keys to the kingdom, however, the advancement made will not be sufficient in your minds. One effort that holds my respect is Ares, because it's the only thing those guys can do to compensate for their perceived shortcomings of Phobos. Even if they've stopped (slowed) participating in the NG, they are still coding that lib. Compiler warts and all. It's all that they can control. <somewhat-random-tangent> If none of this works, and you truly want to leave D, then come join me in the world of Common Lisp. Talk about a powerful language devoid of lots of the warts you speak of. (btw, don't tell me it's interpreted, slow, full of parentheses, and its developers talk funny. All of that's bull, except for the parens, and they're manageable.) All of the Design Patterns you OO guys work with daily are basically to make up for Java/C/C++/D's lack of late binding, and there's nothing like the macros or closures in Lisp. </somewhat-random-tangent> I have learned a ton from this NG, watching the more experienced developers debate, and firmly believe that D would be worse off without the powerful voices that chime in regularly. But I empathize with them in their frustration to affect change recently (i.e. before 1.0). WTF, Walter? Don't answer my post. Answer theirs... And if he doesn't answer, boys, go ahead and fork it. There has to be some way to affect change and realize the great promise that keeps you coming back to the current quagmire. BA
Apr 13 2005
next sibling parent reply kris <fu bar.org> writes:
Now this ... is the best post I've read here in a rather long time.


Brad Anderson wrote:
 Speaking for myself, I've certainly become far grumpier of late. It
 seems I take a break due to some pointless/bad experience, and
 foreswear any such future behaviour on my part or being sucked into
 fatuous debates by others, and yet within a couple of days of
 'coming back' it's happening again. Needless to say, I find this
 truly uncharacteristic - honest! <G> - behaviour of mine both
 appalling and intriguing. (I often think how embarrassed I'll be if
 my sons become software engineers and go and look up some of their
 cranky old fart of a father's semi-lucid ranting and pompous
 condescension.)

I'm totally with you, since I find the same thing happening.

Something's gotta change. I hope it'll be something organisationally with D, but I suspect it'll be my conscience making me leave in response to increasing number of reasonable complaints about my curmudgeon. :-(

This would truly be a shame. The way a technology advances, IMO, is the conflict resolution between knowledgeable, passionate, and boisterous people who are fully engaged in the birthing of the technology. If the conflict is fully vetted, and reasonable compromises can be made, in addition to minds being kept open to future change, then advancement is realized. I hate to name names, and forgive me if I've omitted you, but for D and this NG to lose the voices of Matthew, Kris, Sean and others would be a HUGE loss. They've already been quiet recently as it is. This is a direct result of Walter not finding compromise or recognizing the value of other expert opinions that may differ from his own. Not sure who said this, but maybe ESR? and it's paraphrased... "Thrill your users. At first, it will be the early adopters. Make the experts / power users happy..." This would be a bit more powerful from someone writing a lot of D code on a consistent basis, but I've lurked for 2+ years, and have seen smart people jump up and volunteer some great ideas. I don't care if they get shot down ... to a point. Some of them are now gone because of the problem noted above. Over and over again, it's been proposed that some organization be formed to augment Walter's efforts, whether library or lang standard. Let me say this carefully: THIS IS NOT GOING TO HAPPEN. If it's not going to happen, then get David Friedman on board, or do it yourselves, but fork the damn language and fix the warts you guys want to fix! If you come up with something better, then maybe Walter will want to merge back with you. When he holds the keys to the kingdom, however, the advancement made will not be sufficient in your minds. One effort that holds my respect is Ares, because it's the only thing those guys can do to compensate for their perceived shortcomings of Phobos. Even if they've stopped (slowed) participating in the NG, they are still coding that lib. Compiler warts and all. It's all that they can control. <somewhat-random-tangent> If none of this works, and you truly want to leave D, then come join me in the world of Common Lisp. Talk about a powerful language devoid of lots of the warts you speak of. (btw, don't tell me it's interpreted, slow, full of parentheses, and its developers talk funny. All of that's bull, except for the parens, and they're manageable.) All of the Design Patterns you OO guys work with daily are basically to make up for Java/C/C++/D's lack of late binding, and there's nothing like the macros or closures in Lisp. </somewhat-random-tangent> I have learned a ton from this NG, watching the more experienced developers debate, and firmly believe that D would be worse off without the powerful voices that chime in regularly. But I empathize with them in their frustration to affect change recently (i.e. before 1.0). WTF, Walter? Don't answer my post. Answer theirs... And if he doesn't answer, boys, go ahead and fork it. There has to be some way to affect change and realize the great promise that keeps you coming back to the current quagmire. BA

Apr 14 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
In defense of Walter, he's in a tough position here. We're all wanting his
time, but what are we able to offer him for it other than some of our own time
in return?  We all want him to see things in a certain light, accomplish
certain goals, solve certain problems, and so on.

My first contact with him was basically a complaint... and rather than word it
as an observation, I worded it as just what it was... a complaint.  Well,
realistically, I had no right to complain.  The problem was that the
installation and setup of the D compiler on my system to a useable condition
turned out not to work the way the documentation said it would, and I spent a
lot of time working around one problem after another.  Well... I paid nothing
for it, and from what I can see (although I didn't know this at the time) it is
technically pre-release software... still in development.  With that in mind,
I'm now simply happy that I got it running at all.  Beyond that, I can honestly
say that even in it's current beta-like state, I like it enough that I have
decided on a project to write and have chosen D as the language to write it in.

Now, looking back on it, I "should have" been more considerate of his feelings
when I wrote that first letter.  Of course, since I didn't know him at all and
I was extremely frustrated at the time, I handled the situation poorly.

By the way, Walter, if you're reading this... please accept my sincere and
humble apology.

Okay, so there are things that need worked out.  We'll get through them. 
Overall, I would say we're a good group of people, and capable on the whole of
being supportive of each other, of the D language that we all share an interest
in, and of anyone who stands behind us or our shared interest.  Sometimes, it
may not look that way, and Walter is probably seeing the worst of it more than
any of us... so I suggest we cut him some slack, and try to be encouraging
without setting our cumulative expectations of him higher than we can expect of
ourselves.

From what I can see... in this arena, he's got more lions to fight off than the
rest of us... so if we're going to be in the audience from time to time, it
should be cheering him on... and when the opportunity arises, perhaps we can
pull a lion or two off his back and help give him a fighting chance at victory.
 :)

TZ

"kris" <fu bar.org> wrote in message news:d3l4mb$8eh$1 digitaldaemon.com...
 Now this ... is the best post I've read here in a rather long time.


 Brad Anderson wrote:
 Speaking for myself, I've certainly become far grumpier of late. It
 seems I take a break due to some pointless/bad experience, and
 foreswear any such future behaviour on my part or being sucked into
 fatuous debates by others, and yet within a couple of days of
 'coming back' it's happening again. Needless to say, I find this
 truly uncharacteristic - honest! <G> - behaviour of mine both
 appalling and intriguing. (I often think how embarrassed I'll be if
 my sons become software engineers and go and look up some of their
 cranky old fart of a father's semi-lucid ranting and pompous
 condescension.)

I'm totally with you, since I find the same thing happening.

Something's gotta change. I hope it'll be something organisationally with D, but I suspect it'll be my conscience making me leave in response to increasing number of reasonable complaints about my curmudgeon. :-(

This would truly be a shame. The way a technology advances, IMO, is the conflict resolution between knowledgeable, passionate, and boisterous people who are fully engaged in the birthing of the technology. If the conflict is fully vetted, and reasonable compromises can be made, in addition to minds being kept open to future change, then advancement is realized. I hate to name names, and forgive me if I've omitted you, but for D and this NG to lose the voices of Matthew, Kris, Sean and others would be a HUGE loss. They've already been quiet recently as it is. This is a direct result of Walter not finding compromise or recognizing the value of other expert opinions that may differ from his own. Not sure who said this, but maybe ESR? and it's paraphrased... "Thrill your users. At first, it will be the early adopters. Make the experts / power users happy..." This would be a bit more powerful from someone writing a lot of D code on a consistent basis, but I've lurked for 2+ years, and have seen smart people jump up and volunteer some great ideas. I don't care if they get shot down ... to a point. Some of them are now gone because of the problem noted above. Over and over again, it's been proposed that some organization be formed to augment Walter's efforts, whether library or lang standard. Let me say this carefully: THIS IS NOT GOING TO HAPPEN. If it's not going to happen, then get David Friedman on board, or do it yourselves, but fork the damn language and fix the warts you guys want to fix! If you come up with something better, then maybe Walter will want to merge back with you. When he holds the keys to the kingdom, however, the advancement made will not be sufficient in your minds. One effort that holds my respect is Ares, because it's the only thing those guys can do to compensate for their perceived shortcomings of Phobos. Even if they've stopped (slowed) participating in the NG, they are still coding that lib. Compiler warts and all. It's all that they can control. <somewhat-random-tangent> If none of this works, and you truly want to leave D, then come join me in the world of Common Lisp. Talk about a powerful language devoid of lots of the warts you speak of. (btw, don't tell me it's interpreted, slow, full of parentheses, and its developers talk funny. All of that's bull, except for the parens, and they're manageable.) All of the Design Patterns you OO guys work with daily are basically to make up for Java/C/C++/D's lack of late binding, and there's nothing like the macros or closures in Lisp. </somewhat-random-tangent> I have learned a ton from this NG, watching the more experienced developers debate, and firmly believe that D would be worse off without the powerful voices that chime in regularly. But I empathize with them in their frustration to affect change recently (i.e. before 1.0). WTF, Walter? Don't answer my post. Answer theirs... And if he doesn't answer, boys, go ahead and fork it. There has to be some way to affect change and realize the great promise that keeps you coming back to the current quagmire. BA


Apr 14 2005
parent reply James Dunne <jdunne4 bradley.edu> writes:
I agree.  I just find it amazing that he has time to troll the forums and
respond to user feedback as well as keeping a relatively consistent release
schedule going.  I'm very appreciative of all his hard work over the years and D
is primarily my language of choice now.

I really don't have any significant gripes with any technical issues, except
where strange bugs pop up once in a while, but technically this is "beta"
software, like you said, and you get what you pay for. :-P.  Frankly I think
we're getting amazing feedback and support for what we pay.

I don't know about all you guys, but I've never had anywhere near this close of
contact with a language developer working on a new language.  I find it exciting
to see new features and bug fixes come out regularly.  I trust Walter's
decisions on the language for the most part, and think he's taking it in the
right directions it needs to go in to succeed.

I'm sure others agree with me here, but all you hear about on the forums is the
select few individuals who have strong opinions on the issues debating back and
forth.  I think things may be better if we actually told Walter what we *like*
about the language in addition to what should be fixed/changed.

Here's my list of things I like about D:
- builtin associative arrays
- breaking down the barrier between -> and . field access operators.  honestly,
who cares if the damn thing's a pointer to a structure??
- no funky syntax for referring to objects like * and &.
of course, i still use pointers where appropriate in order to communicate with C
and do some other cool low-level things, but i really hate the & syntax of C++.
Just recently I was asked to help out with a C++ project, and I completely
forgot how to use the language since I've been using D so much!
- operator overload syntax is certainly wonderful!
- declaring all your methods and variables in one single class definition,
rather than the tiresome .h/.cpp duplication of effort and creator of bugs
- imports and modules are a Godsend to maintainability and code reuse (except
when you change the package name of a module to move to a different project -
the endless barrage of import- and module-line changes is enough to drive one
insane)
- properties!!! default arrays, basic types.
however for classes, a get/set syntax really should be used here to define
properties, much like that of C#'s.
- array copy / slicing syntax is absolutely beautiful and I cannot live without
it now.  memcpy just looks so ugly to me now!
- array concatenation
- mixins and templates (except limits of template inheritance in classes as well
as using templates as types)
- free source code to phobos library for complete modification
+ my no-gc patch!
+ most advanced language features boil down to C function calls - now THAT is
true power!!
- the D calling convention is just brilliant and feels like a necessary
evolution of calling conventions.  in, out, inout are truly genious as well as
the variadic parameter approach
? Garbage collection ... I could take it or leave it.  It feels like a crutch to
me.
- readability.  The readability of this language is just through the roof (in
the good sense)!  I love reading through D code, it looks to me like what C has
meant to read like for a long time, but couldn't quite get there.  It is much
cleaner than C++, for sure.

Regards,
James Dunne
Apr 14 2005
next sibling parent Brad Anderson <brad dsource.dot.org> writes:
James Dunne wrote:
 I agree.  I just find it amazing that he has time to troll the forums and
 respond to user feedback as well as keeping a relatively consistent release
 schedule going.  I'm very appreciative of all his hard work over the years and
D
 is primarily my language of choice now.
 
 I really don't have any significant gripes with any technical issues, except
 where strange bugs pop up once in a while, but technically this is "beta"
 software, like you said, and you get what you pay for. :-P.  Frankly I think
 we're getting amazing feedback and support for what we pay.
 
 I don't know about all you guys, but I've never had anywhere near this close of
 contact with a language developer working on a new language.  I find it
exciting
 to see new features and bug fixes come out regularly.  I trust Walter's
 decisions on the language for the most part, and think he's taking it in the
 right directions it needs to go in to succeed.

I don't think my post should be taken as a slight against Walter and his efforts poured into D. I am as appreciative as you, TZ, bobef, and scores of others. My issue is with the process of affecting change recently. You may not have any significant gripes, and I only have a few. But seasoned developers with more experience than most of us put together seem to be fixated on a few warts of the language. I have to believe that if I ever get as deep into development as they have, I will see the warts, too. These guys know more about language use and how moderately skilled developers get trapped than This is why I'm criticizing the methods or processes Walter is (not) implementing as the language grows. We simply don't hear from him after he disagrees with a thread.
 
 I'm sure others agree with me here, but all you hear about on the forums is the
 select few individuals who have strong opinions on the issues debating back and
 forth.  I think things may be better if we actually told Walter what we *like*
 about the language in addition to what should be fixed/changed.

As for your list of things we like about D, it's a good exercise. But I imagine it's equally long for all of us. Remember, even the curmudgeons keep coming back for the great promise... BA
 
 Here's my list of things I like about D:
 - builtin associative arrays
 - breaking down the barrier between -> and . field access operators.  honestly,
 who cares if the damn thing's a pointer to a structure??
 - no funky syntax for referring to objects like * and &.
 of course, i still use pointers where appropriate in order to communicate with
C
 and do some other cool low-level things, but i really hate the & syntax of C++.
 Just recently I was asked to help out with a C++ project, and I completely
 forgot how to use the language since I've been using D so much!
 - operator overload syntax is certainly wonderful!
 - declaring all your methods and variables in one single class definition,
 rather than the tiresome .h/.cpp duplication of effort and creator of bugs
 - imports and modules are a Godsend to maintainability and code reuse (except
 when you change the package name of a module to move to a different project -
 the endless barrage of import- and module-line changes is enough to drive one
 insane)
 - properties!!! default arrays, basic types.
 however for classes, a get/set syntax really should be used here to define
 properties, much like that of C#'s.
 - array copy / slicing syntax is absolutely beautiful and I cannot live without
 it now.  memcpy just looks so ugly to me now!
 - array concatenation
 - mixins and templates (except limits of template inheritance in classes as
well
 as using templates as types)
 - free source code to phobos library for complete modification
 + my no-gc patch!
 + most advanced language features boil down to C function calls - now THAT is
 true power!!
 - the D calling convention is just brilliant and feels like a necessary
 evolution of calling conventions.  in, out, inout are truly genious as well as
 the variadic parameter approach
 ? Garbage collection ... I could take it or leave it.  It feels like a crutch
to
 me.
 - readability.  The readability of this language is just through the roof (in
 the good sense)!  I love reading through D code, it looks to me like what C has
 meant to read like for a long time, but couldn't quite get there.  It is much
 cleaner than C++, for sure.
 
 Regards,
 James Dunne

Apr 14 2005
prev sibling parent "Carlos Santander B." <csantander619 gmail.com> writes:
James Dunne wrote:
 I agree.  I just find it amazing that he has time to troll the forums
 and respond to user feedback as well as keeping a relatively
 consistent release schedule going.  I'm very appreciative of all his
 hard work over the years and D is primarily my language of choice
 now.
 
 I really don't have any significant gripes with any technical issues,
 except where strange bugs pop up once in a while, but technically
 this is "beta" software, like you said, and you get what you pay for.
 :-P.  Frankly I think we're getting amazing feedback and support for
 what we pay.
 
 I don't know about all you guys, but I've never had anywhere near
 this close of contact with a language developer working on a new
 language.  I find it exciting to see new features and bug fixes come
 out regularly.  I trust Walter's decisions on the language for the
 most part, and think he's taking it in the right directions it needs
 to go in to succeed.
 
 I'm sure others agree with me here, but all you hear about on the
 forums is the select few individuals who have strong opinions on the
 issues debating back and forth.  I think things may be better if we
 actually told Walter what we *like* about the language in addition to
 what should be fixed/changed.
 
 Here's my list of things I like about D: - builtin associative arrays
  - breaking down the barrier between -> and . field access operators.
 honestly, who cares if the damn thing's a pointer to a structure?? -
 no funky syntax for referring to objects like * and &. of course, i
 still use pointers where appropriate in order to communicate with C 
 and do some other cool low-level things, but i really hate the &
 syntax of C++. Just recently I was asked to help out with a C++
 project, and I completely forgot how to use the language since I've
 been using D so much! - operator overload syntax is certainly
 wonderful! - declaring all your methods and variables in one single
 class definition, rather than the tiresome .h/.cpp duplication of
 effort and creator of bugs - imports and modules are a Godsend to
 maintainability and code reuse (except when you change the package
 name of a module to move to a different project - the endless barrage
 of import- and module-line changes is enough to drive one insane) -
 properties!!! default arrays, basic types. however for classes, a
 get/set syntax really should be used here to define properties, much
 like that of C#'s. - array copy / slicing syntax is absolutely
 beautiful and I cannot live without it now.  memcpy just looks so
 ugly to me now! - array concatenation - mixins and templates (except
 limits of template inheritance in classes as well as using templates
 as types) - free source code to phobos library for complete
 modification + my no-gc patch! + most advanced language features boil
 down to C function calls - now THAT is true power!! - the D calling
 convention is just brilliant and feels like a necessary evolution of
 calling conventions.  in, out, inout are truly genious as well as the
 variadic parameter approach ? Garbage collection ... I could take it
 or leave it.  It feels like a crutch to me. - readability.  The
 readability of this language is just through the roof (in the good
 sense)!  I love reading through D code, it looks to me like what C
 has meant to read like for a long time, but couldn't quite get there.
 It is much cleaner than C++, for sure.
 
 Regards, James Dunne

I very much feel like James here, but there's something else: Brad Anderson wrote:
 You may not have any significant gripes, and I only have a few.  But
 seasoned developers with more experience than most of us put together
 seem to be fixated on a few warts of the language.  I have to believe
 that if I ever get as deep into development as they have, I will see
 the warts, too.  These guys know more about language use and how
 moderately skilled developers get trapped than This is why I'm
 criticizing the methods or processes Walter is (not) implementing as
 the language grows.  We simply don't hear from him after he disagrees
 with a thread.

I also agree with Brad with this. -- Carlos Santander Bernal JP2, you'll always live in our minds
Apr 14 2005
prev sibling next sibling parent reply bobef <bobef_member pathlink.com> writes:
In article <d3l33k$6fr$1 digitaldaemon.com>, Brad Anderson says...
Speaking for myself, I've certainly become far grumpier of late. 
It
seems I take a break due to some pointless/bad experience, and
foreswear any such future behaviour on my part or being sucked 
into
fatuous debates by others, and yet within a couple of days of
'coming back' it's happening again. Needless to say, I find this
truly uncharacteristic - honest! <G> - behaviour of mine both
appalling and intriguing. (I often think how embarrassed I'll be 
if
my sons become software engineers and go and look up some of 
their
cranky old fart of a father's semi-lucid ranting and pompous
condescension.)

I'm totally with you, since I find the same thing happening.

Something's gotta change. I hope it'll be something organisationally with D, but I suspect it'll be my conscience making me leave in response to increasing number of reasonable complaints about my curmudgeon. :-(

This would truly be a shame. The way a technology advances, IMO, is the conflict resolution between knowledgeable, passionate, and boisterous people who are fully engaged in the birthing of the technology. If the conflict is fully vetted, and reasonable compromises can be made, in addition to minds being kept open to future change, then advancement is realized. I hate to name names, and forgive me if I've omitted you, but for D and this NG to lose the voices of Matthew, Kris, Sean and others would be a HUGE loss. They've already been quiet recently as it is. This is a direct result of Walter not finding compromise or recognizing the value of other expert opinions that may differ from his own. Not sure who said this, but maybe ESR? and it's paraphrased... "Thrill your users. At first, it will be the early adopters. Make the experts / power users happy..." This would be a bit more powerful from someone writing a lot of D code on a consistent basis, but I've lurked for 2+ years, and have seen smart people jump up and volunteer some great ideas. I don't care if they get shot down ... to a point. Some of them are now gone because of the problem noted above. Over and over again, it's been proposed that some organization be formed to augment Walter's efforts, whether library or lang standard. Let me say this carefully: THIS IS NOT GOING TO HAPPEN. If it's not going to happen, then get David Friedman on board, or do it yourselves, but fork the damn language and fix the warts you guys want to fix! If you come up with something better, then maybe Walter will want to merge back with you. When he holds the keys to the kingdom, however, the advancement made will not be sufficient in your minds. One effort that holds my respect is Ares, because it's the only thing those guys can do to compensate for their perceived shortcomings of Phobos. Even if they've stopped (slowed) participating in the NG, they are still coding that lib. Compiler warts and all. It's all that they can control. <somewhat-random-tangent> If none of this works, and you truly want to leave D, then come join me in the world of Common Lisp. Talk about a powerful language devoid of lots of the warts you speak of. (btw, don't tell me it's interpreted, slow, full of parentheses, and its developers talk funny. All of that's bull, except for the parens, and they're manageable.) All of the Design Patterns you OO guys work with daily are basically to make up for Java/C/C++/D's lack of late binding, and there's nothing like the macros or closures in Lisp. </somewhat-random-tangent> I have learned a ton from this NG, watching the more experienced developers debate, and firmly believe that D would be worse off without the powerful voices that chime in regularly. But I empathize with them in their frustration to affect change recently (i.e. before 1.0). WTF, Walter? Don't answer my post. Answer theirs... And if he doesn't answer, boys, go ahead and fork it. There has to be some way to affect change and realize the great promise that keeps you coming back to the current quagmire. BA

I am sorry for the rude language but some things have to be said as they are. First I want to ask what does the subject means? The F Word? What is that? Fuck Walter? Fuck D? Fuck this community? Fuck the world? Which of them? Or it is a joke because only fuck is called the f word but it could be any F-word? And if it is fuck then say it rebel boy! Loudly and proudly. If this is your position stand for it. This is not a kids forum after all. Now my opinion: I totaly stand behind Walter. What he does is great and I deeply respect it and him too. I'm not here from 2 years, but it is almost a year since I found D, so I believe I could say that. What Walter did (the D language) is something great. No need to say why, hope everyone here knows why. And it is true that Walter is not listening about some things. I want this or that. I don't like Walter has different opinion from mine, but this is his product. It will be what he decides and I respect that. And I believe he is a wise man and he will not decide something stupid. And even if I believe something is stupid it is not up to me. If I disagree so much I will take D as a base and make E language as Walter did with C++. If you want something --- it is open source god damn it. Go there and fix it. And I am glad Walter keeps to his opinion only. Otherwise D will end up like linux - a useless bag of SHIT. In matter of fact everyone's shit. Someone touches here, someone touches there and it becomes useless. If you want it to be useless you have to start over and modify all the software... It can't be good for everyone. People are different and thats cool about it. Walter is sparing so much time doing D and I think it's DAMN good! It is not flawless of course. It has flaw in design and it has flaws in implementation but what the fuck??!? IT IS STILL THE BEST LANGUAGE TO THIS DATE! That does not mean I'm resigned to it. I hope after some time Walter will reconsider parts of D so it will become flawless. But lets get down to earth. I know everyone wants D 1.0. But we are light years away. And still we can't just say D is not 1.0 because Walter doesn't want to do what we say. And if D is so good in version 0.120 in 1.0 it WILL BE flawless!
Apr 14 2005
next sibling parent reply David Medlock <amedlock nospam.org> writes:
bobef wrote:

 I am sorry for the rude language but some things have to be said as they are.
 
 First I want to ask what does the subject means? The F Word? 

I think they were referring to 'Fork'... -David
Apr 14 2005
parent reply pragma <pragma_member pathlink.com> writes:
In article <d3lrk9$umr$1 digitaldaemon.com>, David Medlock says...
bobef wrote:

 I am sorry for the rude language but some things have to be said as they are.
 
 First I want to ask what does the subject means? The F Word? 

I think they were referring to 'Fork'...

Thank you for clarifying things. Its an important topic, so allow me to shed some light on the notion for the unintiated: By "F-Word", the OP means "Fork". Saying "F-word" here is clever word-play since many view forking as, well, dirty and undesirable. http://en.wikipedia.org/wiki/Fork_(software) "In software, a project fork or branch happens when a developer (or a group of them) takes code from a project and starts to develop independently of the rest. The term is also used more loosely to represent a similar branching of any work (for example, there are several forks of the English language Wikipedia)." "The term is particularly used in free or open source software, when a schism occurs because of different goals or personality clashes. Some see forks as a weakness in open source, but they can demonstrate the adaptability of the model. The relationship between the different teams can be cordial or very bitter (see xMule and its fork aMule)." The following is largely IMO. Please read, thank you. Forking isn't always a bad thing. Unfortunately, I cannot speak from experience here. The worst that forking can do is divide the resources of a given community so that no branch of the project tree succeeds. It also can be viewed externally as a weakness in the strength of the current offerings behind the overall project... but your mileage may vary. It can also be extremely damaging to developer egos, and can deepend community schisms by becomming a dividing line. So you only really want to fork unless there's absolutely nowhere else to go, since it's so risky. If one looks at the D language as an open specification, with Digital Mars as merely a compiler vendor, then forking makes some sense. other compilers could easily push the envelope of the spec and reccomend updates to Walter so DMD continues to be a part of the pack. As to whom controls the actual D spec, that's the rub. A true fork would indicate that there would be competing D specifications out there, which could be a very bad thing; it could re-invent the problem with C and C++ which is what D was supposed to fix. And besides, nobody is impressed by the "our wheel is rounder" approach. <j/k> An interim solution: Instead of outright saying "D is ours, and we'll go make it our way", perhaps a compromise should be struck instead? First of all, GDC is a very capable rendition of D and is dire need of additional support. It is presently 7 (going on 8) releases behind DMD. If you're looking to get D to make an impact, then get hacking! Second, I strongly reccomend that everyone get a copy of either GDC or Ben Hinkle's DMDFE distribution. The current front end is intimidating, but enabling some of the debug printf statements can yield a lot of insight as to how source is modeled and used to drive the actual compiler***. A determined hacker can easily start adding their own customizations to the language within a mere week, possibly less. Third, after you are familiar with the front-end, start test-bedding new language concepts. Build working groups, and encourage the community to try the new features on for size. Nothing says "this works better" than being able to point at code that compiles on *something*. Its far and away better than all the theory and "this works in forth/lisp/perl" discussions we've seen so far. Plus, the process will inevidably weed out concepts that are simply too hard to implement. I would like to think that publishing compiler patches, to GDC and possibly DMD, would *accelerate* the overall state of the language in a way that Forking couldn't possibly achieve. At worst, the testbed compiler patches will get folded into GDC first, which will (later on) fork quite naturally on its own under the weight of these enhancements. This is the model currently adopted for Ares, and is working quite well. Another exmaple: what if Georg and friends formed a Vectorization working group for D? They could acutally implement vectorization for D and pound out all the kinks. Then they can just supply the community with a reference implementation, documentation, and possibly furnish Walter with a diff/patch so DMD could fully implement the feature. No forking, just collaborating with the community as a whole (Walter included) to get the *implemented enhancements* included in GDC and/or DMD. It seems like a lot, and is certainly more effort than begging for language enhancements from Walter. But it is *orders of magnitude* less complicated and less cumbersome than starting up an over-arching new project to steer the entire state of the language, *and* compete with DMD. People will all want to go their own way at some point anyhow, so why not encourage and leverage that behavior instead? The bottom line here is: why offically fork, when you can form nimble task groups that can build proof-of-concepts for consumption by Walter et al, all by hacking the front-end source. The tools are there, the talent is there, and the ambition is there. In other words, get it done today instead of after everything goes through a (forked) committee that may very well frustrate people as much as Walter has. (*** A doxygen replacement, and a myriad of other tools, could also consume data generated by the front-end) - EricAnderton at yahoo
Apr 14 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
pragma wrote:

 If one looks at the D language as an open specification, with Digital Mars as
 merely a compiler vendor, then forking makes some sense.  other compilers could
 easily push the envelope of the spec and reccomend updates to Walter so DMD
 continues to be a part of the pack.  
 
 As to whom controls the actual D spec, that's the rub.  A true fork would
 indicate that there would be competing D specifications out there, which could
 be a very bad thing; it could re-invent the problem with C and C++ which is
what
 D was supposed to fix.
 
 And besides, nobody is impressed by the "our wheel is rounder" approach. <j/k>

The D specification is copyrighted by Digital Mars, so it's not "open". Then again, it seems silly to fork a language that's so small to begin with? Might as well start using C or Objective-C or C++ or C# instead. Here's hoping that it stays one "project", and that most of the changes needed for GDC are implemented in the upstream DMD front-end itself... (for instance, it seems silly to have two different versions of Phobos?)
 First of all, GDC is a very capable rendition of D and is dire need of
 additional support.  It is presently 7 (going on 8) releases behind DMD.  If
 you're looking to get D to make an impact, then get hacking!  

There's a lot of *impressive* changes in GDC 0.11 already. And for next version, David is even synching with DMD 0.120... Seems like both Walter and David are making good progress, while the intense discussions rages back and forth here ? :-) --anders
Apr 14 2005
prev sibling parent reply Brad Anderson <brad dsource.dot.org> writes:
pragma wrote:
 In article <d3lrk9$umr$1 digitaldaemon.com>, David Medlock says...
 
bobef wrote:


I am sorry for the rude language but some things have to be said as they are.

First I want to ask what does the subject means? The F Word? 

I think they were referring to 'Fork'...

Thank you for clarifying things. Its an important topic, so allow me to shed some light on the notion for the unintiated: By "F-Word", the OP means "Fork". Saying "F-word" here is clever word-play since many view forking as, well, dirty and undesirable. http://en.wikipedia.org/wiki/Fork_(software) "In software, a project fork or branch happens when a developer (or a group of them) takes code from a project and starts to develop independently of the rest. The term is also used more loosely to represent a similar branching of any work (for example, there are several forks of the English language Wikipedia)." "The term is particularly used in free or open source software, when a schism occurs because of different goals or personality clashes. Some see forks as a weakness in open source, but they can demonstrate the adaptability of the model. The relationship between the different teams can be cordial or very bitter (see xMule and its fork aMule)." The following is largely IMO. Please read, thank you. Forking isn't always a bad thing. Unfortunately, I cannot speak from experience here. The worst that forking can do is divide the resources of a given community so that no branch of the project tree succeeds. It also can be viewed externally as a weakness in the strength of the current offerings behind the overall project... but your mileage may vary. It can also be extremely damaging to developer egos, and can deepend community schisms by becomming a dividing line. So you only really want to fork unless there's absolutely nowhere else to go, since it's so risky. If one looks at the D language as an open specification, with Digital Mars as merely a compiler vendor, then forking makes some sense. other compilers could easily push the envelope of the spec and reccomend updates to Walter so DMD continues to be a part of the pack. As to whom controls the actual D spec, that's the rub. A true fork would indicate that there would be competing D specifications out there, which could be a very bad thing; it could re-invent the problem with C and C++ which is what D was supposed to fix. And besides, nobody is impressed by the "our wheel is rounder" approach. <j/k> An interim solution: Instead of outright saying "D is ours, and we'll go make it our way", perhaps a compromise should be struck instead? First of all, GDC is a very capable rendition of D and is dire need of additional support. It is presently 7 (going on 8) releases behind DMD. If you're looking to get D to make an impact, then get hacking! Second, I strongly reccomend that everyone get a copy of either GDC or Ben Hinkle's DMDFE distribution. The current front end is intimidating, but enabling some of the debug printf statements can yield a lot of insight as to how source is modeled and used to drive the actual compiler***. A determined hacker can easily start adding their own customizations to the language within a mere week, possibly less. Third, after you are familiar with the front-end, start test-bedding new language concepts. Build working groups, and encourage the community to try the new features on for size. Nothing says "this works better" than being able to point at code that compiles on *something*. Its far and away better than all the theory and "this works in forth/lisp/perl" discussions we've seen so far. Plus, the process will inevidably weed out concepts that are simply too hard to implement. I would like to think that publishing compiler patches, to GDC and possibly DMD, would *accelerate* the overall state of the language in a way that Forking couldn't possibly achieve. At worst, the testbed compiler patches will get folded into GDC first, which will (later on) fork quite naturally on its own under the weight of these enhancements. This is the model currently adopted for Ares, and is working quite well. Another exmaple: what if Georg and friends formed a Vectorization working group for D? They could acutally implement vectorization for D and pound out all the kinks. Then they can just supply the community with a reference implementation, documentation, and possibly furnish Walter with a diff/patch so DMD could fully implement the feature. No forking, just collaborating with the community as a whole (Walter included) to get the *implemented enhancements* included in GDC and/or DMD. It seems like a lot, and is certainly more effort than begging for language enhancements from Walter. But it is *orders of magnitude* less complicated and less cumbersome than starting up an over-arching new project to steer the entire state of the language, *and* compete with DMD. People will all want to go their own way at some point anyhow, so why not encourage and leverage that behavior instead? The bottom line here is: why offically fork, when you can form nimble task groups that can build proof-of-concepts for consumption by Walter et al, all by hacking the front-end source. The tools are there, the talent is there, and the ambition is there. In other words, get it done today instead of after everything goes through a (forked) committee that may very well frustrate people as much as Walter has. (*** A doxygen replacement, and a myriad of other tools, could also consume data generated by the front-end) - EricAnderton at yahoo

Eric, Thanks for your "middle-of-the-road" suggestion. In many ways, I was thinking along these lines when I said that maybe Walter sees some goodness in this effort and incorporates it back into DMD. I was indeed thinking of an amicable fork, but maybe a proof-of-concept approach would work better. I agree with Anders that anything would be better than arguing in the NG. However, this group needs to be prepared for continued silence from Walter and go their own way. BA
Apr 14 2005
parent "Kris" <fu bar.com> writes:
That is how I read your initial post, Brad.

i.e. "the NG has little or zero impact anyway, so get over it, people, and
take control of your own destiny"

There's no slight to Walter, or anyone else for that matter. To me, it's
simply noting "the emperor has no clothes on", where the emperor is the NG.
I think you were right on the money.

- Kris


"Brad Anderson" <brad dsource.dot.org> wrote in message
news:d3m7gi$1bd9$1 digitaldaemon.com...
 The bottom line here is: why offically fork, when you can form nimble


 groups that can build proof-of-concepts for consumption by Walter et al,


 hacking the front-end source.  The tools are there, the talent is there,


 ambition is there.  In other words, get it done today instead of after
 everything goes through a (forked) committee that may very well


 as much as Walter has.

 (*** A doxygen replacement, and a myriad of other tools, could also


 generated by the front-end)

 - EricAnderton at yahoo

Eric, Thanks for your "middle-of-the-road" suggestion. In many ways, I was thinking along these lines when I said that maybe Walter sees some goodness in this effort and incorporates it back into DMD. I was indeed thinking of an amicable fork, but maybe a proof-of-concept approach would work better. I agree with Anders that anything would be better than arguing in the NG. However, this group needs to be prepared for continued silence from Walter and go their own way. BA

Apr 14 2005
prev sibling next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
 And I am glad Walter keeps to his opinion only. Otherwise D will end up like
 linux - a useless bag of SHIT. In matter of fact everyone's shit. Someone
 touches here, someone touches there and it becomes useless. If you want it to
be
 useless you have to start over and modify all the software...
 It can't be good for everyone. People are different and thats cool about it.

This implies either that Walter knows more about *every* issue than any person here, or that embracing opinion from any parties, however qualified, is too dangerous to be not worth the manifest improvement in the language. Neither of these hold up to scrutiny.
Apr 14 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3mlf0$1pkj$4 digitaldaemon.com...
 And I am glad Walter keeps to his opinion only. Otherwise D will end up like
 linux - a useless bag of SHIT. In matter of fact everyone's shit. Someone
 touches here, someone touches there and it becomes useless. If you want it to
be
 useless you have to start over and modify all the software...
 It can't be good for everyone. People are different and thats cool about it.

This implies either that Walter knows more about *every* issue than any person here, or that embracing opinion from any parties, however qualified, is too dangerous to be not worth the manifest improvement in the language. Neither of these hold up to scrutiny.

TZ
Apr 14 2005
prev sibling parent reply Brad Anderson <brad dsource.dot.org> writes:
bobef wrote:
 I am sorry for the rude language but some things have to be said as 

 First I want to ask what does the subject means? The F Word? What is 

 Walter? Fuck D? Fuck this community? Fuck the world? Which of them? 

 joke because only fuck is called the f word but it could be any 

 it is fuck then say it rebel boy! Loudly and proudly. If this is your 

 stand for it. This is not a kids forum after all.

[snip]
 And I am glad Walter keeps to his opinion only. Otherwise D will end 

 linux - a useless bag of SHIT. In matter of fact everyone's shit. Someone
 touches here, someone touches there and it becomes useless. If you 

 useless you have to start over and modify all the software...

[snip]
 This is sick you know. Somebody do something. And someone else makes
 organization to take over his work. And force him to do it not in his 

 Americans could think of such sick crap... Are you americans? Why 

 let Walter do what he believes is best?

So now you want space at dsource.org. It's a good thing I'm a nice F'ing guy. Oh, and btw, bobef, this is a Linux server running in America. Enjoy. BA
May 17 2005
parent John Reimer <brk_6502 yahoo.com> writes:
Brad Anderson wrote:
 
 So now you want space at dsource.org.  It's a good thing I'm a nice 
 F'ing guy.
 
 Oh, and btw, bobef, this is a Linux server running in America.  Enjoy.
 
 BA

You know what, Brad? I think this is a case of "foot-in-the-mouth" for bobef. He had no idea who you were, did he? ;-P He sure didn't help himself here. All I can say is he had it coming. I'm afraid as interesting as his project looks, I quickly got turned off when I started browsing the beginnings of his forum.... Sorry, bobef... wisdom and discretion are important attributes even on the internet. Be careful what you say... - JJR A series of unfortunate events...
May 17 2005
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Brad Anderson wrote:
 Over and over again, it's been proposed that some organization be
 formed to augment Walter's efforts, whether library or lang standard.
 Let me say this carefully:  THIS IS NOT GOING TO HAPPEN.  If it's not
 going to happen, then get David Friedman on board, or do it
 yourselves, but fork the damn language and fix the warts you guys
 want to fix!  If you come up with something better, then maybe Walter
 will want to merge back with you.  When he holds the keys to the
 kingdom, however, the advancement made will not be sufficient in your
 minds.

The thought has increasingly been on my mind too. But I've tried not to take it up. :-)
Apr 14 2005
parent reply bobef <bobef_member pathlink.com> writes:
In article <425E626B.8000602 nospam.org>, Georg Wrede says...
Brad Anderson wrote:
 Over and over again, it's been proposed that some organization be
 formed to augment Walter's efforts, whether library or lang standard.
 Let me say this carefully:  THIS IS NOT GOING TO HAPPEN.  If it's not
 going to happen, then get David Friedman on board, or do it
 yourselves, but fork the damn language and fix the warts you guys
 want to fix!  If you come up with something better, then maybe Walter
 will want to merge back with you.  When he holds the keys to the
 kingdom, however, the advancement made will not be sufficient in your
 minds.

The thought has increasingly been on my mind too. But I've tried not to take it up. :-)

This is sick you know. Somebody do something. And someone else makes organization to take over his work. And force him to do it not in his way. Americans could think of such sick crap... Are you americans? Why don't you just let Walter do what he believes is best? Sorry if my words are too strong or if I missunderstood something...
Apr 14 2005
next sibling parent nod <nod_member pathlink.com> writes:
In article <d3lsgu$vps$1 digitaldaemon.com>, bobef says...
In article <425E626B.8000602 nospam.org>, Georg Wrede says...
Brad Anderson wrote:
 Over and over again, it's been proposed that some organization be
 formed to augment Walter's efforts, whether library or lang standard.
 Let me say this carefully:  THIS IS NOT GOING TO HAPPEN.  If it's not
 going to happen, then get David Friedman on board, or do it
 yourselves, but fork the damn language and fix the warts you guys
 want to fix!  If you come up with something better, then maybe Walter
 will want to merge back with you.  When he holds the keys to the
 kingdom, however, the advancement made will not be sufficient in your
 minds.

The thought has increasingly been on my mind too. But I've tried not to take it up. :-)

This is sick you know. Somebody do something. And someone else makes organization to take over his work. And force him to do it not in his way. Americans could think of such sick crap... Are you americans? Why don't you just let Walter do what he believes is best? Sorry if my words are too strong or if I missunderstood something...

I do think you are misunderstanding and overreacting. The people here seem smart and (mostly) friendly, and would not "take over" Walters or anyone elses work. A fork would be very much less dramatic than you seem to believe. A "fork" could merely be an effort to take some of the weight off Walters (way to burdened imo) shoulders, and give us others a chance to directly impact the language itself. By being an "experimental" spec of the language where features are tested and bugs stamped out, I believe it could only benefit the language (the original one) as a whole . Walter could of course participate, if he chose to, and could merge back features that work out at his own leisure. And "Americans could think of such sick crap"? WTF? I am not from America, and although some Americans are undoubtedly rather arrogant, so are many Europeans. Singling out any group of people based on nationality (or race, or belief) is ignorant, please refrain from this.
Apr 14 2005
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
 Americans could think of such sick crap... Are you americans?

Wow! That's fighting talk, to be sure. I'm not American. I'm an English-Australian. But lots of my friends are American (i.e from the US). Whatever one might think of "America" at the moment, I have to tell you that Americans are, in my experience, extremely kind and friendly people. If your comment has a geo-political influence, then I can see where you're coming from. Unfortunately, I don't see much spitting distance between America and England or America and Australia, so I for one cannot single out America. Same goes for any of the major powers. In fact, apart from Bhutan, I pretty much think every government and political system is a stinking heap of corruption. So I'd advise you keep your broad-brush bias to yourself, as you'll offend individuals who don't deserve it, and have no effect on any governments who might.
Apr 14 2005
prev sibling parent reply "Dave" <Dave_member pathlink.com> writes:
Ok - Let's try and cut through all of the bullshit here. Fork the language, 
C'MON!! Sounds like a slow and sure death to me.

Don't get me wrong Brad, I do appreciate that the threat of the 'F-word' is 
sometimes needed to get things moving, especially since some very talented 
and smart people seem to be at an impass here, but F'ing D now really would, 
well "F" D for good, IMO.

Below is what I propose should be done.. I apologize beforehand if I hurt 
any feelings here by leaving people out (many of you have put a lot of 
effort into building/testing/fixing things, and all of it is valued), or by 
putting five people on the spot.

Matthew, Kris, Ben and David Friedman:

From your posts, I can surmise that the first three have:
1) All done serious library development with D.
2) Been the most substantively vocal on D language issues.
3) All worked extensively with a lot of applications done w/ other 
languages.

And of course you, David, have actually implemented another working D 
compiler.

What I would suggest is each list their top 3 (and only 3) shortcomings of 
the D language itself (not bugs, not library). Keep it short and number the 
issues please.

Then, I suggest that out of these 12 submissions, 6 could be agreed upon by 
you four as top priority and something that would make sense for compiler 
developers. There may well be some overlap in the original 12 and the idea 
is to boil things down to a handful of the most important issues.

I figure once the language spec. is solid enough for major library and 
compiler development, fixing compiler bugs and fixing/developing the library 
will more easily follow.

Is this something that could be of any value?? If so, who will start?

Once it is done, there will be 6 major issues for Walter to (hopefully) 
focus and comment on, even that comment happens to be "get F'd".

- Dave

(I cross-posted to D.gnu because that seems relevant here).

"Brad Anderson" <brad dsource.dot.org> wrote in message 
news:d3l33k$6fr$1 digitaldaemon.com...
Speaking for myself, I've certainly become far grumpier of late. It
seems I take a break due to some pointless/bad experience, and
foreswear any such future behaviour on my part or being sucked into
fatuous debates by others, and yet within a couple of days of
'coming back' it's happening again. Needless to say, I find this
truly uncharacteristic - honest! <G> - behaviour of mine both
appalling and intriguing. (I often think how embarrassed I'll be if
my sons become software engineers and go and look up some of their
cranky old fart of a father's semi-lucid ranting and pompous
condescension.)

I'm totally with you, since I find the same thing happening.

Something's gotta change. I hope it'll be something organisationally with D, but I suspect it'll be my conscience making me leave in response to increasing number of reasonable complaints about my curmudgeon. :-(

This would truly be a shame. The way a technology advances, IMO, is the conflict resolution between knowledgeable, passionate, and boisterous people who are fully engaged in the birthing of the technology. If the conflict is fully vetted, and reasonable compromises can be made, in addition to minds being kept open to future change, then advancement is realized. I hate to name names, and forgive me if I've omitted you, but for D and this NG to lose the voices of Matthew, Kris, Sean and others would be a HUGE loss. They've already been quiet recently as it is. This is a direct result of Walter not finding compromise or recognizing the value of other expert opinions that may differ from his own. Not sure who said this, but maybe ESR? and it's paraphrased... "Thrill your users. At first, it will be the early adopters. Make the experts / power users happy..." This would be a bit more powerful from someone writing a lot of D code on a consistent basis, but I've lurked for 2+ years, and have seen smart people jump up and volunteer some great ideas. I don't care if they get shot down ... to a point. Some of them are now gone because of the problem noted above. Over and over again, it's been proposed that some organization be formed to augment Walter's efforts, whether library or lang standard. Let me say this carefully: THIS IS NOT GOING TO HAPPEN. If it's not going to happen, then get David Friedman on board, or do it yourselves, but fork the damn language and fix the warts you guys want to fix! If you come up with something better, then maybe Walter will want to merge back with you. When he holds the keys to the kingdom, however, the advancement made will not be sufficient in your minds. One effort that holds my respect is Ares, because it's the only thing those guys can do to compensate for their perceived shortcomings of Phobos. Even if they've stopped (slowed) participating in the NG, they are still coding that lib. Compiler warts and all. It's all that they can control. <somewhat-random-tangent> If none of this works, and you truly want to leave D, then come join me in the world of Common Lisp. Talk about a powerful language devoid of lots of the warts you speak of. (btw, don't tell me it's interpreted, slow, full of parentheses, and its developers talk funny. All of that's bull, except for the parens, and they're manageable.) All of the Design Patterns you OO guys work with daily are basically to make up for Java/C/C++/D's lack of late binding, and there's nothing like the macros or closures in Lisp. </somewhat-random-tangent> I have learned a ton from this NG, watching the more experienced developers debate, and firmly believe that D would be worse off without the powerful voices that chime in regularly. But I empathize with them in their frustration to affect change recently (i.e. before 1.0). WTF, Walter? Don't answer my post. Answer theirs... And if he doesn't answer, boys, go ahead and fork it. There has to be some way to affect change and realize the great promise that keeps you coming back to the current quagmire. BA

Apr 14 2005
next sibling parent reply brad domain.invalid writes:
Dave wrote:
<SNIP>
 Then, I suggest that out of these 12 submissions, 6 could be agreed upon by 
 you four as top priority and something that would make sense for compiler 
 developers. There may well be some overlap in the original 12 and the idea 
 is to boil things down to a handful of the most important issues.
 
 I figure once the language spec. is solid enough for major library and 
 compiler development, fixing compiler bugs and fixing/developing the library 
 will more easily follow.
 
 Is this something that could be of any value?? If so, who will start?
 
 Once it is done, there will be 6 major issues for Walter to (hopefully) 
 focus and comment on, even that comment happens to be "get F'd".
 
 - Dave
 

is too strong of a word, but an open group that tinkers with features they'd like to see in D - that sounds like a plan. It sounds like a lot of work, but I am sure that most features could be implemented in less lines than the arguments that happen on this NG :) Brad
Apr 14 2005
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
<brad domain.invalid> wrote in message news:d3ml1c$1p77$1 digitaldaemon.com...
 Dave wrote:
 <SNIP>
 Then, I suggest that out of these 12 submissions, 6 could be agreed upon by
you four as top priority and something 
 that would make sense for compiler developers. There may well be some overlap
in the original 12 and the idea is to 
 boil things down to a handful of the most important issues.

 I figure once the language spec. is solid enough for major library and
compiler development, fixing compiler bugs and 
 fixing/developing the library will more easily follow.

 Is this something that could be of any value?? If so, who will start?

 Once it is done, there will be 6 major issues for Walter to (hopefully) focus
and comment on, even that comment 
 happens to be "get F'd".

 - Dave

that tinkers with features they'd like to see in D - that sounds like a plan. It sounds like a lot of work, but I am sure that most features could be implemented in less lines than the arguments that happen on this NG :)

I'd be keen to get hold of the necessary stuff to be able to effect changes to the language and try them out. Can anyone summarise the steps to do this? I'd prefer Win32, but can live with doing it on Linux.
Apr 14 2005
next sibling parent brad domain.invalid writes:
 
 I'd be keen to get hold of the necessary stuff to be able to effect changes to
the language and try them out. Can anyone 
 summarise the steps to do this? I'd prefer Win32, but can live with doing it
on Linux.
 
 
 

follow the instructions and see how far you get. I've managed to build GDC on x86 Linux and MacOSX with little trouble & a cross compiled ARM version with a little more trouble. I don't see why a Cygwin build couldn't be fought with and made to work - but the easiest out of the box behaviour will be x86 Linux I think. If you run into problems the D.gnu list has helpful people in it. Brad
Apr 14 2005
prev sibling next sibling parent pragma <pragma_member pathlink.com> writes:
In article <d3mlf1$1pkj$5 digitaldaemon.com>, Matthew says...
<brad domain.invalid> wrote in message news:d3ml1c$1p77$1 digitaldaemon.com...
 Dave wrote:
 <SNIP>
 Then, I suggest that out of these 12 submissions, 6 could be agreed upon by
you four as top priority and something 
 that would make sense for compiler developers. There may well be some overlap
in the original 12 and the idea is to 
 boil things down to a handful of the most important issues.

 I figure once the language spec. is solid enough for major library and
compiler development, fixing compiler bugs and 
 fixing/developing the library will more easily follow.

 Is this something that could be of any value?? If so, who will start?

 Once it is done, there will be 6 major issues for Walter to (hopefully) focus
and comment on, even that comment 
 happens to be "get F'd".

 - Dave

that tinkers with features they'd like to see in D - that sounds like a plan. It sounds like a lot of work, but I am sure that most features could be implemented in less lines than the arguments that happen on this NG :)

I'd be keen to get hold of the necessary stuff to be able to effect changes to the language and try them out. Can anyone summarise the steps to do this? I'd prefer Win32, but can live with doing it on Linux.

As far as I know you'd have to go with GDC on top of Cygwin if you want to continue to run windows. If you mean "compiles and links against win32", then I think we're all out of luck. - EricAnderton at yahoo
Apr 14 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Matthew wrote:
 <brad domain.invalid> wrote in message
 news:d3ml1c$1p77$1 digitaldaemon.com...
 
 Dave wrote: <SNIP>
 
 Then, I suggest that out of these 12 submissions, 6 could be
 agreed upon by you four as top priority and something that would
 make sense for compiler developers. There may well be some
 overlap in the original 12 and the idea is to boil things down to
 a handful of the most important issues.
 
 I figure once the language spec. is solid enough for major
 library and compiler development, fixing compiler bugs and 
 fixing/developing the library will more easily follow.
 
 Is this something that could be of any value?? If so, who will
 start?
 
 Once it is done, there will be 6 major issues for Walter to
 (hopefully) focus and comment on, even that comment happens to be
 "get F'd".
 
 - Dave
 

I think this is the best idea I've heard in a long long time. Fork IMHO is too strong of a word, but an open group that tinkers with features they'd like to see in D - that sounds like a plan. It sounds like a lot of work, but I am sure that most features could be implemented in less lines than the arguments that happen on this NG :)

I'd be keen to get hold of the necessary stuff to be able to effect changes to the language and try them out. Can anyone summarise the steps to do this? I'd prefer Win32, but can live with doing it on Linux.

Even better, maybe someone could create a TinkeringDistro ?
Apr 15 2005
prev sibling next sibling parent pragma <pragma_member pathlink.com> writes:
In article <d3ml1c$1p77$1 digitaldaemon.com>, brad domain.invalid says...
It sounds like a lot 
of work, but I am sure that most features could be implemented in less 
lines than the arguments that happen on this NG :)

I'll add that not only would it take less lines, but it would take less time too. Even if Walter could implement compiler changes three times as fast as the average developer here, four or more people on a single task could out pace him. Multiply that by three or so task-teams and you have a similar increase in productivity, and a similar reduction in time-to-concept. Furthermore, you only need *one* language-addendum project to be accepted for inclusion to D, at such a team size to call the exercise a success. Since in theory, they arrived at a solution faster than Walter ever could have. - EricAnderton at yahoo
Apr 14 2005
prev sibling parent nod <nod_member pathlink.com> writes:
In article <d3ml1c$1p77$1 digitaldaemon.com>, brad domain.invalid says...
I think this is the best idea I've heard in a long long time.  Fork IMHO 
is too strong of a word, but an open group that tinkers with features 
they'd like to see in D - that sounds like a plan.  It sounds like a lot 
of work, but I am sure that most features could be implemented in less 
lines than the arguments that happen on this NG :)

Brad

I would like to see this! I know I am a bit of a newbie on these newsgroups, so I an not sure people will even listen to me. I will try anyways though because as the rest of you all, I too like the D language and would love to see it become the great language it has the potential to become. So, instead of bickering about whether this is a good idea or not, I say we try it out. I will now start "The GDC Hackers Guild", a place for us who want to try and help Walter out more than by just giving opinions. I have made a page for it on the wiki4d (see link below), but I hope we can create our own homepage, because I believe that infrastructure and communication is important. For now though, well make do with the D.gnu NG and the wiki. The first thing we need to do is to learn to hack the GDC sources, and try and help David out. I am not very strong at this myself, but I believe that we can do it if we help eachother out. When we get somewhat acquainted with the sources, we may want to start adding some features... but lets take it one step at a time. :) For myself, I will try to start creating some infrastructure, and helping out... If anyone wants help getting GDC installed (or linux for that matter) please dont hesitate to ask in the D.gnu newsgroup. Only the best of intentions -Nod- (linky: http://www.prowiki.org/wiki4d/wiki.cgi?GdcHacking ) (ps, I added a link to the frontpage too, if no one objects...)
Apr 14 2005
prev sibling next sibling parent reply John Reimer <John_member pathlink.com> writes:
*sigh*  More useless advice... more advice along the same lines that's been
offered many times before.  This is so wearisome.  It would be better to just
admit that you don't agree with these guys than to try to offer the /same/
solution that has been the very basis for these guys frustrations with the
current system.

I apologize if this comes out too strongly, but what makes you think that Kris,
Matthew and others haven't done similar to your suggestion many times before?
Why do you suppose Walter might be so inclined to agree to there "top" listed
suggestions now if he hasn't in the past? This /is/ the very problem!

As benevolent as Walter has been with putting such a wonderful effort into the D
language, I doubt the language can ever completely "break out" until he realizes
it will eventually have to be opened up to more outside influence...someday,
sometime.  He can do it gradually, but I think it's inevitable for D's success
for many of the reasons already discribed. Many, many suggestions on how and why
this should happen have been put forth numerous times.

Morever, this kind of topic seems to make it's rounds multiple times during the
year with what looks like an approaching critical mass on the horizon.

I don't know if forking is the solution, but I can really understand why the
temptation to do so is there.  D could collapse whether or not a fork is
initiated.

I should really have shutup.  Becoming a lurker on the list is getting to become
more attractive occupation all the time. :-(

- JJR

PS  The exasperation of these few should not be constrewed as lack of
appreciation to Walter for all that he's done.  Everyone /wants/ D to succeed,
and Walter with it.  The motivation behind the criticism is really a deep desire
to see D succeed in a /big/ way, rather than fade into proprietary nothingness
which I fear is the current direction D's taking.


In article <d3mh30$1lbv$1 digitaldaemon.com>, Dave says...
Ok - Let's try and cut through all of the bullshit here. Fork the language, 
C'MON!! Sounds like a slow and sure death to me.

Don't get me wrong Brad, I do appreciate that the threat of the 'F-word' is 
sometimes needed to get things moving, especially since some very talented 
and smart people seem to be at an impass here, but F'ing D now really would, 
well "F" D for good, IMO.

Below is what I propose should be done.. I apologize beforehand if I hurt 
any feelings here by leaving people out (many of you have put a lot of 
effort into building/testing/fixing things, and all of it is valued), or by 
putting five people on the spot.

Matthew, Kris, Ben and David Friedman:

From your posts, I can surmise that the first three have:
1) All done serious library development with D.
2) Been the most substantively vocal on D language issues.
3) All worked extensively with a lot of applications done w/ other 
languages.

And of course you, David, have actually implemented another working D 
compiler.

What I would suggest is each list their top 3 (and only 3) shortcomings of 
the D language itself (not bugs, not library). Keep it short and number the 
issues please.

Then, I suggest that out of these 12 submissions, 6 could be agreed upon by 
you four as top priority and something that would make sense for compiler 
developers. There may well be some overlap in the original 12 and the idea 
is to boil things down to a handful of the most important issues.

I figure once the language spec. is solid enough for major library and 
compiler development, fixing compiler bugs and fixing/developing the library 
will more easily follow.

Is this something that could be of any value?? If so, who will start?

Once it is done, there will be 6 major issues for Walter to (hopefully) 
focus and comment on, even that comment happens to be "get F'd".

- Dave

(I cross-posted to D.gnu because that seems relevant here).

"Brad Anderson" <brad dsource.dot.org> wrote in message 
news:d3l33k$6fr$1 digitaldaemon.com...
Speaking for myself, I've certainly become far grumpier of late. It
seems I take a break due to some pointless/bad experience, and
foreswear any such future behaviour on my part or being sucked into
fatuous debates by others, and yet within a couple of days of
'coming back' it's happening again. Needless to say, I find this
truly uncharacteristic - honest! <G> - behaviour of mine both
appalling and intriguing. (I often think how embarrassed I'll be if
my sons become software engineers and go and look up some of their
cranky old fart of a father's semi-lucid ranting and pompous
condescension.)

I'm totally with you, since I find the same thing happening.

Something's gotta change. I hope it'll be something organisationally with D, but I suspect it'll be my conscience making me leave in response to increasing number of reasonable complaints about my curmudgeon. :-(

This would truly be a shame. The way a technology advances, IMO, is the conflict resolution between knowledgeable, passionate, and boisterous people who are fully engaged in the birthing of the technology. If the conflict is fully vetted, and reasonable compromises can be made, in addition to minds being kept open to future change, then advancement is realized. I hate to name names, and forgive me if I've omitted you, but for D and this NG to lose the voices of Matthew, Kris, Sean and others would be a HUGE loss. They've already been quiet recently as it is. This is a direct result of Walter not finding compromise or recognizing the value of other expert opinions that may differ from his own. Not sure who said this, but maybe ESR? and it's paraphrased... "Thrill your users. At first, it will be the early adopters. Make the experts / power users happy..." This would be a bit more powerful from someone writing a lot of D code on a consistent basis, but I've lurked for 2+ years, and have seen smart people jump up and volunteer some great ideas. I don't care if they get shot down ... to a point. Some of them are now gone because of the problem noted above. Over and over again, it's been proposed that some organization be formed to augment Walter's efforts, whether library or lang standard. Let me say this carefully: THIS IS NOT GOING TO HAPPEN. If it's not going to happen, then get David Friedman on board, or do it yourselves, but fork the damn language and fix the warts you guys want to fix! If you come up with something better, then maybe Walter will want to merge back with you. When he holds the keys to the kingdom, however, the advancement made will not be sufficient in your minds. One effort that holds my respect is Ares, because it's the only thing those guys can do to compensate for their perceived shortcomings of Phobos. Even if they've stopped (slowed) participating in the NG, they are still coding that lib. Compiler warts and all. It's all that they can control. <somewhat-random-tangent> If none of this works, and you truly want to leave D, then come join me in the world of Common Lisp. Talk about a powerful language devoid of lots of the warts you speak of. (btw, don't tell me it's interpreted, slow, full of parentheses, and its developers talk funny. All of that's bull, except for the parens, and they're manageable.) All of the Design Patterns you OO guys work with daily are basically to make up for Java/C/C++/D's lack of late binding, and there's nothing like the macros or closures in Lisp. </somewhat-random-tangent> I have learned a ton from this NG, watching the more experienced developers debate, and firmly believe that D would be worse off without the powerful voices that chime in regularly. But I empathize with them in their frustration to affect change recently (i.e. before 1.0). WTF, Walter? Don't answer my post. Answer theirs... And if he doesn't answer, boys, go ahead and fork it. There has to be some way to affect change and realize the great promise that keeps you coming back to the current quagmire. BA


Apr 14 2005
next sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <d3mo3u$1s66$1 digitaldaemon.com>, John Reimer says...
*sigh*  More useless advice... more advice along the same lines that's been
offered many times before.  This is so wearisome.  It would be better to just
admit that you don't agree with these guys than to try to offer the /same/
solution that has been the very basis for these guys frustrations with the
current system.

I really don't have a stand on any of the issues in this thread, because, frankly, I just jumped in when I saw the 'F-word' branch.
I apologize if this comes out too strongly, but what makes you think that Kris,
Matthew and others haven't done similar to your suggestion many times before?
Why do you suppose Walter might be so inclined to agree to there "top" listed
suggestions now if he hasn't in the past? This /is/ the very problem!

I recognize the problem. But I also recognize that Walter (or anyone) would need some sort of priority list to work from. That is damn hard to get when you have people figuratively screaming at you from all directions in a forum like this. I just tried to put forth something I really haven't seen detailed before. Mentioned maybe, but not detailed. Specifically that these four guys, who have used D extensively, put in 3 suggestions each - in one place as it were - to try and get the ball rolling rather than endlessly arguing point/counter-point. I've agreed with these people on past issues while disagreeing with Walter and vice-versa. This is not about defending Walter's decision making process, it's about getting the most out of D w/o fragmenting the group in some way. I will gladly defer to what Kris, Matthew, Ben and David Friedman come up with simply because they have used the language more and for more intensive stuff than I have. Bluntly, this was an attempt to get Walter to listen to them. I think a well reasoned, concise list from such power users would be something usable. If it is well done, makes sense and is demonstrably better for the language and /then/ Walter doesn't implement them because of some personal choice, fork away. As it has been to date, once a complaint/proposal is made, the thread more often than not goes off into la-la land somewhere where it is hard for anyone to figure out if any conclusion was arrived at, much less what the conclusion is. The way it stands right now, a fork would be a disaster because often times the people talking about doing the fork can't even agree amongst themselves what should be in the fork. And often times there would end-up being another 'Walter' to lynch 6 months down the road with the fork once 'the group' see's 'the leader' as a threat to their personal preferences. And then both D and the 'community' would be further fragmented. See, most of these issues are not something that can be proven demonstrably better by building another compiler (forking) because they are, in the final analysis, subjective. Therefore you have to push the changes through by some sort of concensus, as bad as that sounds. I should have known.. The only one who could successfully get a list effort like this going would have been Walter himself. But I figured it was worth a shot anyhow. - Dave
Apr 14 2005
next sibling parent John Reimer <John_member pathlink.com> writes:
An excellent, clear-headed response, Dave. Thanks for taking the time to write
it.  I understand where you are coming from now.  It was good to get your
perspective clarified.  I'll choose not to continue on this topic, though, since
I'm more than a little weary of it.

-JJR

In article <d3mrrt$1v94$1 digitaldaemon.com>, Dave says...
In article <d3mo3u$1s66$1 digitaldaemon.com>, John Reimer says...
*sigh*  More useless advice... more advice along the same lines that's been
offered many times before.  This is so wearisome.  It would be better to just
admit that you don't agree with these guys than to try to offer the /same/
solution that has been the very basis for these guys frustrations with the
current system.

I really don't have a stand on any of the issues in this thread, because, frankly, I just jumped in when I saw the 'F-word' branch.
I apologize if this comes out too strongly, but what makes you think that Kris,
Matthew and others haven't done similar to your suggestion many times before?
Why do you suppose Walter might be so inclined to agree to there "top" listed
suggestions now if he hasn't in the past? This /is/ the very problem!

I recognize the problem. But I also recognize that Walter (or anyone) would need some sort of priority list to work from. That is damn hard to get when you have people figuratively screaming at you from all directions in a forum like this. I just tried to put forth something I really haven't seen detailed before. Mentioned maybe, but not detailed. Specifically that these four guys, who have used D extensively, put in 3 suggestions each - in one place as it were - to try and get the ball rolling rather than endlessly arguing point/counter-point. I've agreed with these people on past issues while disagreeing with Walter and vice-versa. This is not about defending Walter's decision making process, it's about getting the most out of D w/o fragmenting the group in some way. I will gladly defer to what Kris, Matthew, Ben and David Friedman come up with simply because they have used the language more and for more intensive stuff than I have. Bluntly, this was an attempt to get Walter to listen to them. I think a well reasoned, concise list from such power users would be something usable. If it is well done, makes sense and is demonstrably better for the language and /then/ Walter doesn't implement them because of some personal choice, fork away. As it has been to date, once a complaint/proposal is made, the thread more often than not goes off into la-la land somewhere where it is hard for anyone to figure out if any conclusion was arrived at, much less what the conclusion is. The way it stands right now, a fork would be a disaster because often times the people talking about doing the fork can't even agree amongst themselves what should be in the fork. And often times there would end-up being another 'Walter' to lynch 6 months down the road with the fork once 'the group' see's 'the leader' as a threat to their personal preferences. And then both D and the 'community' would be further fragmented. See, most of these issues are not something that can be proven demonstrably better by building another compiler (forking) because they are, in the final analysis, subjective. Therefore you have to push the changes through by some sort of concensus, as bad as that sounds. I should have known.. The only one who could successfully get a list effort like this going would have been Walter himself. But I figured it was worth a shot anyhow. - Dave

Apr 14 2005
prev sibling parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Personally, I thought it was a good suggestion and was very articulately
presented.  Sure, there are many variations on it that may be equally
effective, and sure there's the possibility that it's already been tried, but
it was in my opinion a good suggestion regardless.

TechnoZeus

"Dave" <Dave_member pathlink.com> wrote in message
news:d3mrrt$1v94$1 digitaldaemon.com...
 In article <d3mo3u$1s66$1 digitaldaemon.com>, John Reimer says...
*sigh*  More useless advice... more advice along the same lines that's been
offered many times before.  This is so wearisome.  It would be better to just
admit that you don't agree with these guys than to try to offer the /same/
solution that has been the very basis for these guys frustrations with the
current system.

I really don't have a stand on any of the issues in this thread, because, frankly, I just jumped in when I saw the 'F-word' branch.
I apologize if this comes out too strongly, but what makes you think that Kris,
Matthew and others haven't done similar to your suggestion many times before?
Why do you suppose Walter might be so inclined to agree to there "top" listed
suggestions now if he hasn't in the past? This /is/ the very problem!

I recognize the problem. But I also recognize that Walter (or anyone) would need some sort of priority list to work from. That is damn hard to get when you have people figuratively screaming at you from all directions in a forum like this. I just tried to put forth something I really haven't seen detailed before. Mentioned maybe, but not detailed. Specifically that these four guys, who have used D extensively, put in 3 suggestions each - in one place as it were - to try and get the ball rolling rather than endlessly arguing point/counter-point. I've agreed with these people on past issues while disagreeing with Walter and vice-versa. This is not about defending Walter's decision making process, it's about getting the most out of D w/o fragmenting the group in some way. I will gladly defer to what Kris, Matthew, Ben and David Friedman come up with simply because they have used the language more and for more intensive stuff than I have. Bluntly, this was an attempt to get Walter to listen to them. I think a well reasoned, concise list from such power users would be something usable. If it is well done, makes sense and is demonstrably better for the language and /then/ Walter doesn't implement them because of some personal choice, fork away. As it has been to date, once a complaint/proposal is made, the thread more often than not goes off into la-la land somewhere where it is hard for anyone to figure out if any conclusion was arrived at, much less what the conclusion is. The way it stands right now, a fork would be a disaster because often times the people talking about doing the fork can't even agree amongst themselves what should be in the fork. And often times there would end-up being another 'Walter' to lynch 6 months down the road with the fork once 'the group' see's 'the leader' as a threat to their personal preferences. And then both D and the 'community' would be further fragmented. See, most of these issues are not something that can be proven demonstrably better by building another compiler (forking) because they are, in the final analysis, subjective. Therefore you have to push the changes through by some sort of concensus, as bad as that sounds. I should have known.. The only one who could successfully get a list effort like this going would have been Walter himself. But I figured it was worth a shot anyhow. - Dave

Apr 14 2005
parent reply John Reimer <John_member pathlink.com> writes:
In article <d3mtl8$20v8$1 digitaldaemon.com>, TechnoZeus says...
Personally, I thought it was a good suggestion and was very articulately
presented.  Sure, there are many variations on it that may be equally
effective, and sure there's the possibility that it's already been tried, but
it was in my opinion a good suggestion regardless.

TechnoZeus

Then you didn't understand the context of my complaint at all... probably as a result of not being around this group over the last 2 years (or perhaps you have, and I haven't noticed). This kind of a suggestion is not new, nor is it exceedingly original in comparison to past suggestions. Nor does my assessment of Dave's response have anything to do with his level of articulation in the post: I have no issue with his delivery abilities (that would be pretty stupid of me to pick on). A suggestion is only useful if it solves the original problem. Since his did not, nor did it present something new, thus my conclusion and frustration. People have listed wonderfully organized priority items in the past that have done little to influence Walter's own priority list. When people continue to repeat old suggestions for old problems, admittedly quite innocently and in a slightly different format, no amount of articulation can make the idea savoury. It's like dumping salt on fleshy, open wound. It's even more annoying when people come by and say, "why that's a wonderful idea!" as if it were that rare sought after solution to the whole problem. (my apologies for griping on this) :-( Dave was right in his final assessment (and a good one): "I should have known.. The only one who could successfully get a list effort like this going would have been Walter himself" Unfortuantely, though, objectivity in the list making in this situation would be even harder from one man's experience. But nonetheless Dave clarified his reasoning in his last post, enough for me to respect his perspective. Whether or not, I agree with him is irrelevent. Incidently, it's not likely you will notice Walter responding to any of these "suggestions" in this topic. -JJR
Apr 14 2005
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"John Reimer" <John_member pathlink.com> wrote in message 
news:d3nes9$2e9d$1 digitaldaemon.com...
 In article <d3mtl8$20v8$1 digitaldaemon.com>, TechnoZeus says...
Personally, I thought it was a good suggestion and was very 
articulately presented.  Sure, there are many variations on it 
that may be equally effective, and sure there's the possibility 
that it's already been tried, but it was in my opinion a good 
suggestion regardless.

TechnoZeus

Then you didn't understand the context of my complaint at all... probably as a result of not being around this group over the last 2 years (or perhaps you have, and I haven't noticed). This kind of a suggestion is not new, nor is it exceedingly original in comparison to past suggestions. Nor does my assessment of Dave's response have anything to do with his level of articulation in the post: I have no issue with his delivery abilities (that would be pretty stupid of me to pick on). A suggestion is only useful if it solves the original problem. Since his did not, nor did it present something new, thus my conclusion and frustration. People have listed wonderfully organized priority items in the past that have done little to influence Walter's own priority list. When people continue to repeat old suggestions for old problems, admittedly quite innocently and in a slightly different format, no amount of articulation can make the idea savoury. It's like dumping salt on fleshy, open wound. It's even more annoying when people come by and say, "why that's a wonderful idea!" as if it were that rare sought after solution to the whole problem. (my apologies for griping on this) :-( Dave was right in his final assessment (and a good one): "I should have known.. The only one who could successfully get a list effort like this going would have been Walter himself" Unfortuantely, though, objectivity in the list making in this situation would be even harder from one man's experience. But nonetheless Dave clarified his reasoning in his last post, enough for me to respect his perspective. Whether or not, I agree with him is irrelevent. Incidently, it's not likely you will notice Walter responding to any of these "suggestions" in this topic.

Well, now I really am pessimistic. John's always been the very opposite in temperament to the GOM, but those who know him will recognise in these last couple of posts a degree of impatience and irritation that's quite new. I take this as a sign that the frustration is not only not being rectified in its source(s), but is in fact spreading and reinforcing. :-( Matthew P.S. I agree with what you've said, btw, John
Apr 14 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Matthew wrote:
 "John Reimer" <John_member pathlink.com> wrote in message 
 news:d3nes9$2e9d$1 digitaldaemon.com...
 
In article <d3mtl8$20v8$1 digitaldaemon.com>, TechnoZeus says...


Incidently, it's not likely you will notice Walter responding to 
any of these
"suggestions" in this topic.

Well, now I really am pessimistic. John's always been the very opposite in temperament to the GOM, but those who know him will recognise in these last couple of posts a degree of impatience and irritation that's quite new. I take this as a sign that the frustration is not only not being rectified in its source(s), but is in fact spreading and reinforcing. :-( Matthew P.S. I agree with what you've said, btw, John

If I have any clue of what's going on, it's this: Walter is currently working 80-hour weeks to get the next DMD out, presumably even a release candidate. This precludes him from even reading this newsgroup -- where most of the stuff is about "we need this too in 1.0, and it's urgent" or "We absolutely need this Grand Feature for 2.0". (Of which I'm pretty guilty myself!) (BTW, this particular NG _is_ for these things, so it's ok to do that. ;-) ) All, that reading this NG would produce, is just distraction for him -- from the very work we all want him to do. (Some of us even seem to want him do that like 100 hours per week.) Of course this ultimately leads to frustration: "he's not commenting, dammit he's not even listening". Having understood this, there's an even more frustrating thing: when he'll eventually come out from his chamber, he'll have such a pile of messages to catch up, that the chances of even the BEST suggestions _ever_ reachim are slim. Oh, well. There's a time for everything. Maybe I'll defer my new great ideas till after summer. Thus, maybe this really is the time to go tinkering instead. I've already promised to tinker with metalanguage and a tool explicitly for language tinkering.
Apr 15 2005
prev sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
I understood the context.  You're right that I haven't been here to see where
that context came from, but I understood it quite well.  My opinion remains
though that it was a good suggestion.  If someone tells a kid to look both ways
before crossing the street, it's not any less of a good idea just because
they've been told before.  If someone shows kindness to a stranger, it's not
any less of a good deed just because they have done it before.  The context
doesn't, in my opinion, reduce the validity of the facts.  A good suggestion is
still a good suggestion, no matter how many times it gets repeated.  Maybe
eventually it will sink in, and pay off.

TZ

"John Reimer" <John_member pathlink.com> wrote in message
news:d3nes9$2e9d$1 digitaldaemon.com...
 In article <d3mtl8$20v8$1 digitaldaemon.com>, TechnoZeus says...
Personally, I thought it was a good suggestion and was very articulately
presented.  Sure, there are many variations on it that may be equally
effective, and sure there's the possibility that it's already been tried, but
it was in my opinion a good suggestion regardless.

TechnoZeus

Then you didn't understand the context of my complaint at all... probably as a result of not being around this group over the last 2 years (or perhaps you have, and I haven't noticed). This kind of a suggestion is not new, nor is it exceedingly original in comparison to past suggestions. Nor does my assessment of Dave's response have anything to do with his level of articulation in the post: I have no issue with his delivery abilities (that would be pretty stupid of me to pick on). A suggestion is only useful if it solves the original problem. Since his did not, nor did it present something new, thus my conclusion and frustration. People have listed wonderfully organized priority items in the past that have done little to influence Walter's own priority list. When people continue to repeat old suggestions for old problems, admittedly quite innocently and in a slightly different format, no amount of articulation can make the idea savoury. It's like dumping salt on fleshy, open wound. It's even more annoying when people come by and say, "why that's a wonderful idea!" as if it were that rare sought after solution to the whole problem. (my apologies for griping on this) :-( Dave was right in his final assessment (and a good one): "I should have known.. The only one who could successfully get a list effort like this going would have been Walter himself" Unfortuantely, though, objectivity in the list making in this situation would be even harder from one man's experience. But nonetheless Dave clarified his reasoning in his last post, enough for me to respect his perspective. Whether or not, I agree with him is irrelevent. Incidently, it's not likely you will notice Walter responding to any of these "suggestions" in this topic. -JJR

Apr 15 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Good to hear from you too! It's been a while since I last noticed a post 
by you.

John Reimer wrote:
 As benevolent as Walter has been with putting such a wonderful effort
 into the D language, I doubt the language can ever completely "break
 out" until he realizes it will eventually have to be opened up to
 more outside influence...someday, sometime.  He can do it gradually,
 but I think it's inevitable for D's success for many of the reasons
 already discribed. Many, many suggestions on how and why this should
 happen have been put forth numerous times.

Yes. That'll happen, period. It's not like any of (us+Walter) even together _could_ change that fact. That's just the way things go. We might delay this with 6 to 12 months, with a lot of effort, but eventually that'll happen. With or without us. Besides Walter knows it too.
 Morever, this kind of topic seems to make it's rounds multiple times
 during the year with what looks like an approaching critical mass on
 the horizon.
 
 I don't know if forking is the solution, but I can really understand
 why the temptation to do so is there.  D could collapse whether or
 not a fork is initiated.
 
 I should really have shutup.  Becoming a lurker on the list is
 getting to become more attractive occupation all the time. :-(
 
 - JJR
 
 PS  The exasperation of these few should not be constrewed as lack of
  appreciation to Walter for all that he's done.  Everyone /wants/ D
 to succeed, and Walter with it.  The motivation behind the criticism
 is really a deep desire to see D succeed in a /big/ way, rather than
 fade into proprietary nothingness which I fear is the current
 direction D's taking.

Euphoria is a good example of that having happened. Even if the language has many stunning features, and is as nice to work with as D. And even when Rob hasn't done things "wrong" in so many specific ways. (IMHO) (Not that I'd be blaming Walter either for having done "wrong"!) Euphoria is growing, but the world is growing faster. So, relatively speaking, it's falling "into proprietary nothingness". And the window of opportunity may be going out of scope.
 In article <d3mh30$1lbv$1 digitaldaemon.com>, Dave says...
 
 Ok - Let's try and cut through all of the bullshit here. Fork the
 language, C'MON!! Sounds like a slow and sure death to me.
 
 Don't get me wrong Brad, I do appreciate that the threat of the
 'F-word' is sometimes needed to get things moving, especially since
 some very talented and smart people seem to be at an impass here,
 but F'ing D now really would, well "F" D for good, IMO.


IMHO, a big fork would be a serious risk. But 200 small forks -- none of which aspire to "take over" might be good. (I get my kids to help me with house cleaning. I let them choose what they want to do. Works well. One maybe carries trash, another checks for toys under the piano before I vacuum, etc. Even the smallest contribution is welcome by me, and I show it.) ---- A dream come true (for me, at least) would be a D distro that you just download and run make install. (Or whatever Windows equivalent.) It would be recompilable "with a click of a button", so to speak. One would start by, say, making a new keyword into the language and recompiling: "make recompileD". (There'd be a mini-howto on how to make a helloWord. Pun intended.) Then one could just test the new thing (say a keyword foo that does something trivial, just to show to oneself that it can be done). ---- Loads of people could this way get up and running with doing lab experiments, presumably first with their pet peeves: - So get rid of === - create isnot, and see if it really is useful (by then writing programs for this "my_modified_D".) - ask guys what small things you could try to fix - if you're lucky and get some done, send them (to Walter? or to the dSource CVS, i dunno right now) - maybe try a total separation of reference and value equality tests - [your dream here] - ... etc. The Bazaar, indeed! ----- This package would contain Thomas' stress suite, and running it on the "my_new_D_compiler_of_the_day" would be trivial "right out of the box". The more industrious and capable could get up and running wit ambitious things, and those at the other end might want to find typos in compiler error messages, or some such "non hairy", to begin with. And, possibly a lot of folks would start tuning Phobos instead of breaking the compiler. :-) ----- Many small forks give a huge meal. :-)
Apr 15 2005
prev sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Well, it would be of no use to me personally at this time, and I'm not one of
the people that you mentioned, but in my opinion if there was to be one thing
that I could somehow get added to or changed in the DMD compiler, it would be
the addition of interfaces that would allow programmers to write DLLs that
could add to or supercede functionality within D at the lowest level reasonably
possible.  That would allow opinions to be tested and evidence of what "else"
is worth adding or changing to be produced in tangable form, and it would also
provide a way to allow Walter to delegate some of the workload, as well as
allowing the D community to delegate some of it for him and submit their
results for his aproval and possible internal integration.

TechnoZeus

"Dave" <Dave_member pathlink.com> wrote in message
news:d3mh30$1lbv$1 digitaldaemon.com...
 Ok - Let's try and cut through all of the bullshit here. Fork the language,
 C'MON!! Sounds like a slow and sure death to me.

 Don't get me wrong Brad, I do appreciate that the threat of the 'F-word' is
 sometimes needed to get things moving, especially since some very talented
 and smart people seem to be at an impass here, but F'ing D now really would,
 well "F" D for good, IMO.

 Below is what I propose should be done.. I apologize beforehand if I hurt
 any feelings here by leaving people out (many of you have put a lot of
 effort into building/testing/fixing things, and all of it is valued), or by
 putting five people on the spot.

 Matthew, Kris, Ben and David Friedman:

 From your posts, I can surmise that the first three have:
 1) All done serious library development with D.
 2) Been the most substantively vocal on D language issues.
 3) All worked extensively with a lot of applications done w/ other
 languages.

 And of course you, David, have actually implemented another working D
 compiler.

 What I would suggest is each list their top 3 (and only 3) shortcomings of
 the D language itself (not bugs, not library). Keep it short and number the
 issues please.

 Then, I suggest that out of these 12 submissions, 6 could be agreed upon by
 you four as top priority and something that would make sense for compiler
 developers. There may well be some overlap in the original 12 and the idea
 is to boil things down to a handful of the most important issues.

 I figure once the language spec. is solid enough for major library and
 compiler development, fixing compiler bugs and fixing/developing the library
 will more easily follow.

 Is this something that could be of any value?? If so, who will start?

 Once it is done, there will be 6 major issues for Walter to (hopefully)
 focus and comment on, even that comment happens to be "get F'd".

 - Dave

 (I cross-posted to D.gnu because that seems relevant here).

 "Brad Anderson" <brad dsource.dot.org> wrote in message
 news:d3l33k$6fr$1 digitaldaemon.com...
Speaking for myself, I've certainly become far grumpier of late. It
seems I take a break due to some pointless/bad experience, and
foreswear any such future behaviour on my part or being sucked into
fatuous debates by others, and yet within a couple of days of
'coming back' it's happening again. Needless to say, I find this
truly uncharacteristic - honest! <G> - behaviour of mine both
appalling and intriguing. (I often think how embarrassed I'll be if
my sons become software engineers and go and look up some of their
cranky old fart of a father's semi-lucid ranting and pompous
condescension.)

I'm totally with you, since I find the same thing happening.

Something's gotta change. I hope it'll be something organisationally with D, but I suspect it'll be my conscience making me leave in response to increasing number of reasonable complaints about my curmudgeon. :-(

This would truly be a shame. The way a technology advances, IMO, is the conflict resolution between knowledgeable, passionate, and boisterous people who are fully engaged in the birthing of the technology. If the conflict is fully vetted, and reasonable compromises can be made, in addition to minds being kept open to future change, then advancement is realized. I hate to name names, and forgive me if I've omitted you, but for D and this NG to lose the voices of Matthew, Kris, Sean and others would be a HUGE loss. They've already been quiet recently as it is. This is a direct result of Walter not finding compromise or recognizing the value of other expert opinions that may differ from his own. Not sure who said this, but maybe ESR? and it's paraphrased... "Thrill your users. At first, it will be the early adopters. Make the experts / power users happy..." This would be a bit more powerful from someone writing a lot of D code on a consistent basis, but I've lurked for 2+ years, and have seen smart people jump up and volunteer some great ideas. I don't care if they get shot down ... to a point. Some of them are now gone because of the problem noted above. Over and over again, it's been proposed that some organization be formed to augment Walter's efforts, whether library or lang standard. Let me say this carefully: THIS IS NOT GOING TO HAPPEN. If it's not going to happen, then get David Friedman on board, or do it yourselves, but fork the damn language and fix the warts you guys want to fix! If you come up with something better, then maybe Walter will want to merge back with you. When he holds the keys to the kingdom, however, the advancement made will not be sufficient in your minds. One effort that holds my respect is Ares, because it's the only thing those guys can do to compensate for their perceived shortcomings of Phobos. Even if they've stopped (slowed) participating in the NG, they are still coding that lib. Compiler warts and all. It's all that they can control. <somewhat-random-tangent> If none of this works, and you truly want to leave D, then come join me in the world of Common Lisp. Talk about a powerful language devoid of lots of the warts you speak of. (btw, don't tell me it's interpreted, slow, full of parentheses, and its developers talk funny. All of that's bull, except for the parens, and they're manageable.) All of the Design Patterns you OO guys work with daily are basically to make up for Java/C/C++/D's lack of late binding, and there's nothing like the macros or closures in Lisp. </somewhat-random-tangent> I have learned a ton from this NG, watching the more experienced developers debate, and firmly believe that D would be worse off without the powerful voices that chime in regularly. But I empathize with them in their frustration to affect change recently (i.e. before 1.0). WTF, Walter? Don't answer my post. Answer theirs... And if he doesn't answer, boys, go ahead and fork it. There has to be some way to affect change and realize the great promise that keeps you coming back to the current quagmire. BA


Apr 14 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <d3kunk$3dp$2 digitaldaemon.com>, Matthew says...
But this is what I simply don't get. This 'industry' we're in is 
exactly what should attract people who genuinely care about the 
quality of their work. Lord knows, it's not for the chicks, or the 
money, or the doing-great-work-for-those-less-fortunate. Since it's 
somewhat related to maths, surely the "if it's not elegant, it's not 
correct/finished" ethos should pervade.

I'm not sure I agree. While I certainly feel this way and know others who do as well, there are plenty of people in this industry (and any other) who do not. Not to mention those with massive egos and little skill. People are people, be they computer geeks or anything else.
And yet, the older I get, or certainly since the "heady days of the 
internet", it seems like more and more people care less and less 
about the elegance.

Okay, this may indeed be true. As any practice gains popularity it will attract more folks who are not 'purists.' And it doesn't much help in this case that some companies (MS, for example) have tried to simplify the job so that "anyone can do it." Whether simplifying the task beneficial or not, I don't believe it's been a good thing that there is a perception that this job is easier than it is. I've had to maintain too much badly written code to think otherwise :)
Sometimes I think I was foolish not to take up my cousin's offer to 
go and work in The City (== London's financial community) when I got 
my PhD. He said he'd make me a millionnaire in less than 10 years. 
That was 10 years ago. ;/

Hah. There are finance geeks just like there are software geeks, but I prefer the latter. And being a millionaire would not be a sufficient reward for dealing with traders every day ;) Sean
Apr 14 2005
parent David Medlock <amedlock nospam.org> writes:
Sean Kelly wrote:

 In article <d3kunk$3dp$2 digitaldaemon.com>, Matthew says...
 
But this is what I simply don't get. This 'industry' we're in is 
exactly what should attract people who genuinely care about the 
quality of their work. Lord knows, it's not for the chicks, or the 
money, or the doing-great-work-for-those-less-fortunate. Since it's 
somewhat related to maths, surely the "if it's not elegant, it's not 
correct/finished" ethos should pervade.

I'm not sure I agree. While I certainly feel this way and know others who do as well, there are plenty of people in this industry (and any other) who do not. Not to mention those with massive egos and little skill. People are people, be they computer geeks or anything else.

My frustration with programming is not with mathematically 'purity' in the language, but with concentration on providing power on the wrong end of the language spectrum( by this I mean where the programmer gets his meat hooks into the process). On the one hand, we are given nice syntactical and resource tools(templates, garbage collection,#define macros), but very little in the way of _semantical_ tools, such as macros that Lisp/Scheme provides, or Scheme continuations which make exceptions, coroutines, opApply-type-iterators and a host of other 'features' easy to implement. Given these are hard to implement in compiled languages without explicit closures, but provide overall power at all levels rather than power in a few areas. -DavidM PS. This does not diminish what Walter has accomplished, just my thoughts on how to move down the language power spectrum.
Apr 14 2005
prev sibling next sibling parent reply Kris <Kris_member pathlink.com> writes:
In article <d3h7fb$1iv$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Kris wrote: (and I cut it down heavily)

 This is all to do with compatability vis-a-vis accepted usage. It is not a
 proposition for the ideal usage of these operators.

It does sound like a compatibility kludge, that much is certain.
 And if the roles of '= =' and 'is' were reversed ...?

As in: < is > ? That does look more than a little strange.

Noooooo! :-) What I meant was this: currently, - D 'is' is same as C/Java '==' - D '==' is the effectively the same as Java equals(), but with the twist noted previously That is; D 'is' always does "trivial" equality, and D '==' does "deep" equality (plus that twist noted). *If* these two were role-reversed such that '==' /always/ does trivial equality instead, then you'd be right at home with >, <, and friends; and backward compatability is magically restored (yes, I'm aware of the opCmp implications). That would leave 'is' to do deep equality instead of its current role. In the original post, I noted "perhaps D has made a blunder in this regard". The explicit reversal of these roles is what I was getting at (WRT backward compatability). I have little doubt Walter chose to reverse the roles intentionally, and I don't imagine for one fleeting moment they will change again. But you, Ben, and I all concur that the change breaks compatability with currently accepted idioms. This is what I found interesting enough to post about in the first place. What's also interesting is that nobody here seems to care much about compatability at this rather fundamental level (or haven't raised their hand high enough yet). It seems far more important to have, for example, libraries that mimic the C approach :-) [the only person I've seen to make a fuss over claims of compatability is Walter himself. Such is the dichotomy of D] The saving grace, of course, is that we at least have a choice. I'll use 'is' for everything except deep comparisons ~ which for my libraries will likely hover around that magic 98.75% usage. "Deep equivalence" is just not used very much outside of some specific algorithms (such as containers). I think if you analyzed your own typical code, it would perhaps be in that vicinity also? When it comes to general-case programming, consistency is king. Jumping between equivalence operators, depending upon the data-type in question, is an ugly yet seemingly necessary evil. Where one has to do it, it should be in the minority case rather than the majority. Yes? The kludge, as you called it, currently appears to be present in the majority case. Before simply refuting that, please try some analysis on a large code base of quality code :-) Cheers, Anders; - Kris p.s. As Brad noted, this topic is recieving far more attention than the arguably more important "true inner class". Go figure :-)
Apr 12 2005
next sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
 When it comes to general-case programming, consistency is king. Jumping 
 between
 equivalence operators, depending upon the data-type in question, is an 
 ugly yet
 seemingly necessary evil. Where one has to do it, it should be in the 
 minority
 case rather than the majority. Yes?

In templates I use the equals and compare functions in the TypeInfo. But that requires more work on the coder's part. TypeInfos are very handy things for generic code.
Apr 12 2005
prev sibling next sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Kris wrote:

And if the roles of '= =' and 'is' were reversed ...?

As in: < is > ? That does look more than a little strange.

Noooooo! :-)

Phew. :-)
 What I meant was this: currently, 
 
 - D 'is' is same as C/Java '=='

No argument there. Although that's: "when applied to Object references". That it happens to work for primitive types in D, is simply because identity falls back to equality for those... It "really" uses '=='. Not that it matters in the slightest, in practice. Just in theo-logy/ry.
 - D '==' is the effectively the same as Java equals(), but with the twist noted
 previously
 
 That is; D 'is' always does "trivial" equality, and D '==' does "deep" equality
 (plus that twist noted).

"trivial equality" being identity, and "deep equality" being equality, OK. (i.e. 'is' compares the pointers, and '==' compares the contents) D '==' is the same as Java 'equals', for Object references. It's also the same as Java's '==', for the primitive types. It adds new functionality over C for comparing structs/arrays, but works the same as in C when comparing two pointer values... The difference between references and pointers in D, is something of a dark side of allowing both things at once (C and Java does not have it, since they only do one thing) I guess those are the breaks when doing "multi-paradigm"...
 *If* these two were role-reversed such that '==' /always/ does trivial equality
 instead, then you'd be right at home with >, <, and friends; and backward
 compatability is magically restored (yes, I'm aware of the opCmp
implications). 

I'm not sure I follow ? Would < and > also work on the reference value ? (i.e. compare the pointers to the objects, instead of calling on opCmp) Or would == now work on the reference, and < > work on the contents ? (which was why I commented that it would be "< is >", if it was so...)
 That would leave 'is' to do deep equality instead of its current role. 

Then one might as well rename it 'equals', than re-using 'is' keyword ? Assuming here that 'is' has some kind of connection with "identity", why it was suggested as a transcript of '==='/≡ in the first place ? But I don't really see a reason to flip '==' over to "Java mode", except that it would make it easier to port things like large libraries over... But D and Java do differ in other areas, just not this particular one ?
 In the original post, I noted "perhaps D has made a blunder in this regard".
The
 explicit reversal of these roles is what I was getting at (WRT backward
 compatability).

Java and D made different choices. I'm not sure that D made a "blunder".
 I have little doubt Walter chose to reverse the roles intentionally, and I
don't
 imagine for one fleeting moment they will change again. But you, Ben, and I all
 concur that the change breaks compatability with currently accepted idioms.
This
 is what I found interesting enough to post about in the first place. 

That's OK, as I thought that what Walter did was unreverse the old ones. i.e. the reference types were the odd ones in Java, set straight in D. Then Walter made a different choice about whether comparing null should throw a NullPointerException or not, but that's for another discussion.
 What's also interesting is that nobody here seems to care much about
 compatability at this rather fundamental level (or haven't raised their hand
 high enough yet). It seems far more important to have, for example, libraries
 that mimic the C approach :-)

Well, some might have thought that Java was broken and that D fixed it ?
 The saving grace, of course, is that we at least have a choice. I'll use 'is'
 for everything except deep comparisons ~ which for my libraries will likely
 hover around that magic 98.75% usage. "Deep equivalence" is just not used very
 much outside of some specific algorithms (such as containers). I think if you
 analyzed your own typical code, it would perhaps be in that vicinity also?

Sorry, I don't have that much of a object-oriented codebase right now. But when I ran some quick greps on the JDK 1.5 codebase, what I saw was a whole lot of "x == null" and "x != null" which Walter has now decided shall be "x" and "!x" in D (just like they were in C++ in the Dark Ages) Then there were some enum stuff, not sure if those counts since D has integer(-ish) enumerations just like C - and not object Enums like Java. Then there was 'equals', about a quarter of the *total* amount of '==' calls, and then 'compare' again about a quarter of the equality calls. So I guess your 98-2 breakdown just does not sound familiar to me ?
 The kludge, as you called it, currently appears to be present in the majority
 case. Before simply refuting that, please try some analysis on a large code
base
 of quality code :-)

Well, it reminds me of the comment made on the "bool" vs. "bit" page: "The only problem is that a bit is not a bool. :-)" Same problem here, just with equals and identity... While it might work out (perhaps?), it still doesn't qualify as pretty. Especially not if D also allows '==' for structs and arrays, neither of which are even present in Java. (Similar to "no operator overloads") Side note: C#, being a somewhat strange language, uses identity for Object and equality for subclasses. Thus, to check the references you use a cast... But that's pretty similar to how the default implementation of equals in the java.lang.Object simply compares the object references anyway ? For things like String, it is overridden to check all the characters. (with the equals() method in Java, and with the == operator in C#) --anders
Apr 12 2005
parent reply "Kris" <fu bar.com> writes:
 I have little doubt Walter chose to reverse the roles intentionally, and


 imagine for one fleeting moment they will change again. But you, Ben,


 concur that the change breaks compatability with currently accepted


 is what I found interesting enough to post about in the first place.

That's OK, as I thought that what Walter did was unreverse the old ones. i.e. the reference types were the odd ones in Java, set straight in D.

Heck, I don't really care if B, BCPL, ALGOL, C, C++ and Java are /all/ broken, Anders. That's not what this thread is about, so let's not turn it into an ideology quagmire.
Apr 12 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kris wrote:

That's OK, as I thought that what Walter did was unreverse the old ones.
i.e. the reference types were the odd ones in Java, set straight in D.

Heck, I don't really care if B, BCPL, ALGOL, C, C++ and Java are /all/ broken, Anders. That's not what this thread is about, so let's not turn it into an ideology quagmire.

Really, I only meant when it comes to the '==' operator and references ? As in: No, I didn't see any compelling reason to switch the operators... --anders "C is quirky, flawed, and an enormous success" -- Dennis M. Ritchie
Apr 13 2005
prev sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Kris" <Kris_member pathlink.com> wrote in message 
news:d3hcf3$60r$1 digitaldaemon.com...
 In article <d3h7fb$1iv$1 digitaldaemon.com>,
 =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Kris wrote: (and I cut it down heavily)

 This is all to do with compatability vis-a-vis accepted usage. 
 It is not a
 proposition for the ideal usage of these operators.

It does sound like a compatibility kludge, that much is certain.
 And if the roles of '= =' and 'is' were reversed ...?

As in: < is > ? That does look more than a little strange.

Noooooo! :-) What I meant was this: currently, - D 'is' is same as C/Java '==' - D '==' is the effectively the same as Java equals(), but with the twist noted previously That is; D 'is' always does "trivial" equality, and D '==' does "deep" equality (plus that twist noted). *If* these two were role-reversed such that '==' /always/ does trivial equality instead, then you'd be right at home with >, <, and friends; and backward compatability is magically restored (yes, I'm aware of the opCmp implications). That would leave 'is' to do deep equality instead of its current role. In the original post, I noted "perhaps D has made a blunder in this regard". The explicit reversal of these roles is what I was getting at (WRT backward compatability). I have little doubt Walter chose to reverse the roles intentionally, and I don't imagine for one fleeting moment they will change again. But you, Ben, and I all concur that the change breaks compatability with currently accepted idioms. This is what I found interesting enough to post about in the first place.

Whooshka! Straight over my head. Can you re-explain, with the assumption that your audience has half the IQ you think it has?
 What's also interesting is that nobody here seems to care much 
 about
 compatability at this rather fundamental level (or haven't raised 
 their hand
 high enough yet). It seems far more important to have, for 
 example, libraries
 that mimic the C approach :-)

Please exemplify this statement. (Still desperately trying to get ya ...)
Apr 12 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Bjrklund wrote:
 "Been annoyed by", yes. :-) Wonder what dumb font would mix the two up ?
 Surely people aren't using Helvetica or Arial to program in ? <horrors>

:-) But program code gets printed in books, magazines, etc.
Apr 12 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 But program code gets printed in books, magazines, etc.

Or quoted on web pages. Usually in typewriter fonts, though ? --anders
Apr 12 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 "Been annoyed by", yes. :-) Wonder what dumb font would mix the two up ?
 Surely people aren't using Helvetica or Arial to program in ? <horrors>

But program code gets printed in books, magazines, etc.

And if you mess '==' and '===' up, wouldn't you have the same problems with the '=' and '==' expressions as well ? That can easily be solved, though. We can change to using ':=' for all assignments. Or start them all with 'LET' ? ;-) Seriously, I don't think "is" is bad. But this !(is nice). --anders
Apr 12 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Kris wrote:
 "Anders F Bjrklund" <afb algonet.se> wrote:
 Kris wrote:
 
 Disagree here, Eric. I think Java tried to cater to the most 
 widely used cases of '= =' such that it rarely conflicts with 
 established use (per the original example given). Don't forget
 that Java was attempting to pick up C/C++ users, just like D ;-)


 [...]
 
 Having said that, the now-generic usage of 'is' has somewhat 
 switched its role from an "identity" operator, and has <gasp> 
 suddenly become identical to the Java '= =' :-)



 If the assigned role of '= =' and 'is' were flipped, D would be just 
 like C/Java ~ with the aforementioned twist regarding the equals() 
 working with primitives as well as aggregates. That is, since '= =' 
 is currently the same as a Java equals(), but works with primitives 
 also, and 'is' currently plays the identical role of the Java '= =' 
 operator, switching the D operators around makes D equivalent to Java
  in the usage of '= =' and equivalent to C for the largest percentage
  of uses (given the original illustration). The use of 'is' would 
 thus be relegated to "deep equivalence" testing instead.

 What I do question is the break in backward compatability, which you 
 (and others) acknowledge.
 
 However if the D operators '= =' and 'is' were role-reversed, the C &
  Java compatability would be restored for the majority case (98.75% 
 in the use-case given). There's still compromise going on there, 
 naturally. But, shouldn't one optimize for the majority case?

Looks like the case FOR swapping == and is, has been established quite well! Now let's hear it from the other side: do there exist _valid_ reasons for not to swap them? (With "valid" I mean other than whining about old code breaking.)
Apr 12 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
Having read this whole thread, and feeling the need to at least put my  
opinion out there...

On Tue, 12 Apr 2005 23:41:40 +0300, Georg Wrede <georg.wrede nospam.org>  
wrote:
 Looks like the case FOR swapping == and is, has been established quite  
 well!

It can be summed up as "so it behaves like C/Java" right?
 Now let's hear it from the other side: do there exist _valid_ reasons  
 for not to swap them?
 (With "valid" I mean other than whining about old code breaking.)

Because IMO the afore mentioned reason isn't a valid one *for* swapping them. Here's my personal take on "==" and "is". There appears to be a rule, with one exception. "==" compares value. "is" compares identity. for all types, no matter what. Except.. "is" is identical to "==" for value types because comparing identity for value types is meaningless. I'll admit when I first started with D I was at first confused by this change. However, now, I like it a lot. It's simple, it's straightforward and it makes sense. (once you get over the fact that it's different). The fact that "==" segv's on null doesn't bother me, I'm used to it happening when I compare the value of something non-existant, eg. char *p = NULL: if (*p == 'a') // segv My gut feeling (as I have no proof/example) is that "==" will be used just as frequently outside container implementations as "is". I'm thinking of basic types where by habit I use "==" (I could now use "is"). In response to Brad's question about how we define a type that behaves like a user defined one.. I don't know. It seems at first glance/thought that a struct would need to be used as it exhibits value type behaviour. It's interesting to note that Java cannot do it either. I don't think C# can either. In response to Brad's comment about Derek's problem with deep/shallow copy. I believe there is a need for a deep-copy operator, eg. ":=" which for all types copies the "value" (AKA deep copy). The is analogous to "==" which for all types compares that value. In response to the idea for a word to replace "!==". I think it should be replaced, I think "===" and "!==" should be deprecated. I like either: isnt, isnot Regan
Apr 12 2005
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:

 Here's my personal take on "==" and "is". There appears to be a rule, 
 with  one exception.
 
 "==" compares value.
 "is" compares identity.
 
 for all types, no matter what. Except.. "is" is identical to "==" for  
 value types because comparing identity for value types is meaningless.

There is one more exception, and is not that obvious - at first: the default implementation of Object.opEquals compares identity... module object; class Object { int opEquals(Object o) { return this is o; } } package java.lang; public class Object { public boolean equals(Object obj) { return (this == obj); } } All this means is that all Objects are by default "unique" and separate, unless they explicitly declare that the state matters more than the ref. --anders
Apr 12 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 13 Apr 2005 00:34:33 +0200, Anders F Bjrklund <afb algonet.se>  
wrote:
 Regan Heath wrote:

 Here's my personal take on "==" and "is". There appears to be a rule,  
 with  one exception.
  "==" compares value.
 "is" compares identity.
  for all types, no matter what. Except.. "is" is identical to "==" for   
 value types because comparing identity for value types is meaningless.

There is one more exception, and is not that obvious - at first: the default implementation of Object.opEquals compares identity...

True. With no description of how to compare the contents (i.e. no OpEquals) it does "default" to comparing identity. This seems the most sensible choice to me. i.e. Until you tell it how the value compares to other values the identity is the value of the object. What else could it do? throw an exception? Regan
Apr 12 2005
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:

 This seems the most sensible choice to me. i.e. Until you tell it how 
 the  value compares to other values the identity is the value of the 
 object.  What else could it do? throw an exception?

Well, it could just crash... Or perhaps segfault on one OS and throw an Exception on another ? Or was that when comparing things with null, I mixed them up. :-) Seriously, the alternative would be to compare the bit contents. (not saying that this would be a *good* alternative, or anything) Comparing bits for structs, and references for objects, sounds good. (as a default, then the object could always just implement opEquals) --anders
Apr 12 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 13 Apr 2005 00:51:53 +0200, Anders F Bjrklund <afb algonet.se>  
wrote:
 Regan Heath wrote:

 This seems the most sensible choice to me. i.e. Until you tell it how  
 the  value compares to other values the identity is the value of the  
 object.  What else could it do? throw an exception?

Well, it could just crash... Or perhaps segfault on one OS and throw an Exception on another ? Or was that when comparing things with null, I mixed them up. :-)

:)
 Seriously, the alternative would be to compare the bit contents.
 (not saying that this would be a *good* alternative, or anything)

 Comparing bits for structs, and references for objects, sounds good.
 (as a default, then the object could always just implement opEquals)

Isn't this what it does currently? http://www.digitalmars.com/d/ctod.html#structcmp Regan
Apr 12 2005
parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:

 Comparing bits for structs, and references for objects, sounds good.
 (as a default, then the object could always just implement opEquals)

Isn't this what it does currently? http://www.digitalmars.com/d/ctod.html#structcmp

It is (sorry), and it's a good default too. --anders
Apr 13 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:425C3284.5070700 nospam.org...
 Kris wrote:
 "Anders F Bjrklund" <afb algonet.se> wrote:
 Kris wrote:

 Disagree here, Eric. I think Java tried to cater to the most 
 widely used cases of '= =' such that it rarely conflicts with 
 established use (per the original example given). Don't forget
 that Java was attempting to pick up C/C++ users, just like D 
 ;-)


 [...]

 Having said that, the now-generic usage of 'is' has somewhat 
 switched its role from an "identity" operator, and has <gasp> 
 suddenly become identical to the Java '= =' :-)



 If the assigned role of '= =' and 'is' were flipped, D would be 
 just like C/Java ~ with the aforementioned twist regarding the 
 equals() working with primitives as well as aggregates. That is, 
 since '= =' is currently the same as a Java equals(), but works 
 with primitives also, and 'is' currently plays the identical role 
 of the Java '= =' operator, switching the D operators around 
 makes D equivalent to Java
  in the usage of '= =' and equivalent to C for the largest 
 percentage
  of uses (given the original illustration). The use of 'is' would 
 thus be relegated to "deep equivalence" testing instead.

 What I do question is the break in backward compatability, which 
 you (and others) acknowledge.

 However if the D operators '= =' and 'is' were role-reversed, the 
 C &
  Java compatability would be restored for the majority case 
 (98.75% in the use-case given). There's still compromise going on 
 there, naturally. But, shouldn't one optimize for the majority 
 case?

Looks like the case FOR swapping == and is, has been established quite well! Now let's hear it from the other side: do there exist _valid_ reasons for not to swap them? (With "valid" I mean other than whining about old code breaking.)

Sorry, I must've missed that. Where is a good case for swapping made?
Apr 12 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:

Looks like the case FOR swapping == and is, has been established 
quite well!

Now let's hear it from the other side: do there exist _valid_ 
reasons for not to swap them?

(With "valid" I mean other than whining about old code breaking.)

Sorry, I must've missed that. Where is a good case for swapping made?

The case FOR is where Kris notes that in his ported Java library, '===' (identity) is used more often than what '==' (equality) is. Therefore, D should treat references like Java does (i.e. like pointers) Since that would make it more compatible with Java, and with C pointers. Then, in a bizarre twist, 'is' should now be used to compare equality... (since it does work with primitives, as identity falls back to equality) In case it wasn't obvious already, I didn't agree with the new idea? But we still need a new operator for '!==', and 'isnt' is now ahead. --anders PS. Kris, I hope I got the suggestion right. At least the '==' part.
Apr 13 2005
next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Anders F Bjrklund" <afb algonet.se> wrote in message
news:d3ijth$15bd$1 digitaldaemon.com...
 Matthew wrote:

Looks like the case FOR swapping == and is, has been established quite well!

Now let's hear it from the other side: do there exist _valid_ reasons for not
to swap them?

(With "valid" I mean other than whining about old code breaking.)

Sorry, I must've missed that. Where is a good case for swapping made?

The case FOR is where Kris notes that in his ported Java library, '===' (identity) is used more often than what '==' (equality) is. Therefore, D should treat references like Java does (i.e. like pointers) Since that would make it more compatible with Java, and with C pointers. Then, in a bizarre twist, 'is' should now be used to compare equality... (since it does work with primitives, as identity falls back to equality) In case it wasn't obvious already, I didn't agree with the new idea? But we still need a new operator for '!==', and 'isnt' is now ahead.

I don't go for it either, despite Kris's stats, because I think there's more precedent for == being equality - C/C++/Java builtins, C++/Ruby objects - and there's precedent for 'is' being identity in Python. I think we need to cut a slice of pie that Walter'll swallow, and that's no bigger than getting rid of === / !=== IMO.
Apr 13 2005
prev sibling parent reply "Kris" <fu bar.com> writes:
"Anders F Bjrklund" <afb algonet.se> wrote in message
 Matthew wrote:

Looks like the case FOR swapping == and is, has been established
quite well!

Now let's hear it from the other side: do there exist _valid_
reasons for not to swap them?

(With "valid" I mean other than whining about old code breaking.)

Sorry, I must've missed that. Where is a good case for swapping made?

The case FOR is where Kris notes that in his ported Java library, '===' (identity) is used more often than what '==' (equality) is. Therefore, D should treat references like Java does (i.e. like pointers) Since that would make it more compatible with Java, and with C pointers. Then, in a bizarre twist, 'is' should now be used to compare equality... (since it does work with primitives, as identity falls back to equality) In case it wasn't obvious already, I didn't agree with the new idea? But we still need a new operator for '!==', and 'isnt' is now ahead. --anders PS. Kris, I hope I got the suggestion right. At least the '==' part.

That surely has to get the prize for the most misleading post ever made to this NG ... if you had gone out of your way to deliberately misrepresent virtually every aspect of the core topic, you probably could not have done a more thorough job. Congratulations! As a bonus, it's a vaguely amusing post too :-)
Apr 13 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kris wrote:

PS. Kris, I hope I got the suggestion right. At least the '==' part.

That surely has to get the prize for the most misleading post ever made to this NG ... if you had gone out of your way to deliberately misrepresent virtually every aspect of the core topic, you probably could not have done a more thorough job. Congratulations!

Oh, that is something of an achievement considering the other posts. I must admit that I wasn't trying to deliberately misrepresent your post or opinions, just summarize as I had understood them. Seems like I had missed what you were trying to say. Care to try again, then ? Glad you found it amusing, at least. --anders
Apr 13 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Ding, Ding!

Kris, can you deobfuscate this topic with a summary of your points, 
as I'm now totally lost?

Thanks

Matthew

"Kris" <fu bar.com> wrote in message 
news:d3jogm$278a$1 digitaldaemon.com...
 "Anders F Bjrklund" <afb algonet.se> wrote in message
 Matthew wrote:

Looks like the case FOR swapping == and is, has been 
established
quite well!

Now let's hear it from the other side: do there exist _valid_
reasons for not to swap them?

(With "valid" I mean other than whining about old code 
breaking.)

Sorry, I must've missed that. Where is a good case for swapping made?

The case FOR is where Kris notes that in his ported Java library, '===' (identity) is used more often than what '==' (equality) is. Therefore, D should treat references like Java does (i.e. like pointers) Since that would make it more compatible with Java, and with C pointers. Then, in a bizarre twist, 'is' should now be used to compare equality... (since it does work with primitives, as identity falls back to equality) In case it wasn't obvious already, I didn't agree with the new idea? But we still need a new operator for '!==', and 'isnt' is now ahead. --anders PS. Kris, I hope I got the suggestion right. At least the '==' part.

That surely has to get the prize for the most misleading post ever made to this NG ... if you had gone out of your way to deliberately misrepresent virtually every aspect of the core topic, you probably could not have done a more thorough job. Congratulations! As a bonus, it's a vaguely amusing post too :-)

Apr 13 2005
parent "Kris" <fu bar.com> writes:
I did, Matthew. Two hours ago.

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3kao0$2mu4$3 digitaldaemon.com...
 Ding, Ding!

 Kris, can you deobfuscate this topic with a summary of your points,
 as I'm now totally lost?

 Thanks

 Matthew

Apr 13 2005
prev sibling next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
IMHO, Walter made a basic mistake when he followed Java's example of 
having clases be reference types rather than pointers.  I think that the 
'==' versus '===' issue is simply an outcome of that.

What I mean is, D should have been designed such that you would declare 
a class pointer/references like this:
	MyClass *foo;
rather than the current
	MyClass foo;
The difference is only one character, and yet it saves a massive amount 
of confusion, such as people (coming from C++) who don't expect the 
above to be a null reference.

More to the point, if D had required the pointer, then deep versus 
shallow compares would have been easy to differentiate:
	MyClass *foo;
	MyClass *bar;
	if(foo == bar) // compares pointers
	if(*foo == *bar) // compares value
(Yes, I know that there are always questions about *how* deep a deep 
compare should go...but that is not solved by the === operator, either.)

We wouldn't need an "is" operator if we had gone with the above syntax.

Kris wrote:
 Food for thought:
 
 Java is explicit about the distinction between equality and identity, just
 as D is. However, where D uses '==' as an equivalence operator, Java uses an
 equals() method. Where D uses (triple) '===' and 'is' for identity purposes,
 Java uses the traditional double '==' instead.
 
 So, what's that got to do with the price of tea in China?
 
 While porting 125,000 lines of Java to D, and an interesting thing happened.
 You'll perhaps not be surprised to hear Java identity style tests are far
 more prevalent than equivalence tests, but you may be surprised to know that
 the former comprised 98.75% of all explicit tests within those 125,000
 lines. To embellish, equals() was applied just 1.25% of the time.
 
 Please note that we're talking about high-quality Java code that makes
 extensive use of OO practices, and does indeed use equals() appropriately
 when doing class comparisons. It's just that there's relatively little call
 for that kind of thing once you get beyond writing sorting-algorithms,
 containers, and so on. What I'd classify as "user-level code" appears to
 apply equivalence testing rather seldom.
 
 The Java code was converted mechanically, so it was thankfully easy to
 change all identity tests into the D equivalent, which is the word 'is', or
 the triplet '==='. Likewise, the inversion was converted from '!=' to the D
 triplet '!=='. Each equals() instance was translated into the more
 traditional twin '==' equivalence operator.
 
 This has some notable ramifications; of which I'll attempt to be brief:
 
 1) The converted Java code now has reams of  'is' statements throughout the
 code, which makes it look 'interesting', to say the least. Quite nice,
 actually; and eminantly readable, even vaguely amusing at times. The '!=='
 instances look suitably alien by comparison. This amplifies the need for a
 sibling for the word 'is', such as the oft proposes 'not' or the colloquial
 'aint'.
 
 BTW, using 'is' generates optimal code for that 98.75% of tests within that
 large body of code. That is absolutely not the case when applying the
 traditional operators instead. Look at the emitted codegen.
 
 2) Anyone used to C or Java will habitually use the traditional '==' and
 '!=' all over their D code. This is actually the *wrong* thing to do, since
 those operators in D are for equivalence testing instead of identity
 testing. This has implications for both performance and for "expectations of
 behaviour". For example, the subsequent addition of an opEquals() to some
 aggregate may break the overall system in all manner of subtle and
 unexpected ways, where the original developer used '==' by force of habit.
 
 3) Just as importantly, this highlights a significant divergence of D from C
 and, IMO, in a rather fundamental manner. Think about this: you should
 actually be using 'is' most of the time instead of (twin) '=='. How many of
 you even use 'is' at all?
 
 One might perhaps argue the numbers above are artificially inflated since
 many of those test are applied to native types rather than to classes and
 structs ~ that may be true. But we're talking about something that's already
 well-developed as a habit in the community (the double '==') and we're
 talking about consistency in the majority case.
 
 I think D has perhaps made a serious blunder here. IMO, Java has the right
 approach by maintaining compatability for the vast majority of usage, whilst
 providing an option for testing "deep equivalence" via the equals() method
 for the remaining small percentage.
 
 D has effectively inverted that, and almost requires the adoption of a
 different, and somewhat confusing, idiom to do what has been tradition for a
 rather long time. The alternative is potentially error-prone code.
 
 There's ostensibly nothing wrong with change, but it's not clear what the
 benefit is here ~ if any?
 
 At the very least, one has to mentally shift gears to perform identity tests
 on classes and structs instead of native types. This would be OK if such
 things were in the minority, but they're not. In the case noted above, one
 has to continually shift gears for the overwhelming majority of tests.
 
 Those of you who avoid OO like the plague will likely not be bothered by
 such trivialities. For the rest, is it best to full embrace "is" and just
 stick with it?
 
 What sayeth ye?
 
 - Kris

Apr 11 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kris wrote:

 3) Just as importantly, this highlights a significant divergence of D from C
 and, IMO, in a rather fundamental manner. Think about this: you should
 actually be using 'is' most of the time instead of (twin) '=='. How many of
 you even use 'is' at all?
 
 One might perhaps argue the numbers above are artificially inflated since
 many of those test are applied to native types rather than to classes and
 structs ~ that may be true. But we're talking about something that's already
 well-developed as a habit in the community (the double '==') and we're
 talking about consistency in the majority case.
 
 I think D has perhaps made a serious blunder here. IMO, Java has the right
 approach by maintaining compatability for the vast majority of usage, whilst
 providing an option for testing "deep equivalence" via the equals() method
 for the remaining small percentage.

(I meant to ask this earlier, but might as well ask it now...) Did you mean for 'is' to be preferred only for class objects, or did you feel that the default operator ('==') does the "wrong thing" when it comes to the arrays and strings too ? (since in Java, '==' compares the references there too - not too surprising since they are both first-class Objects there) As in: should one really be checking identity most of the time ? All I know that in the Java that *I* have written, that's usually not the case. It's pretty common to want to compare the contents ? Like if I have two Integer "wrappers", and I want to compare them. It's kinda confusing to learn that new Integer(1) != new Integer(1) ? Or if you have two strings, that you must use string1.equals(string2) just in case they have not allocated from the exact same string pool. And when I have created two arrays, I cannot compare them either with the normal '==' operator, but must instead call upon Array.equals() ? The only thing that I thought to be confusing in D was that accidently comparing something with null, causes a "NullPointerException"/segv... (I still think it's the biggest trap in D for the Java programmer, since calling opEquals an extra time is not as big as dereferencing null is ?) That you now could compare objects, structs, arrays and strings with the same == syntax as used for primitives - I thought that to be excellent ? Especially when you could now use the related syntax of < <= >= > also, for comparing two objects (assuming they are Comparable, of course...) I'm not sure I would like to go back to the definition of '==' in Java. (That treats primitive types in one way, and reference types in another) As at least I *thought* that was what you were suggesting, either by always using 'is' instead of '==' - or possibly even by a change to D ? --anders PS. I'm assuming that you like the equality for arrays and strings in D. (Since Java doesn't really have those "built-in", they are objects)
Apr 13 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Well, I'll try to paraphrase it, as I understand it.  The problem is that there
is no way to state as an imutable fact exactly what "is" or "==" does without
having to first specify what they are being used to compare, other than that
they both compare for likeness.

In other words, we know what "is" and "==" have in common, and roughly what
that common functionality does, but we can't be sure of exactly how either one
goes about doing it even as a default, unless we have some idea what they are
doing it to.

For some things, like litteral numeric expressions for example, as they are
both comparing the value of those expressions, rather than the location that
the expressions are stored in.  (someone correct me if I'm wrong, because part
of this I am extrapolating from experience with other languages and assuming to
have been paralleled here based on the parts of this discussion that I have
read so far.)

For some things, like Objects for example, they are both comparing the
locations of the things rather than the contents of the things.

For some things, such as variables, for example, the "is" operator compares the
locations of the things, while the "==" operator compares the contents of the
things.

To make matters worse, this is just the "default" behavior, and can which it is
possible to override, and therefore can't always be trusted.

Of course, if should be possible to specify the unoverridden form, but doing so
all the time "just in case someone else over-rides the default" would be a real
bother.  Besides, it is even possible that the defaults could get changed.

Okay, I think that should about sum it up.  I did offer a solution a while
back... but it's probably lost in this thread by now.

TZ



"Anders F Bjrklund" <afb algonet.se> wrote in message
news:d3k43n$2hmb$1 digitaldaemon.com...
 Kris wrote:

 3) Just as importantly, this highlights a significant divergence of D from C
 and, IMO, in a rather fundamental manner. Think about this: you should
 actually be using 'is' most of the time instead of (twin) '=='. How many of
 you even use 'is' at all?

 One might perhaps argue the numbers above are artificially inflated since
 many of those test are applied to native types rather than to classes and
 structs ~ that may be true. But we're talking about something that's already
 well-developed as a habit in the community (the double '==') and we're
 talking about consistency in the majority case.

 I think D has perhaps made a serious blunder here. IMO, Java has the right
 approach by maintaining compatability for the vast majority of usage, whilst
 providing an option for testing "deep equivalence" via the equals() method
 for the remaining small percentage.

(I meant to ask this earlier, but might as well ask it now...) Did you mean for 'is' to be preferred only for class objects, or did you feel that the default operator ('==') does the "wrong thing" when it comes to the arrays and strings too ? (since in Java, '==' compares the references there too - not too surprising since they are both first-class Objects there) As in: should one really be checking identity most of the time ? All I know that in the Java that *I* have written, that's usually not the case. It's pretty common to want to compare the contents ? Like if I have two Integer "wrappers", and I want to compare them. It's kinda confusing to learn that new Integer(1) != new Integer(1) ? Or if you have two strings, that you must use string1.equals(string2) just in case they have not allocated from the exact same string pool. And when I have created two arrays, I cannot compare them either with the normal '==' operator, but must instead call upon Array.equals() ? The only thing that I thought to be confusing in D was that accidently comparing something with null, causes a "NullPointerException"/segv... (I still think it's the biggest trap in D for the Java programmer, since calling opEquals an extra time is not as big as dereferencing null is ?) That you now could compare objects, structs, arrays and strings with the same == syntax as used for primitives - I thought that to be excellent ? Especially when you could now use the related syntax of < <= >= > also, for comparing two objects (assuming they are Comparable, of course...) I'm not sure I would like to go back to the definition of '==' in Java. (That treats primitive types in one way, and reference types in another) As at least I *thought* that was what you were suggesting, either by always using 'is' instead of '==' - or possibly even by a change to D ? --anders PS. I'm assuming that you like the equality for arrays and strings in D. (Since Java doesn't really have those "built-in", they are objects)

Apr 14 2005
prev sibling next sibling parent John Demme <me teqdruid.com> writes:
On Thu, 2005-04-14 at 09:38 +1000, Matthew wrote:
 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message 
 news:d3j529$1l27$1 digitaldaemon.com...
 What program were you doing your searching in?  I'm writing code 
 in Notepad and Wordpad at the moment, and neither one of them 
 support that sort of search to my knowledge.

Desist immediately, and get GVIM (http://vim.org/). Sure, if you're unfamiliar with vi keystrokes, it'll seem quite weird at first, but I _promise_ that once you get used to it you'll be a very happy puppy. (Caveat: I actually do my D editing in Visual Studio '98, but I do edit make scripts, Ruby, Python, C & C++ in GVIM both on Win32 and Linux, it's really cool. Others on this ng have specific expertiese on using it with D, and they can help out, I'm sure.) I also recommend the book "Vi IMproved - Vim", by Steve Oualline.

Don't listen to him! He's mad! Get yourself a nice copy of emacs. (heh heh heh)
Apr 13 2005
prev sibling parent John Demme <me teqdruid.com> writes:
I don't know the first thing about LISP, but I use Emacs very
productively.  If I ever wanted to write something like Ben Hinkle's
D-Mode (or even modify it) then I would have to learn LISP.

Once you learn a few simple concepts, and key bindings, you can get
pretty productive in Emacs.

John Demme

On Thu, 2005-04-14 at 10:12 +1000, Matthew wrote:
 "Kris" <fu bar.com> wrote in message 
 news:d3kc9h$2ns6$1 digitaldaemon.com...
 "John Demme" <me teqdruid.com> wrote in message
 Don't listen to him! He's mad!

 Get yourself a nice copy of emacs.

 (heh heh heh)

Yes, Yes! Matthew has entirely lost control of his faculties. Emacs is the one, the true, the Holy Shoe! (ahem ... *cough*)

But - and I am 100% ignorant of Emacs - doesn't it take like a whole-system-approach, i.e. you have to give your brain up to Lisp, and "the Emacs way"? At least that's the impression I've gotten from people - such as Raymond - who've written about the two. (Bear in mind that I've been hanging on to VS98 for 7 years now, so reluctant am I to have to get productive in another editor. So I might not be sane ...)

Apr 13 2005