Azure WebJobs are so simplify to work with parameter binding, so sometimes it is hard to guess which parameter goes from and to.
For example, ProcessQueueMessage([QueueTrigger("webjobsqueue")] MyClass input, string Name, [Blob("container/{Name}", FileAccess.Write)] Stream writer) shows that Name is given from a property in MyClass which is automatically converted from Json string type.
I just copy and use some sense from examples but I don't have concrete knowledge why Name is there and how it is binded with previous MyClass parameter without any words.
I read several links from here and there and even examples, but I want to read whole description of parameter binding rules. Could you provide a well-documented receipe or cheatsheet about this?
There is one cheatsheet (from 2014, so it might be the forthcoming one mentioned in the comments) at http://download.microsoft.com/download/2/2/0/220DE2F1-8AB3-474D-8F8B-C998F7C56B5D/Azure%20WebJobs%20SDK%20Cheat%20Sheet%202014.pdf
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.
Ok, thanks everyone who has looked at this. I've recreated the exact scenario for easy viewing at the link below, so I'll just comment out the original text I had as it wasn't clear.
http://cpp.sh/5lp4l
In the comment section I show calling make_some(32, std::string{"hi"}) without specifying the Data type declaration for the call. I realize this seems insane and way above my expected use case, automatically inferring the composite type (inferring I wanted Data, based on the int/string) based on the arguments wasn't necessary, or a good idea.
The compiler is right. There's just no relation given between T and Args. Hence, it cannot determine what QueryResult<T> means.
What you apparently expect is that the return type of somefn forces T to be int, int. That's obviously not possible for two reasons: T denotes a single type, and there's just no mechanism by which the return statement somehow affects the template instantiation of make_some.
Have you tried using auto as type declaration?
Also decltype (variable_here) variable_to_inherit_type; sets the type of the second variable to that of the first variable. You might be able to first set the type the same as the incoming variable using this.
I am not sure if this will work in your case but let me know if it helps!
Usually in my code I need to use specific functions for various variables i.e.
object->SetStatus("var1",1); object->SetAddress("var1",&var1);
object->SetStatus("var2",1); object->SetAddress("var2",&var2);
object->SetStatus("var3",1); object->SetAddress("var3",&var3);
...
My idea is to use a function that will do this automatically by calling it, i.e.
object->function(var1,var2,var3,...);
To achieve that I have to solve 3 issues
I need to read the number of arguments when calling function()
I need to parse somehow the argument names inside the code
Since the variables are not of the same type, I need to find a way to make function() type "transparent"
Since I am newbie in c++ coding, I tried to search fo something similar, but I couldn't find anything.
Any help, advice or remark is more than welcome!
There are multiple ways to do so. One way is make a Base class and all your variable type will inherit from this base class. Then pass a map<string,Base> as an argument to you function. name of variable will be key and value will be actual variables. Iterate through the map and set and assign values to methods.
You could consider some variadic template, if coding in C++11 or C++14. There is considerable literature about that subject (e.g. this tutorial), which is a bit tricky (so explaining it here is not reasonable). Read also about parameter pack
You could also use C style varargs using <cstdarg>
Perhaps std::initializer_list could be useful too.
I have defined a vararg for list as below in method definition ,
List<String>... valuesList
For example,the below method is to create a sql query with 'where clause' conditions as an input by user.
getRecords(List<String> dbColumnList,List<String>... valuesList)
Is it a good practice to define an API method like this ? The reason I am asking because the compiler throws a warning , "Type safety: A generic array of List is created for a varargs parameter".
Please provide your comments and suggestions.
Krithika,
firstly the issue depends from the version used and will change again in future version.
IMHO it is NOT an issue about "good practice", it is a "vulnerability" of varargs. Since, varargs (as you know) is an array and Java does not permit the creation of arrays of parameterized types, the compiler converts the varargs formal parameter to Object[] ( List[] instead of List[] in the given case) elements losing the "real type".
Then, having taken note of this issue, use varargs only for primitive type when you finish the write API. However, Java knows this issue: see also the dedicated annotation on java 7 #SafeVarargs
http://docs.oracle.com/javase/7/docs/api/java/lang/SafeVarargs.html
if java "admits it", this way should be acceptable.
Finally, see the official documentation.
I want to recognize all of my servers over my office network. They have a particular naming pattern which only I use. I've defined it in a simpleType.
Now I was told I have to filter my servers from a list of full DNS names (like www.bla.moo.oneofmyservers.foo.loo). My naming strategy has a length limit. I would have simply put it inside a *mystrategy* if not for that.
Is there a way to reference my type from within a pattern definition?
It didn't work when I wrote *mytype*.
Assuming that what you're asking is something like this:
I have a pattern and I've used it as a constraining facet in a simple type; now, I want to make another type, and for maintenance purposes, I wish to somehow reference that pattern, so that I don't have to maintain it in two different places...
The answer is no, you can't. Constraining facets in XSD are not referenceable entities; nor types are referenceable within constraining facets.