Open gavinking opened 8 years ago
I still think it’s much clearer with else
, i. e.
assert (exists length, nonempty sequence, length>0) else {
return null;
}
So the difference with if
is that the new values scope extends to the end like normal assert
, and the difference with normal assert
is the failure code that can be customised rather than just throw, right?
Well the really big difference is that to write the above with if
, I would have to write:
if (!exists length) {
return null;
}
if (!nonempty sequence) {
return null;
}
if (length<=0) {
return null;
}
Which is significantly worse.
I can't help but intensely dislike this, but I don't see any other option since we decided a long time ago to have this ,
notation in conditions.
Honestly, I agree with @quintesse. I think a better aproach would be to allow people to put !
before conditional thingies:
if!(exists bar, foo())
{
assert(false);
}
bar.baz();
Same for while!()
, and assert!()
...
But also, I agree with @gavinking that these "guard" thingles are not very ceylonic. If you end up with a bunch of if
s guarding your actual code, then just put your code actually inside the if
block...
if(!exists foo) { return(null); }
if(!exists bar) { return(null); }
if(!exists baz) { return(null); }
// actual code
becomes
if!(exists foo, exists bar, exists baz)
{
// actual code
}
else
{
return(null);
}
Oh so now I could rewrite this Java code:
if (foo == null || foo == bar) {
return;
}
to a nice
assert(exists foo, foo != bar) {
return;
}
instead of the ugly
if (foo?.equals(bar) else true) {
return;
}
assert(exists foo);
I like that :+1:
I agree with @lucaswerkmeister, the else
is necessary to make this clear to people not familiar with the feature.
I somewhat dislike the else
after the assert
condition.
Although, I can see how it makes the it more explicit when the block is being invoked...
I would however add an additional condition to the assertion failure block that it has to definitely return.
Otherwise it is indistinguishable from if
I would however add an additional condition to the assertion failure block that it has to definitely return.
Yes, of course, I'm assuming that.
I'd also put an else
.
+1 for the else
also
+1 for else.
+1 for else
I thought I had posted this already, but apparently not: besides my distaste for this feature (and my preference for if!()
), I prefer the version with else
as well. Not exclusively because it makes it easier it easier for people unfamiliar with the feature to understand, but also because it makes more sense syntactic-wise. It bring the syntax closer to the if
structure, having the else
block contain code that is executed when the structure's normal behavior isn't performed...
I really like the idea, but I'm not sure about the syntax. assert
suggests the input is invalid, or at least deficient, making many uses of this powerful feature look like abuses.
The if!()
idea doesn't make sense to me, because !
is confusing. Are all of the conditions negated? What happens to the ,
s?
If any
were a keyword, I'd suggest:
if any (!exists length, !nonempty sequence, length <= zero) {
return;
}
perhaps subtle, but another idea would be to use ;
s for the ||
analog to &&
's ,
in if
statements:
if (!exists length; !nonempty sequence; length <= zero) {
return;
}
The
if!()
idea doesn't make sense to me, because!
is confusing. Are all of the conditions negated? What happens to the,
s?
The !
means that all the conditions should be false.
if!(foo, bar, baz)
{
print("hi");
}
is equivalent to
if(!(foo && bar && baz))
{
print("hi");
}
Of course, that substituition wouldn't work for is
, exists
and nonempty
...
In #891 it was proposed that we could support stuff like this:
Even though #891 is now implemented, there may still be value in that. I personally find it to be a more pleasing and more powerful way to write "guards".