Library migration: Is it possible to convert a component to a different class when the condition parameter is of type String? Trying something like
convertClassIf("OldClass",
"stringParameter",
"blue",
"NewClass");
fails. This shall trigger conversion of OldClass(stringParameter=\"blue\") into NewClass().
I'm using Dymola 2022x.
It looks like this does not work in Dymola 2022x.
According to Modelica Specification 3.5 it should be possible:
The old element should be of a Boolean, Integer, String, or enumeration type and the match is based
on the literal value of the modiļ¬er. For string elements the value argument to convertClassIf shall be
up-quoted, e.g. "\"My String\"" ...
So this should have worked (And maybe it will in future Dymola versions):
convertClassIf("OldClass",
"stringParameter",
"\"blue\"",
"NewClass");
But Dymola 2022x just marks classes as modified without changing anything.
Related
I'm working on a Function Module to assist with dealing with included text with logic embedded. While looking into the way SAP handles SAPScript files and parses the logic I found a structure that is declared as so:
DATA BEGIN OF events OCCURS 100.
INCLUDE STRUCTURE ITCCA.
DATA: command LIKE BOOLEAN,
template LIKE BOOLEAN,
mask LIKE BOOLEAN,
END OF events.
This obviously works, as I can trace through it while it is running a print program. So I thought I would try a similar structure in my own code but even when I copied the code 1 for 1 like above I get an error during activation. The error is
"BOOLEAN" must be a flat structure. Internal tables, references,
strings and structures are forbidden as components.
Can someone explain to me why this structure is valid in one program and not mine?
To explain the actual effect: LIKE usually refers to a data object (an actual variable) on the right-hand side, not a data type. As you rightly discovered, once you provide a data object named BOOLEAN, that is used to construct the type. If a data object of that name is not present and you're not within a class or an interface, an obsolete variant of the LIKE statement will be triggered that also takes data types into account, but only allows for certain elements on the right-hand side - namely only flat structured objects or their components. LIKE DATATYPE-BOOLEAN should have worked. As usual, the error message is somewhat less than helpful.
It seems during my initial investigation I missed a declaration for the BOOLEAN type. In the STXC function group SAP decided to declare their own variable for boolean in a different include file like this:
data: boolean(1) type c.
I had originally assumed that they were doing this with the dictionary defined type which has a similar name and is a 1 character long string. What I also found is that if I were to change my structure declaration like this:
DATA BEGIN OF events OCCURS 100.
INCLUDE STRUCTURE ITCCA.
DATA: command TYPE BOOLEAN,
template TYPE BOOLEAN,
mask TYPE BOOLEAN,
END OF events.
My code would be valid because it would then be using the dictionary defined value. So either I have to add a declaration for my own definition of boolean so that I can use the LIKE keyword or I have to use the TYPE keyword to use the dictionary definition.
Is it possible, in ABAP, to evaluate string templates dynamically?
Normally, you will have some string template in code that will be checked by the compiler. (The variables in the curly brackets are checked by the compiler at compile time).
However, is it possible to have a string evaluated at runtime?
So, instead of:
data(val) = |System ID: { sy-sysid }|.
I would like the string to be interpolated to come from elsewhere, for example:
parameter: p_file type string lower case default '/mnt/{ sy-sysid }/file.txt'.
In this case, I would like to have the value of p_file to be evaluated at runtime to substitute the variable (sy-sysid) with the runtime value.
You could, of course, program your own substitution by finding all occurrences of variables with curly brackets with a regex expression, then evaluate the variable values with ASSIGN and substitute them back into the string, but I am looking for a built-in way to do this.
Sorry, this is maybe a stupid example, but hopefully you understand what I mean. (If not, please let me know in the comments and I will try and clarify).
The problem in your snippet is not with string template but with PARAMETER behavior. It does not allow dynamics in DEFAULT clause.
To achieve what you want you should use INITIALIZATION and set path value in runtime:
parameter: p_file type string lower case.
INITIALIZATION.
p_file = | /mnt/{ sy-sysid }/file.txt |.
Unfortunately, the example you gave, does not make any sense to me. ABAP String templates are evaluated at run-time and type-checked at compile-time.
In your example, it is always the run-time value of SY-SYSID that will be written to the variable.
I guess what you want to do is circumvent compile-time checks for expressions inside a string template.
Please try to give us your actual use case, so maybe we find an even better solution to your problem.
However, here is what I think could help you:
Personally, I do not recommend to write code like the one below, because it is extremely error-prone likely to mislead other programmers and because there is very likely a better solution.
Given that you know the name of a variable at run-time, try this:
".. say LV_VARNAME is a charlike variable that contains a
" variable name at runtime.
"NOTE that the variable LV_VARNAME must be visible in the scope of the
"following code.
FIELD-SYMBOLS: <my_var> TYPE any.
ASSIGN (lv_varname) TO <my_var>.
DATA(lv_str) = |The value is { <my_var> }|.
I have a function that decorates a string. If the decorated string is again fed to the function, it is guaranteed not to change. How is the standard naming convention for such a function? I'll probably create a namespace because I need to have a few of those functions.
I've come up with:
repetition_safe.decorate(me);
fixpoint_gen.decorate(me);
one_time_effect.decorate(me);
but I don't really like any of these.
How would you name the namespace or function?
How about:
StringDecorator.MakeImmutable(input);
I think "MakeImmutable" is better than "Decorate" as the later is ambiguous i.e. a user reading the code won't know what "decorate" does, whereas "makeImmutable" will inform the user that this function will make the input string immutable/non-changable.
I'm learning D and have seen a lot of code like this:
ushort x = to!ushort(args[1]);
I assume this casts args[1] to ushort, but what's the difference between this and cast(ushort)?
EDIT: And what other uses does the exclamation mark operator have?
In D,
to!ushort(args[1])
is shorthand for the template instantiation
to!(ushort)(args[1])
and is similar to
to<ushort>(args[1])
in languages like C++/Java/C#.
The exclamation point is to note the fact that it's not a regular argument, but a template argument.
The notation does not use angle brackets because those are ridiculously difficult to parse correctly for a compiler (they make the grammar very context-sensitive), which makes it that much more difficult to implement a correct compiler. See here for more info.
The only other use I know about is just the unary 'not' operation (e.g. false == !true)... I can't think of any other uses at the moment.
Regarding the cast:
cast(ushort) is an unchecked cast, so it won't throw an exception if the value is out of range.
to!ushort() is a checked cast, so it throws an exception if the value is out of range.
The exclamation mark here is not an operator, it is just a token part of the explicit template instantiation syntax (described in detail here).
std.conv.to (docs) is a function template for converting between arbitrary types. It is implemented entirely in the library and has no special support in the language. It has a broader and different scope compared to the cast operator.
The to template takes two type parameters; a "to" type and a "from" type, in that order. In your example, the template is explicitly instantiated with the single type argument ushort for the "to" parameter, and a second type argument string (assuming args comes from the first parameter to main) is automatically inferred from the regular function argument passed to the function (args[1]) as the "from" parameter.
The resulting function takes a string parameter and returns a ushort parsed from that string, or throws an exception if it failed. The cast operator will not attempt this kind of high-level conversion.
Note that if there is more than one explicit template parameter, or that parameter has more than one token in it (ushort is a single keyword token), you must wrap the template parameter list in parentheses:
ushort result;
result = to!(typeof(result))(args[1]);
In this example, typeof, (, result and ) are four separate tokens and the parentheses are thus required.
To answer your last question, the ! token is also used for the unary not operator, unrelated to template instantiations:
bool yes = true;
bool no = !yes; // 'no' is false
You already got two excellent answers by jA_cOp and Merhdad. I just want answer directly to the OP question (what's the difference between this and cast(ushort)?) - The difference is that cast(ushort)args[1] will not work (you cannot cast from a string to an uint just like that), while the to!(type)(param) template knows what to do with the string and how to convert it to the primitive type.
I came across some sample code in VB.Net which I have some experience with and kinda having a duh moment figuring out the meaning of :=.
RefreshNavigationImages(bForward:=True, startIndex:=-1)
The sig for this method is RefreshNavigationImages(boolean, int). Is this a default value if null? Like "bIsSomething ?? false"?
Tried to bing/google but they just don't like searching for operators especially if it's only 2 chars.
They are named parameters. They let you specify values for arguments in function calls by name rather than order.
The := indicates the use of named parameters. Rather than relying on the order of the parameters in the method declaration, named parameters allow you to specify the correlation of parameters to values by specifying the name of the parameter.