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
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 theis
expression in parens which I've always found annoying:I've also seen the keyword
isnt
used. 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:
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
isnot
as a keyword would ever really bother someone.But I kind like the idea of
unless
orifnot
- more general purpose.andy Sun 6 Jul 2008
isnot
would be nice, and seems a harmless keyword to take. I usedunless
alot in Ruby, might be nice to have as well (or instead).thatguydrinksbeer Mon 7 Jul 2008
ifnot/unless is brilliant.
else unless
is confusing, I'd preferelse ifnot
.What about
not
as a keyword?if not (x)
else if not (y)
while not (x)
tompalmer Mon 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.andy Mon 7 Jul 2008
Yeah, I agree with tom - unless you allow
unless
to follow the expression, then I vote to haveifnot
instead.Though the other problem with
unless
is it makes if-else branches awkward:I think
ifnot
is more natural in that scenario:tompalmer Tue 8 Jul 2008
I'm actually not a fan of
ifnot
and 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 thatisnt
might 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
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.
brian Wed 9 Jul 2008
I implemented the
isnot
operator as just the inverse of theis
operator. This is a really simple enhancement which doesn't raise any thorny issues (like a general purposeunless
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 whatis
evaluates 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:The not empty scenario is messy:
Neither option is particularly clear. As a result I sometimes code the reverse method:
The
ifnot
keyword would avoid the need for that:mike Wed 9 Jul 2008
I'd like to second
aint