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.
Related
I am trying to assign the value of this stucture path to a fieldsymbol, but this path does not work because it has a table in it's path.
But with in the debugger this value of this path is shown correctly.
Is there a way to dynamically assign a component of a table line to a fieldsymbol, by passing one path?
If not then I will just read the table line and then use the path to get the wanted value.
ls_struct (Struct)
- SUPPLYCHAINTRADETRANSACTION (Struct)
- INCL_SUPP_CHAIN_ITEM (Table)
- ASSOCIATEDDOCUMENTLINEDOCUMENT (Element)
i_component_path = |IG_DDIC-SUPPLYCHAINTRADETRANSACTION-INCL_SUPP_CHAIN_ITEM[1]-ASSOCIATEDDOCUMENTLINEDOCUMENT|.
ASSIGN (i_component_path) TO FIELD-SYMBOL(<lg_value>).
IF <lg_value> IS NOT ASSIGNED.
return.
ENDIF.
<lg_value> won't be assigned
Solution by Sandra Rossi
The debugger has its own syntax and own logic, it doesn't apply the ASSIGN algorithm at all. With ABAP source code, you have to use ASSIGN twice, the first one to reach the internal table, then you select the first line, and the second one to reach the component of the line.
The debugger works completely differently, the debugger code works only in debug mode, you can't call the code from the debugger (i.e. if you call it, the kernel code used by the debugger will fail). No, there's no "abappath". There are the XSL transformation objects (xpath), but it's slow for what you ask.
Thank you very much
This seems to be a rather unexpected limitation of the ASSIGN statement. Probably worth a ticket to SAP's ABAP language group to clarify whether it's even a bug.
While this works:
ASSIGN data-some_table[ 1 ]-some_field TO FIELD-SYMBOL(<lv_source>).
the same expressed as a string doesn't:
ASSIGN (`data-some_table[ 1 ]-some_field`) TO FIELD-SYMBOL(<lv_source>).
Alternative 1 for (name) of the ABAP keyword documentation for the ASSIGN statement says that "[t]he name in name is structured in the same way as if specified directly".
However, this declaration is immediately followed by "the content of name must be the name of a data object which may contain offsets and lengths, structure component selectors, and component selectors for assigning structured data objects and attributes in classes or objects", a list that does not include the table expressions we would need here.
I'm using reflection to serialize an object. Getting the values as objects is a real murder on performance due to late binding penalties. CType / DirectCast can get rid of most of it but I can't feed a type variable into it so currently I'm using a switch case block on the type variable to select the correct DirectCast.
It came to my attention that CTypeDynamic exists and takes type variables but the return type is Object so... it converts an object into an object, cool. That got me wondering, what is the purpose of this function?
The CTypeDynamic function looks for dynamic information and performs the cast/conversion appropriately. This is different from the CType operator which looks for static information at compile time or relies on the types being IConvertible.
This function examines the object at runtime including looking for Shared (aka static) custom operators. As always, if you know the type then use CType, but if you need dynamic casting then you need to use CTypeDynamic.
More information here: http://blogs.msmvps.com/bill/2010/01/24/ctypedynamic/
Is it possible to create variables to be a specific type in Lua?
E.g. int x = 4
If this is not possible, is there at least some way to have a fake "type" shown before the variable so that anyone reading the code will know what type the variable is supposed to be?
E.g. function addInt(int x=4, int y=5), but x/y could still be any type of variable? I find it much easier to type the variable's type before it rather than putting a comment at above the function to let any readers know what type of variable it is supposed to be.
The sole reason I'm asking isn't to limit the variable to a specific data type, but simply to have the ability to put a data type before the variable, whether it does anything or not, to let the reader know what type of variable that it is supposed to be without getting an error.
You can do this using comments:
local x = 4 -- int
function addInt(x --[[int]],
y --[[int]] )
You can make the syntax a = int(5) from your other comment work using the following:
function int(a) return a end
function string(a) return a end
function dictionary(a) return a end
a = int(5)
b = string "hello, world!"
c = dictionary({foo = "hey"})
Still, this doesn't really offer any benefits over a comment.
The only way I can think of to do this, would be by creating a custom type in C.
Lua Integer type
No. But I understand your goal is to improve understanding when reading and writing functions calls.
Stating the expected data type of parameters adds only a little in terms of giving a specification for the function. Also, some function parameters are polymorphic, accepting a specific value, or a function or table from which to obtain the value for a context in which the function operates. See string.gsub, for example.
When reading a function call, the only thing known at the call site is the name of the variable or field whose value is being invoked as a function (sometimes read as the "name" of the function) and the expressions being passed as actual parameters. It is sometimes helpful to refactor parameter expressions into named local variables to add to the readability.
When writing a function call, the name of the function is key. The names of the formal parameters are also helpful. But still, names (like types) do not comprise much of a specification. The most help comes from embedded structured documentation used in conjunction with an IDE that infers the context of a name and performs content assistance and presentations of available documentation.
luadoc is one such a system of documentation. You can write luadoc for function you declare.
Eclipse Koneki LDT is one such an IDE. Due to the dynamic nature of Lua, it is a difficult problem so LDT is not always as helpful as one would like. (To be clear, LDT does not use luadoc; It evolved its own embedded documentation system.)
I am investigating types in VB especially in VBA. Generally, given an entity there are two types: Effective value type, I guess, is defined as value types in this part of the specification; Declared Type is defined in this part of the specification.
To do tests, I need to use some functions to check types. There are TypeName and VarType. I think they are used to check effective value type of an entity, because TypeName can return DBNull, Decimal and Nothing; VarType can return vbNull, vbEmpty, vbError and vbDecimal. These types exist in the table of effective value types, but not in the table of declared type.
So now, my question is, does anyone know how to check/display the declared type of an entity (variable, expression...)?
Edit 1: Probably for a variable, its declared type is just the type that the declaration of the variable specifies. I would like to insist that, it seems that VBA has declared type for expressions. For instance, Operator Declared Type is mentioned in this link. I think that refers to the declared type of the result of an operation. That means such entities as -i, i+5, i>6... can have a declared type. I would like to know how to display their declared type.
If,
Dim i as integer
i = 6/3
then you do, TypeName(i>3)
it returns Boolean which is the expression's Type based on the Type of the resulting value it holds not operand's declare type. And it complies with the specification given in your link for msdn 2.2 Entities and Declared Types.
Or else are you looking for a syntax/function (e.g. DType, imaginative function) that could return DType(i>3) as integer which is operand's (i) Type? Or rather it's more useful when you have multiple variables within some expression, so you can find all their Types in one go?
e.g. some String that combined all sorts of different TYPE variables in one expressoin.
Just trying to understand when and how this can be useful to you and what could be the end result you are looking for.. Seems like this is more to lanague root definitions.
PS: I do not have reps points to comment. So I added as an answer.
I'm currently working on my first major project in clojure and have run into a question regarding coding style and the most "clojure-esque" way of doing something. Basically I have a function I'm writing which takes in a data structure and a template that the function will try to massage the data structure into. The template structure will look something like this:
{
:key1 (:string (:opt :param))
:key2 (:int (:opt :param))
:key3 (:obj (:tpl :template-structure))
:key4 (:list (:tpl :template-structure))
}
Each key is an atom that will be searched for in the given data structure, and it's value will be attempted to be matched to the type given in the template structure. So it would look for :key1 and check that it's a string, for instance. The return value would be a map that has :key1 pointing to the value from the given data structure (the function could potentially change the value depending on the options given).
In the case of :obj it takes in another template structure, and recursively calls itself on that value and the template structure, and places the result from that in the return. However, if there's an error I want that error returned directly.
Similarly for lists I want it to basically do a map of the function again, except in the case of an error which I want returned directly.
My question is what is the best way to handle these errors? Some simple exception handling would be the easiest way, but I feel that it's not the most functional way. I could try and babysit the errors all the way up the chain with tons of if statements, but that also doesn't seem very sporting. Is there something simple I'm missing or is this just an ugly problem?
You might be interested in schematic, which does pretty similar stuff. You can see how it's used in the tests, and the implementation.
Basically I defined an error function, which returns nil for correctly-formatted data, or a string describing the error. Doing it with exceptions instead would make the plumbing easier, but would make it harder to get the detailed error messages like "[person: [first_name: expected string, got integer]]".