Check if call result is undefined - scala.js

how can I check if the result to call a JavaScript function is undefined?
I tried with
if( s.getNode(id1) != js.undefined)
but fastOptJS say:
scala.scalajs.js.Dynamic and scala.scalajs.js.UndefOr[Nothing] are
unrelated: they will most likely always compare unequal
TIA

This is Scala's type system being a bit "too" helpful.
To compare against undefined, you can use js.isUndefined:
if (!js.isUndefined(s.getNode(id1)))

Related

Why do I get this compiler error with the djb2 hash function

I copied and pasted the widely available code for the djb2 hashing function, but it generates the error shown below (I am using the CS50.ide, which may be a factor). Since this error IS fixed by a second set of parentheses, can someone explain why those aren't in the code I find everywhere online?
dictionary.c:67:14: error: using the result of an assignment as a condition without
parentheses [-Werror,-Wparentheses]
while (c = *word++)
~~^~~~~~~~~
dictionary.c:67:14: note: place parentheses around the assignment to silence this
warning
while (c = *word++)
^
( )
dictionary.c:67:14: note: use '==' to turn this assignment into an equality comparison
while (c = *word++)
^
==
= is used for setting variables to a value. == is the relational operator used for comparing the equality of values. Perhaps you are finding the C++ version of the function. Perhaps it is the IDE compiler rules/config.+
I understand about = vs ==. My question was how come i get the compiler error with code that is correct, since it is a well established hash function.
turns out is related to the cs50 makefile being more stringent than clang on it's own. needlessly frustrating.

Slick "for/yield"-query doesn't compile with negative comparison

I ran into an odd problem with my slick-query:
As you can see, the function below is compiling although it's basically the same query but with a possitive comparison (I don't know if it's actually doing what it's supposed to do, though). When swapping the order of the if conditions, it tells me that && cannot be resolved. I don't know if that's the case, but I guess the second table query object, in this case contents, doesn't seem to be finished yet. However, that begs the question why the second function/query is compiling properly.
Do you have an answer to this? Am I doing something wrong here?
Thanks in advance!
You should use =!= for inequality and === for equality in queries according to slick docs
I guess I've fixed the problem.
Instead of:
if a.documentId === documentId && b.contentTypeId !== ContentType.PROCESS
I needed to write:
if a.documentId === documentId && !(b.contentTypeId === ContentType.PROCESS)
Still a weird behavior I can't really explain, espacially since negative comparisons like !== are generally allowed in those if-statements

What is the difference between ByRef and Output method argument modifiers?

All is in the subject, really.
I fail to see what the difference in behavior is between those two methods for x:
// first version
Method m(ByRef x As whatever)
{
// play with x
}
// second version
Method m(Output x As whatever)
{
// play with x
}
There must be some reason why both those modifiers exist, however my "mastery" (uhm) of the language is not enough to understand the difference. I have tried and read the documentation, search it etc, to no avail so far.
So, what is the difference between those two argument modifiers?
Well those are just "prettifiers", they don't do much in terms of actual language behaviour, and only used to provide documentation. Idea is that arguments documented as ByRef provide both input and output, for example you can pass an array to be sorted, and Output arguments only provide output, for example list of errors. Output modifier was introduced later, and a lot of system code still use ByRef for both use cases.
If argument is actually passed by reference is only determined by method caller, and keyword doesn't really matter. You will call your method as ..m(.parameter) to pass variable by reference, and ..m(parameter) to pass variable by value.

Perl references. How do we know it is one?

I am new to Perl and reading about references.
I can not understand how doe one know if the variable he work on is a reference.
For instance if I understand correctly, this:
$b = $a could be assigning scalars or references. How do we know which is it?
In C or C++ we would know via the function signature (*a or &a of **a). But in Perl there is no signature of parameters.
So how do we know in code what is a reference and what is not? Or if it is a reference to scalar or array or hash or another reference?
Perl has a ref that you can use for that:
Returns a non-empty string if EXPR is a reference, the empty string otherwise. [...]
The string returned (if non-empty) will tell you the type of object the reference references.
You're asking the wrong question.
While there is a function called ref and another called reftype, these are not functions you should ever need to use.
It's bad to check the type of variables, because there's no way to effectively know without actually using it as intended due to overloading and magic.
For example, say you designed a function that accepts a reference or a string. That would be a bad design because an object that overloads stringification is both.
A good interface would use context to differentiate the arguments. For example, it could differentiate based on the number of arguments,
foo($point_obj)
-vs-
foo(x => $x, y => $y)
based on the value of other arguments,
foo(fh => $fh)
-vs-
foo(str => $file_contents)
or based on the choice of function called
foo_from_fh($fh)
-vs-
foo($file_contents)
So the answer is: You know it's a reference because your documentation instructs the caller of your function to pass a reference. If you got passed something other than a reference and it's used as a reference, the caller will get a strict error for their error.
The ref function is what you're looking for. Documentation is available at http://perldoc.perl.org/functions/ref.html
ref EXPR
Returns a non-empty string if EXPR is a reference, the empty string otherwise. If EXPR is
not specified, $_ will be used. The value returned depends on the type of thing the
reference is a reference to...

iPhone SDK: Please explain why "nil ==" is different than "== nil"

I have been programming iPhone SDK for around 6 months but am a bit confused about a couple of things...one of which I am asking here:
Why are the following considered different?
if (varOrObject == nil)
{
}
vs
if (nil == varOrObject)
{
}
Coming from a perl background this is confusing to me...
Can someone please explain why one of the two (the second) would be true whereas the first would not if the two routines are placed one after the other within code. varOrObject would not have changed between the two if statements.
There is no specific code this is happening in, just that I have read in a lot of places that the two statements are different, but not why.
Thanks in advance.
They are the same. What you have read is probably talking about if you mistakenly write == as =, the former will assign the value to the variable and the if condition will be false, while the latter would be a compile time error:
if (variable = nil) // assigns nil to variable, not an error.
if (nil = variable) // compile time error
The latter gives you the chance to correct the mistake at compile time.
They might be different if you are using Objective-C++ and you were overriding the '==' operator for the object.
They are exactly the same, it is just a style difference. One would never be true if the other is false.
if it's a recommendation that you use the latter, it's because the second is easier to catch if you accidentally type =. otherwise, they are identical and your book is wrong.
They can only be different if the "==" - Operator is overloaded.
Let's say someone redefines "==" for a list, so that the content of two lists is checked rather than the memory adress (like "equals() in Java). Now the same person could theoretically define that "emptyList == NULL".
Now (emptyList==NULL) would be true but (NULL==emptyList) would still be false.