I have been using what some call "sentinel" default values to determine when an argument has been passed (null or something other than the sentinel value). If the sentinel value is received, then the convention is that the parameter must not have been passed by the caller.
This avoids the ambiguity of using something like "null" as the default value, as it then becomes impossible to determine if "null" was passed by the caller or was provided as the default value.
Some languages support bitmaps or other methods to determine when data has been changed or referenced in contexts other than method / function / procedure calls.
And some environments, e.g. .NET, support reflection, which might allow a "complex" implementation to compare actual to default values.
So my question is, which languages support this directly, and what is the syntax?
For example:
function able(Parm1 default "rho", Parm2 default "epsilon")
{
If SpecifiedByCaller(Parm1)
do something with Parm1
else
use Parm1 "knowing" it was a default value
}
Related
IntelliJ is showing me context hints that my variables are of type (String..String?). I cannot find any mention of it on the internet, what is this type?
(String..String?) represents a flexible type with lower bound String and upperbound String? (nullable string). This is not valid Kotlin code (it's not denotable) but it is used in the compiler internals and thus in IntelliJ's hints sometimes.
(On the JVM we often see platform types using ! as in String!, which are a more specific case of flexible types)
It's Kotlin's way of saying it doesn't know whether the String type declared for payload.email is nullable or not (for instance if this is declared in Java, which doesn't distinguish those), and yet it doesn't want to enforce either of those, for convenience (hence "flexible").
As the name suggests, flexible types are flexible — a value of type (L..U) can be used in any context, where one of the possible types between L and U is needed
This means that even though the actual type of the value is "somewhere between String and String?", values of this type can be used even in places expecting String, even though the real type of that value may be String? and thus the value could be null.
This is useful because assuming it is String would mean that null checks would be marked as redundant, and assuming it is String? would force the developer to write null checks everywhere, even though they might know that this particular Java method cannot return null.
In general, it's a good practice to explicitly declare the type of a variable that you get from Java, to avoid the propagation of the platform type and the uncertainty (and unsafety) that comes with it:
val email: String = payload.email // if you know it cannot be null
val email: String? = payload.email // if you don't know
If I have a COM interface method expecting BSTR and SAFEARRAY parameters, but these are optional, what is the correct way to implement this? Can I pass NULL or do I need to pass empty strings and zero-length arrays? Or would I be better passing VARIANTs which can be VT_EMPTY or VT_BSTR / VT_ARRAY?
e.g.
Login([in]BSTR Name, [in]BSTR Password /*optional*/);
SendEmail([in]SAFEARRAY *To, [in]SAFEARRAY *Cc /*optional*/);
In these examples, should Password be passed as NULL or ""? And should Cc be passed as NULL, or do I need to create a 0-length SAFEARRAY, or pass a VARIANT of type VT_EMPTY... which are valid/sensible options?
Well, those sort of arguments really aren't quite right--the MIDL compiler should throw a warning or even an error if you try to make anything other than a VARIANT to be "optional".
The correct way is to define default values ("defaultvalue"). For BSTRs you want to make the default value to be L"" and not 0 (NULL). If you make the default value for BSTRs to be 0, you will run into problems down the road--I think in some .NET interop.
For the SAFEARRAY it should be safe to make the "defaultvalue" to be NULL.
Of course, this advice is from the point of designing how the interface ought to be. You may be in the situation where someone has already designed and implemented the interface. In that case, you're at the mercy of their implementation. For the BSTR arguments, I would try passing in empty strings (L"") and for the SAFEARRAY I would try passing in NULL.
If you are going to define it as "optional", make it a variant. And in that case, the correct argument is VT_EMPTY.
I have a question about preferences.
I have used and seen used both of these examples and was wondering if one is better/faster/preferred over the other...
Using SQL Server 2008
(RS = RecordSet)
RS!field
vs
RS.Fields("Field")
The first is shorter, quicker to type, but is there any advantage to one or the other?
No, they are equivalent in VB. From the documentation:
Use the ! operator only on a class or interface as a dictionary access operator. The class or interface must have a default property that accepts a single String argument. The identifier immediately following the ! operator becomes the argument value passed to the default property as a string.
Since Fields is the "default" property for Recordset and Item is the default property for Fields,
RS!field
is compiled to
RS.Fields("field")
which is technically
RS.Fields.Item("field")
Note that you can also do
RS("field")
is one better/faster/preferred over the other?
Faster? No. Preferred? Well the latter usage is more consistent with other .NET languages, so it may be preferred in larger circles because of that.
What's the difference between values and literals? Values apparently have dynamic type, and literals apparently have static type, according to slide four of the first page in Here. But isn't a literal a value?
Using the terms used in that slideshow - a literal is kind of container, so it'll be better to compare between values and containers.
A container "contains" a value. If you write int x=1;, then x is a container and the number one is a value. But 1 is also a container - more precisely, a literal. The slideshow stress that there is a difference between the value one and the literal 1.
When you code, you can't actually access values directly - you can only do it via containers. That's why you can write x and 1, but not the value that is the number one.
A literal is a container that can be translated directly to a value without looking at it's surrounding - for example 1 can be translated directly to the number one. x can not be translated to a value in such a way, since it's a variable and we don't know what it holds unless we look at the surrounding code.
As for the dynamic vs static types - a container has a static type, known at compile-time. If it's a variable, it's the declared type of the variable. If it's an expression, it's the inferred type of the expression. If it's a literal, it's the direct type of the literal. The compiler can tell the type of each container without running the program and without caring what values it'll hold once the program runs.
A value, on the other hand, is stored in memory as a series of bytes. The type data is also stored in memory near the value(unless it's a primitive value), that's why the types of values are dynamic - because if you want to discover what type a value has, you have to look in the memory during runtime.
Even though values' types are dynamic, Java is a static language since you usually don't look at the dynamic type. Since you can only refer a value via a container, the static type of the container is used when you do things with the value.
For instance, when to use
GetterUtil.getBoolean()
and when
ParamUtil.getBoolean()?
Are both same, or is it expected to be used differently according to a parameter, a variable, etc? Can you give some examples for both?
Both are util methods to avoid Null-Pointer Exceptions.
GetterUtil internally returns the default type and does the casting too. So in case where someone has passed a null value, it will return default value of the type.
Example:
Assume you have a String value "true", and you are expecting it will always be of type boolean. So you use GetterUtil.getBoolean("true") which will internally do the casting to boolen and return the value as boolean-true. Incase someone passes rubbish characters like "tr", it will be converted to boolean-false.
As mentioned ParamUtil does the same treatment with request parameters. ParamUtil internally uses the GetterUtil to have the above behaviour. It first retrieves the parameter (which always would be a string) and then passes it to GetterUtil.getType() method and in turn returns the proper type.
GetterUtil and ParmUtil both are different classes.
GetterUtil is to get the default values for basic Java data types.
ParamUtil is to retrive the values(of primitive data types) from the HttpReqeust.
Check the source code here for these two classes here
For GetterUtil
http://docs.liferay.com/portal/6.0/javadocs/src-html/com/liferay/portal/kernel/util/GetterUtil.html
For ParamUtil
http://docs.liferay.com/portal/5.1/javadocs/portal-kernel/com/liferay/portal/kernel/util/ParamUtil.java.html