Something that I've been meaning to bring up is the notion of an isnot operator. It seems that I check that an instance is not a type as often as it is. Because of operator precedence you have to wrap the is expression in parens which I've always found annoying:
// what you do today
if (!(x is Foo)) doSomething
// proposed isnot keyword
if (x isnot Foo) doSomething
I've also seen the keyword isnt used. I don't really have a preference between the two.
I'm a bit hesitant reserving and entire keyword just for a negative operator. I agree that the extra parentheses are a bit annoying, but not to the extent that you should burn your keyword allowance for this.
How about making this more general and introducing "unless", which you could extend to all boolean expressions and not only instanceof ones?
Regarding the patent - that patent is for comparing two memory references, so it doesn't apply. That fact that the US Patent Office granted a patent for what is effectively the "!=" C operator which has been use for three decades illustrates how broken the patent system is.
PLEASE DO NOT POST PATENT LINKS ON THIS SITE! It is fundamentally impossible to develop software which doesn't infringe on patents - so assume that Fan infringes someone's patents. But by posting in public all you are going to do is complicate a legal case and bring up the potential for treble damages.
How about making this more general and introducing "unless", which you could extend to all boolean expressions and not only instanceof ones?
Well I don't think burning isnot as a keyword would ever really bother someone.
But I kind like the idea of unless or ifnot - more general purpose.
andySun 6 Jul 2008
isnot would be nice, and seems a harmless keyword to take. I used unless alot in Ruby, might be nice to have as well (or instead).
thatguydrinksbeerMon 7 Jul 2008
ifnot/unless is brilliant.
else unless is confusing, I'd prefer else ifnot.
What about not as a keyword?
if not (x)
else if not (y)
while not (x)
tompalmerMon 7 Jul 2008
I like unless best for the reverse syntax in Ruby (as in, doSomething unless (x is Foo)). I'm not sure if I'd use it as much otherwise.
I think isnot might be OK.
andyMon 7 Jul 2008
Yeah, I agree with tom - unless you allow unless to follow the expression, then I vote to have ifnot instead.
Though the other problem with unless is it makes if-else branches awkward:
doFoo unless (x is Foo)
else doBar
I think ifnot is more natural in that scenario:
ifnot (x is Foo) doFoo
else doBar
tompalmerTue 8 Jul 2008
I'm actually not a fan of ifnot and probably not unless (because I only like the reverse form). I don't think either sounds clear with else.
I think my context caused some confusion. I was referring to being OK with isnot, the original question on this thread. I think I like it better than isnt, just for fear that isnt might look alien to a new learner who didn't get the point.
cbeustTue 8 Jul 2008
Especially since "isnt" looks like "is NT" :-)
-- Cedric
alexlamslTue 8 Jul 2008
Random thought of the day:
if (x is Foo) doSomething;
nah! doSomethingElse;
heliumTue 8 Jul 2008
I vote for aint. ;)
brianTue 8 Jul 2008
My current thoughts are that isnot seems pretty useful and no likely to be used as a identifier - so I'm thinking we should do that feature.
I'm not quite sure about unless or other forms of "inversed statements". I like unless in Ruby, but not sure how it work with Fan.
brianWed 9 Jul 2008
I implemented the isnot operator as just the inverse of the is operator. This is a really simple enhancement which doesn't raise any thorny issues (like a general purpose unless solution does). I was using (!(x is Foo)) quite a few places in the code base.
So there is now a new isnot keyword which is semantically equivalent to !(x is Type). If x is null, then it evaluates to true (opposite of what is evaluates to when x is null). Examples:
fansh> 3 is Num
true
fansh> 3 isnot Num
false
fansh> null is Num
false
fansh> null isnot Num
true
jodastephenWed 9 Jul 2008
Reading through the options here, I like the ifnot option.
ifnot (x is Foo) doFoo
else doBar
For example consider an API that defines an isEmpty() method:
if (obj.isEmpty()) {
doStuff();
}
The not empty scenario is messy:
if (obj.isEmpty() == false) {
doStuff();
}
if (!obj.isEmpty()) {
doStuff();
}
Neither option is particularly clear. As a result I sometimes code the reverse method:
brian Sun 6 Jul 2008
Something that I've been meaning to bring up is the notion of an
isnotoperator. It seems that I check that an instance is not a type as often as it is. Because of operator precedence you have to wrap theisexpression in parens which I've always found annoying:I've also seen the keyword
isntused. I don't really have a preference between the two.Comments?
helium Sun 6 Jul 2008
http://en.wikipedia.org/wiki/Visual_Basic_.NET#.27IsNot.27_operator_Patented
cbeust Sun 6 Jul 2008
I'm a bit hesitant reserving and entire keyword just for a negative operator. I agree that the extra parentheses are a bit annoying, but not to the extent that you should burn your keyword allowance for this.
How about making this more general and introducing "unless", which you could extend to all boolean expressions and not only instanceof ones?
unless (x is Foo) doSomething unless (x == 0) {
}
cbeust Sun 6 Jul 2008
One more time, with the correct formatting:
unless (x is Foo) doSomething() unless (x == 0) { // ... }brian Sun 6 Jul 2008
Regarding the patent - that patent is for comparing two memory references, so it doesn't apply. That fact that the US Patent Office granted a patent for what is effectively the "!=" C operator which has been use for three decades illustrates how broken the patent system is.
PLEASE DO NOT POST PATENT LINKS ON THIS SITE! It is fundamentally impossible to develop software which doesn't infringe on patents - so assume that Fan infringes someone's patents. But by posting in public all you are going to do is complicate a legal case and bring up the potential for treble damages.
Well I don't think burning
isnotas a keyword would ever really bother someone.But I kind like the idea of
unlessorifnot- more general purpose.andy Sun 6 Jul 2008
isnotwould be nice, and seems a harmless keyword to take. I usedunlessalot in Ruby, might be nice to have as well (or instead).thatguydrinksbeer Mon 7 Jul 2008
ifnot/unless is brilliant.
else unlessis confusing, I'd preferelse ifnot.What about
notas a keyword?if not (x)
else if not (y)
while not (x)
tompalmer Mon 7 Jul 2008
I like
unlessbest for the reverse syntax in Ruby (as in,doSomething unless (x is Foo)). I'm not sure if I'd use it as much otherwise.I think
isnotmight be OK.andy Mon 7 Jul 2008
Yeah, I agree with tom - unless you allow
unlessto follow the expression, then I vote to haveifnotinstead.Though the other problem with
unlessis it makes if-else branches awkward:I think
ifnotis more natural in that scenario:tompalmer Tue 8 Jul 2008
I'm actually not a fan of
ifnotand probably notunless(because I only like the reverse form). I don't think either sounds clear withelse.I think my context caused some confusion. I was referring to being OK with
isnot, the original question on this thread. I think I like it better thanisnt, just for fear thatisntmight look alien to a new learner who didn't get the point.cbeust Tue 8 Jul 2008
Especially since "isnt" looks like "is NT" :-)
-- Cedric
alexlamsl Tue 8 Jul 2008
Random thought of the day:
helium Tue 8 Jul 2008
I vote for
aint. ;)brian Tue 8 Jul 2008
My current thoughts are that
isnotseems pretty useful and no likely to be used as a identifier - so I'm thinking we should do that feature.I'm not quite sure about unless or other forms of "inversed statements". I like unless in Ruby, but not sure how it work with Fan.
brian Wed 9 Jul 2008
I implemented the
isnotoperator as just the inverse of theisoperator. This is a really simple enhancement which doesn't raise any thorny issues (like a general purposeunlesssolution does). I was using(!(x is Foo))quite a few places in the code base.So there is now a new
isnotkeyword which is semantically equivalent to!(x is Type). If x is null, then it evaluates to true (opposite of whatisevaluates to when x is null). Examples:jodastephen Wed 9 Jul 2008
Reading through the options here, I like the ifnot option.
For example consider an API that defines an
isEmpty()method:if (obj.isEmpty()) { doStuff(); }The not empty scenario is messy:
if (obj.isEmpty() == false) { doStuff(); } if (!obj.isEmpty()) { doStuff(); }Neither option is particularly clear. As a result I sometimes code the reverse method:
if (obj.isNotEmpty()) { doStuff(); }The
ifnotkeyword would avoid the need for that:ifnot (obj.isEmpty()) { doStuff(); }mike Wed 9 Jul 2008
I'd like to second
aint