Why does not Swashbuckle generate the required constraint for all the not Nullable value types? Anyway, is it a good idea to do so?
By default, Swashbuckle does not mark as required any fields of exposed objects.
To do so, you should just add the RequiredAttribute on properties you need to be required from the Swagger definition file.
Swagger specifications are at start not treating any fields as required by default; from specifications on required:
Determines whether this parameter is mandatory. If the parameter is in
"path", this property is required and its value MUST be true.
Otherwise, the property MAY be included and its default value is false
Related
In ember documentation it says the following for the method DS.attr():
By default, attributes are passed through as-is, however you can
specify an optional type to have the value automatically transformed
If you go to the transform method documentation it says the following:
You can specify that you would like a transform to run for an
attribute by providing the transform name as the first argument to the
attr method. Ember Data supports attribute types of string, number,
boolean, and date, which coerce the value to the JavaScript type that
matches its name.
So my question is: is it bad to explicitly insert the type of the attribute? It seems it forces some kind of cast as mentioned after (quoted below). So it could have some performance decrease (almost nothing).
The boolean transform can handle values other than true or false. The
strings "true" or "t" in any casing, "1", and the number 1 will all
coerce to true, and false otherwise.
The only reason I see to insert the type is to make it easier to read in your model, but that can be done in a comment as well...
No, it's not bad to insert the type of the attribute. It's actually good.
While there may be some negligible performance decrease when loading data into the Store, you get the added benefit of consistent types when working with your models regardless of what your API may return.
If you were to only use comments to specify types, you may be telling other developers what type is expected to be in the model, but the API could return anything it wants. In that case the expected type and the actual type may not match.
I tend to believe this is a bad practice unless you have an API that is very buggy that you do not control and will sometimes deliver an attribute with varying types for the same field. In general, an API should be reliable in how it delivers types. Setting the type in Ember causes it to do type-coercion which is never a good idea in JavaScript because JavaScript is surprisingly terrible at type-coercion.
As for the fact that this documents your types, I agree that's a good idea. However, in modern Ember TypeScript is a far better tool to document types because the documentation is actually enforced.
In Kotlin there are two ways to express an optional parameter, either by specifying default argument value:
fun foo(parameter: Any, option: Boolean = false) { ... }
or by introducing an overload:
fun foo(parameter: Any) = foo(parameter, false)
fun foo(parameter: Any, option: Boolean) { ... }
Which way is preferred in which situations?
What is the difference for consumers of such function?
In Kotlin code calling other Kotlin code optional parameters tend to be the norm over using overloads. Using optional parameters should be you default behavior.
Special cases FOR using defaulted values:
As a general practice or if unsure -- use default arguments over overrides.
if you want the default value to be seen by the caller, use default values. They will show up in IDE tooltips (i.e. Intellij IDEA) and let the caller know they are being applied as part of the contract. You can see in the following screenshot that calling foo() will default some values if values are omitted for x and y:
Whereas doing the same thing with function overloads hides this useful information and just presents a much more messy:
using default values causes bytecode generation of two functions, one with all parameters specified and another that is a bridge function that can check and apply missing parameters with their defaulted values. No matter how many defaulted parameters you have, it is always only two functions. So in a total-function-count constrained environment (i.e. Android), it can be better to have just these two functions instead of a larger number of overloads that it would take to accomplish the same job.
Cases where you might not want to use default argument values:
When you want another JVM language to be able to use the defaulted values you either need to use explicit overloads or use the #JvmOverloads annotation which:
For every parameter with a default value, this will generate one additional overload, which has this parameter and all parameters to the right of it in the parameter list removed.
You have a previous version of your library and for binary API compatibility adding a default parameter might break compatibility for existing compiled code whereas adding an overload would not.
You have a previous existing function:
fun foo() = ...
and you need to retain that function signature, but you also want to add another with the same signature but additional optional parameter:
fun foo() = ...
fun foo(x: Int = 5) = ... // never can be called using default value
You will not be able to use the default value in the 2nd version (other than via reflection callBy). Instead all foo() calls without parameters still call the first version of the function. So you need to instead use distinct overloads without the default or you will confuse users of the function:
fun foo() = ...
fun foo(x: Int) = ...
You have arguments that may not make sense together, and therefore overloads allow you to group parameters into meaningful coordinated sets.
Calling methods with default values has to do another step to check which values are missing and apply the defaults and then forward the call to the real method. So in a performance constrained environment (i.e. Android, embedded, real-time, billion loop iterations on a method call) this extra check may not be desired. Although if you do not see an issue in profiling, this might be an imaginary issue, might be inlined by the JVM, and may not have any impact at all. Measure first before worrying.
Cases that don't really support either case:
In case you are reading general arguments about this from other languages...
in a C# answer for this similar question the esteemed Jon Skeet mentions that you should be careful using defaults if they could change between builds and that would be a problem. In C# the defaulting is at the call site, whereas in Kotlin for non-inlined functions it is inside of the (bridge) function being called. Therefore for Kotlin it is the same impact for changing hidden and explicit defaulting of values and this argument should not impact the decision.
also in the C# answer saying that if team members have opposing views about use of defaulted arguments then maybe don't use them. This should not be applied to Kotlin as they are a core language feature and used in the standard library since before 1.0 and there is no support for restricting their use. The opposing team members should default to using defaulted arguments unless they have a definitive case that makes them unusable. Whereas in C# it was introduced much later in the life cycle of that language and therefore had a sense of more "optional adoption"
Let's examine how functions with default argument values are compiled in Kotlin to see if there's a difference in method count. It may differ depending on the target platform, so we'll look into Kotlin for JVM first.
For the function fun foo(parameter: Any, option: Boolean = false) the following two methods are generated:
First is foo(Ljava/lang/Object;Z)V which is being called when all arguments are specified at a call site.
Second is synthetic bridge foo$default(Ljava/lang/Object;ZILjava/lang/Object;)V. It has 2 additional parameters: Int mask that specifies which parameters were actually passed and an Object parameter which currently is not used, but reserved for allowing super-calls with default arguments in the future.
That bridge is called when some arguments are omitted at a call-site. The bridge analyzes the mask, provides default values for omitted arguments and then calls the first method now specifying all arguments.
When you place #JvmOverloads annotation on a function, additional overloads are generated, one per each argument with default value. All these overloads delegate to foo$default bridge. For the foo function the following additional overload will be generated: foo(Ljava/lang/Object;)V.
Thus, from the method count point of view, in a situation when a function has only one parameter with default value, it's no matter whether you use overloads or default values, you'll get two methods. But if there's more than one optional parameter, using default values instead of overloads will result in less methods generated.
Overloads could be preferred when the implementation of a function gets simpler when parameter is omitted.
Consider the following example:
fun compare(v1: T, v2: T, ignoreCase: Boolean = false) =
if (ignoreCase)
internalCompareWithIgnoreCase(v1, v2)
else
internalCompare(v1, v2)
When it is called like compare(a, b) and ignoreCase is omitted, you actually pay twice for not using ignoreCase: first is when arguments are checked and default values are substituted instead of omitted ones and second is when you check the ignoreCase in the body of compare and branch to internalCompare based on its value.
Adding an overload will get rid of these two checks. Also a method with such simple body is more likely to be inlined by JIT compiler.
fun compare(v1: T, v2: T) = internalCompare(v1, v2)
I have a question on the COM interfaces exposed from an application. Can I have a COM interface where some parameters have default values similar to the one allowed by C++?
Default values can be defined with interface definition in IDL and are language agnostic. A method argument can be provided with a defaultvalue attribute, and then defaultvalue attribute article on MSDN states:
The MIDL compiler accepts the following parameter ordering (from left-to-right):
Required parameters (parameters that do not have the [defaultvalue] or [optional] attributes),
optional parameters with or without the [defaultvalue] attribute,
parameters with the [optional] attribute and without the [defaultvalue] attribute,
[lcid] parameter, if any,
[retval] parameter
Note that only optional parameters can have defaultvalue attribute. This makes sense as non-optional parameter always comes with explicit value. This also means that any parameter having default value is actually a VARIANT parameter (effectively this is not true though: IDL compiler accepts defaultvalue attribute on non-VARIANT parameters).
Parameters with default values have restrictions on types:
The default value you specify for the parameter can be any constant, or an expression that resolves to a constant, that can be represented by a VARIANT. Specifically, you cannot apply the [defaultvalue] attribute to a parameter that is a structure, an array, or a SAFEARRAY.type.
Information about the default value stays on the IDL and the respective type library. It is the responsibility of the caller to read it and substitute at the time of the call. C++ clients #import'ing the type library will have to supply the value explicitly anyway. C# client adding such type library as a reference will extract default value and translate it into optional parameter with this default value and then will use it on the caller side of the call in such way that server sees no difference whether this value is default or explicitly given.
On the implementation side, a parameter with default value is identical to regular parameter with no default value defined: the actual value is always provided by the caller.
i'm using Orbeon section templates in a common library that i use in multiple forms.
I need some values of a given section template to determine the visibility of some controls in other sections of my form. So i'm looking for a solution to parametrize the section template in order to never access its inner control values.
Can someone pls explain to me how to achieve that?
To refer to the value of a field which is inside a section template from a field outside of that section template (and itself not in another section template), you can't use the $field-name syntax. You can from inside the section template, but not from outside the section template. This is because section templates really encapsulate their content, thus allowing you, for instance, to have multiple instances of the same section template in your form, or multiple section templates using the same field names.
So, to answer your question, this is a case where you need to use a path expression. Say the field you want to refer to is named street and you named that particular instance of the template shipping, then you can refer to the value of the field with the expression /form/shipping/street. If you add another instance of that same template, and name that instance billing, then you could refer to that other street field as /form/billing/street.
I have a section of a schema for a model that I need to parse. Lets say it looks like the following.
{
type = "Standard";
hostname="x.y.z";
port="123";
}
The properties are:
The elements may appear unordered.
All elements that are part of the schema must appear, and no other.
All of the elements' synthesised attributes go into a struct.
(optional) The schema might in the future depend on the type field -- i.e., different fields based on type -- however I am not concerned about this at the moment.
According to the Spirit forums, the following is the answer.
You might want to have a look at the
permutation parser:
a ^ b ^ c
Which matches a or b or c (or a
combination thereof) in any sequence.
If the objective is to parse into a struct, than the best way to test weather all essential members have been initialized, the struct members should be wrapped with boost::optional<> The attribute presence may then be easily tested post-parsing during run-time.