January 21, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | John Reimer wrote:
> Georg Wrede wrote:
>
>> I ignored it, since the main point was kind of obvious. :-)
>>
>> In my mother tongue "at most" is just one word, as is "at least". My gripe is actually the pronunciation of "<=" as "less than or equal to", in all spoken languages. It sounds clumsy and overly technical, especially as it refers to a single operator, or concept, more than a combination of two.
>>
>> Back to the original point, I like "isnt". It should be perfectly ok since nobody seems to have a problem with "endif". We might use "isnot", but "isnt" feels nicer.
>
>
> As an English speaker, "isnt" feels very informal. I doesn't (!) quite feel correct to use informal English contractions in a computer language.
Heh, obviously I meant to say "It doesn't."
|
January 21, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | John Reimer wrote:
>> As an English speaker, "isnt" feels very informal. I doesn't (!) quite feel correct to use informal English contractions in a computer language.
>
> Heh, obviously I meant to say "It doesn't."
Or: "Not that I do", as in current D syntax. :-)
(p isnot null) => (!(p is null))
--anders
PS. I take it that's another one against "aint" ?
|
January 21, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | Anders F Björklund wrote:
>
> Or: "Not that I do", as in current D syntax. :-)
>
> (p isnot null) => (!(p is null))
>
> --anders
>
> PS. I take it that's another one against "aint" ?
Heh, "aint" just doesn't cut it. :-)
|
January 21, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | John Reimer wrote:
>> PS. I take it that's another one against "aint" ?
>
> Heh, "aint" just doesn't cut it. :-)
The two most likely outcomes are "isnot", or nothing.
I mean, since "(p)" works and booleans are unwanted,
then shortening "(!(p is null))" is not a priority ?
Hopefully, "===" and "!==" will continue to work
when using the "-d" flag (for deprecated features)...
--anders
|
January 21, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | Anders F Björklund wrote:
> John Reimer wrote:
>
>>> PS. I take it that's another one against "aint" ?
>>
>>
>> Heh, "aint" just doesn't cut it. :-)
>
>
> The two most likely outcomes are "isnot", or nothing.
>
> I mean, since "(p)" works and booleans are unwanted,
> then shortening "(!(p is null))" is not a priority ?
>
> Hopefully, "===" and "!==" will continue to work
> when using the "-d" flag (for deprecated features)...
>
> --anders
If it is anything, then "isnot" it is; otherwise "nothing" is it. :-)
- John
|
January 21, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | Anders F Björklund wrote:
> Georg Wrede wrote:
>
>> We should start using a word for >= and <=, too.
>
> But if you really like some new words, then I suggest ≥ and ≤ ?
I absolutely agree with this suggestion. I would further it by suggesting "≡≡" and "!≡" replace the current "is" and the proposed "isnt". After all I suspect D 2.0 will struggle with all the english based keywords in the future since Unicode support really suggests supporting multiple languages.
|
January 21, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to parabolis | parabolis wrote: >> But if you really like some new words, then I suggest ≥ and ≤ ? > > I absolutely agree with this suggestion. I would further it by suggesting "≡≡" and "!≡" replace the current "is" No, not replace. As an *alternative* to the US-ASCII syntax. And that should be ≡ for '===', and ≢ for '!==' by the way. http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/UnicodeOperators --anders |
January 21, 2005 Re: What is the difference .. really: Why are typenames keywords? | ||||
---|---|---|---|---|
| ||||
Posted in reply to parabolis | My example was C code, I was making a point which everybody here probably already knows (sorry for any confusion) as a step towards my real point that typenames in D don't need to be reserved words. Precisely because the D language, unlike C/C++, does *not* need them to be so in order to direct parsing. And making too many things keywords has some bad side-effects. In article <csq0ml$1nh8$1@digitaldaemon.com>, parabolis says... >agent.smith@archvillain.com wrote: >> typedef float foo; >> a= (foo)(i); /* a cast */ >> b= (bar)(i); /* a function call */>Check the D spec on casting. Especially Unary Expressions: >http://www.digitalmars.com/d/expression.html#UnaryExpression > >So the above should be: >---------------------------------------------------------------- > a= cast(foo)(i); /* a cast */ > b= (bar)(i); /* a function call */ >---------------------------------------------------------------- |
January 21, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | > Hopefully, "===" and "!==" will continue to work
> when using the "-d" flag (for deprecated features)...
They shouldn't be supported. Walter'd better add a hint to the error messages which they'll generate when they are removed.
old.d(25): I did not expect another = after == (did you mean "is"?)
old.d(26): either use != or == but not both (did you mean "isnot"?)
L.
|
January 21, 2005 Scope hiding, dangers thereof | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kris | In article <csq18r$1o7t$1@digitaldaemon.com>, Kris says... >In article <csps3e$1jcu$1@digitaldaemon.com>, agent.smith@archvillain.com says... > Unfortunately, you cannot have a variable called 'length' in D. >Well ... you can ... but there's that sneaky issue where you can't use it within an array reference: > ># int length = 0; ># char x[], y[20]; ># ># // what do you think will happen here? ># x = y[0 .. length]; > >Believe it or not, 'length' is a pseudo-reserved keyword when used in this manner (within the braces), although the compiler says nothing about the 'collision'. > Really? but I'm not allowed to do this in D: myfunc() { int x; ... { int x; ... } ... } .. shouldn't the same philosophy make your example an error? That would be a Good Thing, IMHO. I.e. I can use 'length' if I want, but the compiler will keep me from loading it and pointing it at my foot. I can still do x.length. So somebody wanting to add the last statement to my code later would either have to add int ylength= y.length; x = y[ 0..ylength]; or int tlength = length; x = y[ 0..tlength]; .. whilst cursing me in the comments. or just s/length/len/ first. I'm not so sure that this should be disallowed: myfunc() { {int x; ...} { int x; ... } ... } I've an awful lot of C++ code where ... for( int irow=0; irow < h ; irow ++ )... .. appears several times in a function, and I'm less convinced that's dangerous. I'm making it explicit that these are independent uses of the same conceptual variable; in D i'd have to give each one a different name, or make them all the same variable, neither of which accomplishes this. Another issue: years ago I read something on a language newsgroup which really surprised me... that every Pascal 'with .. do' was a bug waiting to happen; but the author was right; what is even more scary is that the exact same issue exists in every C++ member func; these inherit scopes in basically the same way as a with ..do. It's actually worse in C++, because of class inheritance. This problem, which could result in bugs that take days to find, is commonly avoided by lexical conventions (e.g. starting member names with m_). Here's the problem in C++: ---- static int table[] = {1,2,3}; int MyClass::memberfunc(int i) { return table[i]; } --- OK. Now imagine 'MyClass' is based on 'JoesClass', and next week Joe adds a member 'table' to his function. My memberfunc() function will now reference that member variable instead of the static local! If I'm really lucky, I'll get a compile error, if not, I'll get different runtime behaviour, despite the fact that I didn't touch my code, and Joe's change was done in such a way as not to change the existing class interface (other than by adding this name...) This could take ages to figure out. The reason this doesn't happen much is because most variable naming conventions avoid it (e.g m_); but I suspect few programmers realize that this can happen. I only realized recently that the Pascal problem applies to C++ too. This can be avoided, of course, by putting :: in front of table, but that's a lot of ::'s to use. Some languages (e.g. Python) require explicit this->, (or self.) which is also rather a pain, but at least avoids this problem. Is there is a similar issue in D? Fundamentally, the problem is that a name introduced into a distant scope (inherited class) can hide a variable in a scope which is in some sense much closer (file scope of the function); it can be argued that the derived class and the file scope are under control of the author of the derived class, whereas the base class is not; and therefore this should not work this way. Maybe it's even more dangerous, somehow, to insert the file scope between the base class and derived class. In any case, it seems to me that this is a detectable case of ambiguity, and it's not unreasonable to flag it as such, and require the :: to be used. The problem will also be avoided if Joe's member 'table' is private. It might not compile, but that's better than compiling with the wrong meaning. I apologize for not stating this in D terms, and I apologize profusely if this is discussed in the D docs somewhere, but I haven't had time to read it all yet... will do so before further ramblings.. I did see just now that there is a with(){ } in D, which may suffer from the same problem, but this time accidentally hiding local vars instead of file-scope? This is more dangerous, if only because naming conventions are much less likely to protect you. |
Copyright © 1999-2021 by the D Language Foundation