We're using the ifnull function in one of our Splunk queries (yes, ifnull not isnull), and I wanted to look up the logic just to be sure, but I can't find it documented anywhere.
It is referenced in a few spots:
SPL data types and clauses
Eval
Where
But I can't find a definition/explanation anywhere on what it actually does. Google seems to be of no help either (constantly wants to redirect me to isnull).
In particular it's also not listed in "common evaluation functions".
Can anyone point me to some documentation about ifnull?
TL;DR; it's an alias for coalesce
Wow, it really is hidden! I managed to find it on my local instance here: ./etc/system/default/searchbnf.conf
example4 = coalesce(null(), "Returned value", null())
comment4 = Takes any number of arguments and returns the first value that is not null. The ifnull function does the exact same thing, so both names are acceptable.
Related
In my cloudformation code (yaml file) I want to write condition that check if string parameter is longer than some value(lets say 15) and I did not find any way to do it.
Two main questions are,
How to get string parameter length?
After I have the length, how can I write condition that check if this length is longer/smaller than specific value?
I wish cloudformation has a Fn like LongerThan or something like this
Conditions:
isLongerThanParam:
'Fn::LongerThan':
- {Ref: Param}
- '15'
But they only support these functions: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html
I did not find any way to do it
There is no such functionality in CFN. You already provided the link to available conditional checks, and there are no condition to check if something is greater or lower then something else.
Some possible workaround would possibly involve development of CloudFormation macro, which would be in the form of a lambda function. The function would take your Fn::LongerThan, and performed some transformations of it based on how you want it to behave. As an outcome of the macro, the valid conditions would be returned, whether or not Fn::LongerThan is satisfied.
to is an infix function within the standard library. It can be used to create Pairs concisely:
0 to "hero"
in comparison with:
Pair(0, "hero")
Typically, it is used to initialize Maps concisely:
mapOf(0 to "hero", 1 to "one", 2 to "two")
However, there are other situations in which one needs to create a Pair. For instance:
"to be or not" to "be"
(0..10).map { it to it * it }
Is it acceptable, stylistically, to (ab)use to in this manner?
Just because some language features are provided does not mean they are better over certain things. A Pair can be used instead of to and vice versa. What becomes a real issue is that, does your code still remain simple, would it require some reader to read the previous story to understand the current one? In your last map example, it does not give a hint of what it's doing. Imagine someone reading { it to it * it}, they would be most likely confused. I would say this is an abuse.
to infix offer a nice syntactical sugar, IMHO it should be used in conjunction with a nicely named variable that tells the reader what this something to something is. For example:
val heroPair = Ironman to Spiderman //including a 'pair' in the variable name tells the story what 'to' is doing.
Or you could use scoping functions
(Ironman to Spiderman).let { heroPair -> }
I don't think there's an authoritative answer to this. The only examples in the Kotlin docs are for creating simple constant maps with mapOf(), but there's no hint that to shouldn't be used elsewhere.
So it'll come down to a matter of personal taste…
For me, I'd be happy to use it anywhere it represents a mapping of some kind, so in a map{…} expression would seem clear to me, just as much as in a mapOf(…) list. Though (as mentioned elsewhere) it's not often used in complex expressions, so I might use parentheses to keep the precedence clear, and/or simplify the expression so they're not needed.
Where it doesn't indicate a mapping, I'd be much more hesitant to use it. For example, if you have a method that returns two values, it'd probably be clearer to use an explicit Pair. (Though in that case, it'd be clearer still to define a simple data class for the return value.)
You asked for personal perspective so here is mine.
I found this syntax is a huge win for simple code, especial in reading code. Reading code with parenthesis, a lot of them, caused mental stress, imagine you have to review/read thousand lines of code a day ;(
As the HELP document says:
The FIND function and the INDEX function both search for substrings of characters in a character string. However, the INDEX function does not have the modifier nor the start-position arguments.
so why we have the both functions? Can't we just replace index() with find()?
Thanks in advance.
Welcome to SAS. This is an old language and there are many not so obvious solutions. Despair not, for more often there is an answer than not!
As for your question: They allow a bit different things, but function in similar fashion when doing a simple thing.
Index returns the position of the specified string. Documentation
Find allows you to narrow down the range where you look for. Documentation
As indicated by #Richard, the find() function was added to SAS after the index() function. This can be seen in the "What's New" details SAS provide here.
If, as indicated elsewhere, you have trouble getting to the link, then perform a web search for "What's new in SAS 9", the first result (for me) was from SAS, then within that result look for details on "SAS Language Features". This shows that find() was newly introduced then, with some new abilities compared to index().
I've recently encountered these two variables in some Velocity code:
$!variable1
!$variable2
I was surprised by the similarity of these so I became suspicious about the correctness of the code and become interested in finding the difference between two.
Is it possible that velocity allows any order of these two symbols or do they have different purpose? Do you know the answer?
#Jr. Here is the guide I followed when doing VM R&D: http://velocity.apache.org/engine/1.7/user-guide.html
Velocity uses the !$ and $! annotations for different things. If you use !$ it will basically be the same as a normal "!" operator, but the $! is used as a basic check to see if the variable is blank and if so it prints it out as an empty string. If your variable is empty or null and you don't use the $! annotation it will print the actual variable name as a string.
I googled and stackoverflowed a lot before I finally found the answer at people.apache.org.
According to that:
It is very easy to confuse the quiet reference notation with the
boolean not-Operator. Using the not-Operator, you use !${foo}, while
the quiet reference notation is $!{foo}. And yes, you will end up
sometimes with !$!{foo}...
Easy after all, shame it didn't struck me immediately. Hope this helps someone.
In this question, a user commented to never use the With block in VB. Why?
"Never" is a strong word.
I think it fine as long as you don't abuse it (like nesting)
IMHO - this is better:
With MyCommand.Parameters
.Count = 1
.Item(0).ParameterName = "#baz"
.Item(0).Value = fuz
End With
Than:
MyCommand.Parameters.Count = 1
MyCommand.Parameters.Item(0).ParameterName = "#baz"
MyCommand.Parameters.Item(0).Value = fuz
There is nothing wrong about the With keyword. It's true that it may reduce readibility when nested but the solution is simply don't use nested With.
There may be namespace problems in Delphi, which doesn't enforce a leading dot but that issue simply doesn't exist in VB.NET so the people that are posting rants about Delphi are losing their time in this question.
I think the real reason many people don't like the With keyword is that is not included in C* languages and many programmers automatically think that every feature not included in his/her favourite language is bad.
It's just not helpful compared to other options.
If you really miss it you can create a one or two character alias for your object instead. The alias only takes one line to setup, rather than two for the With block (With + End With lines).
The alias also gives you a quick mouse-over reference for the type of the variable. It provides a hook for the IDE to help you jump back to the top of the block if you want (though if the block is that large you have other problems). It can be passed as an argument to functions. And you can use it to reference an index property.
So we have an alternative that gives more function with less code.
Also see this question:
Why is the with() construct not included in C#, when it is really cool in VB.NET?
The with keyword is only sideswiped in a passing reference here in an hilarious article by the wonderful Verity Stob, but it's worth it for the vitriol: See the paragraph that starts
While we are on identifier confusion. The with keyword...
Worth reading the entire article!
The With keyword also provides another benefit - the object(s) in the With statement only need to be "qualified" once, which can improve performance. Check out the information on MSDN here:
http://msdn.microsoft.com/en-us/library/wc500chb(VS.80).aspx
So by all means, use it.