Passing complex object as parameter to sub-stack - aws-cloudformation

I want to pass the output of a custom resource, which is an array of objects, as parameter to a sub-stack. An example of what I want to pass as parameter to the child stack is :
[
{"Role":"Role1","IdentifierType":"Prefix","Identifiers":"Bucket1"}
{"Role":"Role2","IdentifierType":"Prefix","Identifiers":"Bucket2"}
]
How do I pass this to the sub-stack? I tried declaring the parameter in the child stack as String, and later as CommaDelimitedList. Both the times, the stack gave an error: "Value of property Parameters must be an object with String (or simple type) properties"

As I know until now, there is not way to pass complex objects as a result of of stack execution. Like the message say, the outputs need to be string or single types (integer and boolean in case of cloudformation).
Without more information is hard to help you with alternatives, but let's assume that your Custom Resource is based on lambda. And let's assume that you have control about the code of your Custom Resource. If this is the case you can:
Send the resource identification of your custom resource as a parameter for your nested stack;
Inside nested stack, invoke the lambda function again with the resourceId as a parameter;
Change the lambda code to check for a new parameter for the resourceId (inside the ResourceParameters, not inside the Common Resource Id sent by CloudFormation).
If the parameter is not empty (or not a defined value passed on the first invocation) respond with the old values (you must have a way to keep this values in some place or check then in runtime.);
Change the lambda code to do not take action in the update/deletion is case of invocation by the nested stack (with the resourceId parameter).
Again, is hard to think in alternatives without more info about your specific problem. But use this response as a food for thought.

Related

Prevent object creation if some conditions are violated

In a script I want to create an object of a class only if all the constructor inputs meet some conditions. All the checks are embedded in the constructor itself. Problem is when:
myObj = myClass(input1,input2,...);
is triggered in the script. The object, even when an input doesn't meet the relative condition, is still created eventually with all empty properties.
Inserting the following code within the constructor:
if nargout == 0
clear obj;
end
prevents the creation of the object, but only when the output is assigned to the ans variable. Otherwise, I get an error.
Is there a way to obtain something like that without adding some code directly into the script (like using try)?
If the constructor throws an error, no object will be created. Use error. You can put a try/catch block around the constructor call if you like.
There is no way AFAIK to have the constructor return normally but produce no object. What would be assigned to its output?

Specification builder doesn't recognize transient properties

I'm trying to implement specification in one of my use cases.
As u can see in the function dateValueBetween, I'm trying to get from the root the transient property valueDate. But when calling this service with real data it give the error downside.
My original problem was how to call the builder.between method but the value I have is a String value and need to be parsed.
but it seems that the first argument need to be a property of the table and not a function.
How can I achieve my goal?

What is the relationship of TypeMirrors and Elements in the lang model?

