When in a conversation with other developers, what do I call the !! operator?
In Kotlin, the ?: is called the Elvis operator
These sources don't say what the name of !! is:
http://kotlinlang.org/docs/reference/null-safety.html#the--operator
http://kotlinlang.org/docs/reference/keyword-reference.html
Looking online, the generic term for !! is double bang. Do I use the same for Kotlin even though swift's ! operator is called forced unwrapping (Note: the ! in swift is similar to Kotlin's !!.)
What I'm specifically looking for:
A name that I can verbally call the !! operation that Kotlin developers can understand
A name other than double exclamation or bang bang or double bang
The Kotlin documentation refers to it as the not-null assertion operator.
Personally, I call it the hold my beer operator.
"Kotlin in Action" calls it the not-null assertion operator. We've decided to update the docs to use this term too.
I use to call it "double bang", but actually hold my beer operator does get to the heart of it too (thx #Todd ;-)).
I like to say "non-null asserted call" for things like
a!!.length
that is also how it is shown in the Android studio ALT+ENTER context menu.
Makes sense to me because that sums up what it is actually doing.
I'm using "force-unwrapping" (same as is in Swift).
Related
What would be the best way to convert Java Optional to Arrows Option? I was expected to have something out-of-box, but it's not there. Something like:
fun <T> Optional<T>.toOption(): Option<T> = if (this.isPresent) Some(this.get()) else none()
There is no such function at the moment, but such a contribution would be welcomed!
Arrow however does not recommend using Option unless absolutely necessary. The only use-case being nested nulls, which is the limitation for ReactiveX implementation of RxJava & Project Reactor. Both libraries don't allow null being used for their generic value A in Flowable, Flux, Mono, etc.
Analogue, you cannot use null as an empty signal for generic code in Kotlin. Unless A is constraint to be non-null by using A : Any.
Only in both cases should you use Arrow's Option, otherwise using Kotlin's nullable type is recommended by the Arrow maintainers.
When would we ever need with in Kotlin if we can already use apply, run, also and let?
Can anyone give me a clear example?
In most situations, a with call can be transformed to a run like this:
with(foo) {
// some code ...
}
// is the same as:
foo.run {
// the same code ...
}
run and with will both return the lambda result, and will use foo as the lambda receiver.
However, I can think of one case where this wouldn't work - when foo declares its own run method that takes a lambda, e.g.
// having something like this isn't too uncommon, right?
fun run(x: () -> Unit) {}
The lambda type doesn't have to be exactly the same as the scope function run. Any function type should work. Then overload resolution wouldn't resolve to the built-in run.
You can force the resolution by doing some casts, but using with in this case is much better. Don't you agree?
I don’t think there’s any better example than with(context). Maybe it’s not clear if English isn’t one of your primary languages, but it semantically is translated into English much clearer than context.run when the object is being used to produce a result but isn’t the primary actor, so it makes code a little easier to read.
This of course raises the question of why run exists. Well, it semantically makes more sense in English when the object is the thing doing the action. In English, the context of an action is what you’re doing something with. But if the object is what is directly producing the result, then it is running the action.
Also, you can’t do ?.with.
I’m trying to figure out what the differences are between the above-mentioned routines, and if statements like
say $y.Bool;
say $y.so;
say ? $y;
say so $y;
would ever produce a different result.
So far the only difference that is apparent to me is that ? has a higher precedence than so. .Bool and .so seem to be completely synonymous. Is that correct and (practically speaking) the full story?
What I've done to answer your question is to spelunk the Rakudo compiler source code.
As you note, one aspect that differs between the prefixes is parsing differences. The variations have different precedences and so is alphabetic whereas ? is punctuation. To see the precise code controlling this parsing, view Rakudo's Grammar.nqp and search within that page for prefix:sym<...> where the ... is ?, so, etc. It looks like ternary (... ?? ... !! ...) turns into an if. I see that none of these tokens have correspondingly named Actions.pm6 methods. As a somewhat wild guess perhaps the code generation that corresponds to them is handled by this part of method EXPR. (Anyone know, or care to follow the instructions in this blog post to find out?)
The definitions in Bool.pm6 and Mu.pm6 show that:
In Mu.pm6 the method .Bool returns False for an undefined object and .defined otherwise. In turn .defined returns False for an undefined object and True otherwise. So these are the default.
.defined is documented as overridden in two built in classes and .Bool in 19.
so, .so, and ? all call the same code that defers to Bool / .Bool. In theory classes/modules could override these instead of, or as well, as overriding .Bool or .defined, but I can't see why anyone would ever do that either in the built in classes/modules or userland ones.
not and ! are the same (except that use of ! with :exists dies) and both turn into calls to nqp::hllbool(nqp::not_i(nqp::istrue(...))). I presume the primary reason they don't go through the usual .Bool route is to avoid marking handling of Failures.
There are .so and .not methods defined in Mu.pm6. They just call .Bool.
There are boolean bitwise operators that include a ?. They are far adrift from your question but their code is included in the links above.
Since '+', '-', and the rest of the arithmetic operators must be, at heart, just function calls (I think), how are they defined? More specifically, how are they written such that they can look for arguments that precede them and follow them?
For example, the function '*', or multiply, in the expression 7 * 9 must look for the first argument 7 before it's called, and then the 9, it's second argument, which appears to be in the right place.
Most languages (not OCaml) require parentheses around arguments -- how have they gotten around this requirement in languages that do?
It sounds like you're asking about operator overloading, or at least reading into operator overloading will give you a pretty solid understanding on how arithmetic operations are defined in some languages. Here's a link to a nice tutorial on C++ operator overloading:
http://www.tutorialspoint.com/cplusplus/cpp_overloading.htm
In object-oriented world, this is called "operator overloading". It is just a kind of syntactic sugar, that enables you to call a + b, instead of a.+(b), that is actually the same method call.
What happened to me while programming in Java:
String str
// want to call something(), but signature does not match
something(Foo foo)
// but I have this conversion function
Foo fooFrom(String)
// Obviously I am about to create another method overload.. sigh
something(String s) {
something(fooFrom(s));
}
But then I thought of the possibility of a "automatic type conversion" which just uses my defined conversion function fooFrom everytime a string is passed in where a Foo object is excepted.
My search brought me to the wikipedia page about type conversion with this Eiffel example:
class STRING_8
…
create
make_from_cil
…
convert
make_from_cil ({SYSTEM_STRING})
to_cil: {SYSTEM_STRING}
…
The methods after convert are called automatically if a STRING_8 is used as a SYSTEM_STRING and vice-versa.
Somehow surprising for me I could not find any other language supporting this.
So my question: are there any other languages supporting this feature?
If not, are there any reasons for that, since it seems quite useful to me?
Further I think it would not be difficult to implement it as a language add-on.
There is one minor point that may make the things a bit more complicated. At the moment Eiffel has a rule that conversion can be applied only when the source of reattachment is attached to an object, i.e. is not Void (not null in Java/C#).
Let's look at the original example:
something (str);
Suppose that str is null. Do we get a NullPointerException / InvalidArgumentException, because the code is transformed into
something (fooFrom (str));
and fooFrom does not expect null? Or is the compiler smart enough to transform this into
if (str == null)
something (null);
else
something (fooFrom (str));
?
The current Eiffel standard makes sure that such issues simply do not happen and str is not null if conversion is involved. However many other languages like Java or C# do not guarantee that and the additional complexity may be not worth the effort for them.
I believe that Eiffel is not the only language to support conversion routines, but I would say that it might be one of the very few that integrate this very nicely with the rest of the language definition.
In .NET, for example, you have both op_Explicit and op_Implicit routines that can be used for conversion for languages that support them. And I believe C# does.
Manu
Type coercion (implicit conversion) is a curse and a blessing--handy in some case, but it can also backfire.
For instance, Javascript has many weird coercion rules, that can leads to bug when coercings string to number, etc.
Scala has something called "implicit" which achieves something similar (at least to me) to what you describe in Eiffel. With little surprise, they can lead to certain gotchas. But they can be also very handy, see for instance the article Pimp My Library.
C++ has copy constructors and assignment operator.