(While this question is tagged with annotation-processing I'm actually asking questions about the type model exposed by javax.lang.model whether or not annotation processing is involved.)
In javax.lang.model, there are two fundamental constructs: Elements and TypeMirrors.
Every Element is backed by a TypeMirror. However only certain TypeMirror subtypes, namely DeclaredType and TypeVariable, have Elements associated with them via DeclaredType#asElement() and TypeVariable#asElement() respectively.
(It follows that all Elements "have" TypeMirrors, but not all TypeMirrors "have" Elements.)
Speaking loosely and intuitively, this makes sense: you declare types by chanting certain Java spells: the spells themselves are the (declared) elements; the things they bring into being are the types that back them. I've programmed in Java for decades and have a good working familiarity with oddities like Foo implements Comparable<Foo>. I'm trying to get more rigorous here.
With all that in mind, and considering the following snippet, how are the javax.lang.model types and elements manifested?
// (Defined by the JDK itself of course.)
public interface Comparable<T> ...
// (My class.)
public class Frob implements Comparable<Frob> ...
I see the following "things", working from "top" to "bottom" with less and less certainty as I go along:
a TypeParameterElement whose affiliated Name is equal to "T"
The return value of its asType() method will be a (definitionally nameless) TypeVariable whose asElement() method will return the TypeParameterElement currently being discussed.
The return value of its getGenericElement() method (and its getEnclosingElement() method) will be the Element we'll talk about next ("Comparable").
a TypeElement whose affiliated Name is equal to "Comparable"
The return value of its asType() method will be a (definitionally nameless) DeclaredType whose asElement() method will return the TypeElement currently being discussed
The DeclaredType so returned will have exactly one type argument which will be the (definitionally nameless) TypeVariable discussed above whose asElement() method will return the TypeParameterElement discussed above ("T")
The return value of its getTypeParameters() method will consist solely of the TypeParameterElement discussed earlier.
a TypeElement whose affiliated Name is equal to "Frob".
(This TypeElement is brought into being with the Java syntax public class Frob ....)
The return value of its asType() method will be a (definitionally nameless) DeclaredType whose asElement() method will return the TypeElement currently being discussed.
The return value of its getInterfaces() method will be discussed in a moment.
an Element of some variety loosely described by "Comparable<Frob>".
I say "of some variety" because as written it itself does not have, say, an explicit or implicit extends or implements clause, or other markers I would expect to see of, say, a TypeElement. Nevertheless I'm not sure that it could be any other kind of Element other than a TypeElement. Maybe it is a TypeElement equal to that denoted by "Comparable<T>", but with its various TypeMirror-returning or -referencing methods using the type denoted by Frob?
The return value of its asType() method will be a (definitionally nameless) TypeMirror of some variety (almost certainly a DeclaredType) whose asElement() method will return the Element currently being discussed (this corresponds somewhat to java.lang.reflect.ParameterizedType in the runtime/reflection model)
The TypeMirror so returned will have exactly one type argument which will be the (definitionally nameless) DeclaredType returned by the asType() method of the TypeElement whose Name is equal to "Frob" described above
The TypeMirror so returned will be the sole member of the return value of the getInterfaces() method when invoked on the TypeElement whose Name is equal to "Frob" described above
Do I have this right as far as it goes?
Your question seems well-reasoned, and I can't find anything specifically wrong with it to point out to you, but it is missing the one vital truth of where Elements and TypeMirrors differ.
Elements represent nodes in the Java type AST that reside "on disk" - the code at rest, either in .java or .class files. Any class/interface/enum/record/annotation that exists on disk in this form is in some way discoverable by this. To get a bit further, these cover the entire API of any of those types above - any members (fields/constructors/methods or nested types, then also the params of those methods/ctors) and packages too are described by elements. But the Element hierarchy only covers the types on disk - to use a concrete example from your question, Comparable<T> and its Comparable<T>.compareTo(T) member, and that method's parameter are covered in this way. And yes, lest I omit the type parameter, both the class and the method have a type param embedded in their respective element - as an element.
On the other hand, TypeMirrors represent those elements "in use" - you can't really reason about Comparable<T> in your code, but instead will either use it raw (please don't), or will parameterize it in some specific way (such as Comparable<Frob>, Comparable<?>, or possibly Comparable<T> where T is the type param of an enclosing element such as the current method or class). This means that T is not the same TypeElement as above - it isn't the value of the TypeElement that was on disk, but is something more specific.
You'll find TypeMirrors in Elements (for example "what is the return type of the method that appears in this class?"), and all Elements can be converted to some form of TypeMirror. On the other hand, not all TypeMirrors can be converted to some Element (such as a primitive), or if they can, that conversion may be "lossy" (for example converting a TypeMirror of List<String> to an Element would give you only List<T> itself).

Why do some Matlab class methods require "apparently" unnecessary output argument

After evolving my project code for months, I've finally hit a need to define a new class. Having to romp through my previous class definitions as a refresher of the conventions, I noticed that all constructors and property setters all have an output argument, even though nothing is assigned to it, e.g.:
function o = myConstructor( arg1, arg2, ... )
function o = set.SomeProperty( o, arg1 )
I've been looking through the documentation for upward of an hour without finding the explanation for this. It doesn't look like it depends on whether a function is defined in the class definition file or in its own separate m-file.
Can anyone please explain?
The best place to start is the documentation "Comparison of Handle and Value Classes". From the very top:
A value class constructor returns an object that is associated with the variable to which it is assigned. If you reassign this variable, MATLABĀ® creates an independent copy of the original object. If you pass this variable to a function to modify it, the function must return the modified object as an output argument.
A handle class constructor returns a handle object that is a reference to the object created. You can assign the handle object to multiple variables or pass it to functions without causing MATLAB to make a copy of the original object. A function that modifies a handle object passed as an input argument does not need to return the object.
In other words, value classes need to return a modified object (which is a new object distinct from the original), while handle classes don't. The constructor of either class will always have to return an object, since it is actually constructing it.
Some good additional reading is "Which Kind of Class to Use", which links to a couple helpful examples of each type of class object. Looking at the DocPolynom value class example, you can see that property set methods have to return the modified object, while the dlnode handle class example only requires an output for its constructor. Note that you could still return an object from a handle class method (if desired), but it's not required.

Scala how to get object property value given name of property in string?

I wondering how to get object property value given name of property in string in Scala? I saw examples when you get all fields of object using Reflection and iterate over it. But is it possible to call it without iteration? Or may be there is a way to pass object.field to another function without evaluation and evaluate it there and return result?
Kolmar comment give me right direction to call by name function.