Typing field-symbols with ANY or DATA - abap

I'm currently learning ABAP and wanted to know what is the difference between the following ways of defining a field symbol?
Method 1
FIELD-SYMBOLS <fs> TYPE data.
Method 2
FIELD-SYMBOLS <fs> TYPE any.
I understand that both are typed generically and that the data type will be assigned at runtime. What I don't understand is how the two are different (or if they are at all).

Yes TYPE ANY and TYPE DATA are exactly the same. Excerpt from ABAP documentation, Generic ABAP types :
The generic type any can, like all generic types listed here except
data and object, only be specified directly after TYPE and has exactly
the same effect there as the generic type data. After TYPE REF TO,
only data (for fully generic data reference variables) and object (for
fully generic object reference variables) can be specified. Specifying
REF TO any would define a fully generic reference variable covering
data references and object references. This is not currently possible.

Related

DDS IDL | Creating a network alias name separate from a structure name

I've had a constraint imposed on me that my C structure names can't be published via DDS and that I instead have to use a different set of names and then somehow associate the two. It begs the question why not just change my C structure to match the actual DDS names but it is impractical since the names have to be configurable at run time.
Discarding the run-time constraint, I am wondering if there is an IDL keyword that I can use to create an alias between my structures and the desired DDS published names. There is an "alias" keyword but it is for data types.
I did a lot of google searching and had a hard time finding a definition for IDL keywords. The OMG document doesn't provide any insight to indicate this is possible (perhaps it's not).
In DDS, data types are registered with the middleware via a 'register_type()' operation. This operation includes a parameter to specify the 'name' to associate with the registered type. This name is not required to match the name of the IDL type. [If this name is not specified, then the middleware will use the IDL type name.]

Is it possible to create a generic type in Oracle, one that is suitable to many data domains?

Is there a way to create a generic type in Oracle which accepts data from different domains (as numbers and texts)?
OR
Is there a way to create a VARRAY of REF, being the REF a reference to different types of objects.
Something like this:
CREATE OR REPLACE TYPE LIST_REFS AS VARRAY(10) OF REF
Is it possible?
Yes, Oracle has an ANYDATA type which is intended for use as a generic type to hold data of different types. It's a little awkward to use.

How do you handle the values of the symbols in the symbol table?

In reference to chapter 6 of your book "Language Implementation Patterns"; what is the best practice/pattern for storing and retrieving values for each symbol.
Every symbol has a name, a type and a scope. However; where do you store the actual value?
I.e. symbol "n" of type "integer" has a value of 42.
What the symbol contains and how it contains that information is entirely your choice. In an untyped language the symbol could be just an object with term name and value attributes. For typing, add type and kind attributes.
Or the symbol object could contain just name and reference attributes, where the ref points into a separate table that contains additional attributes, including a reference that might point into a heap, immutables pool, or stack that actually stores the literal value.
This answer provides an example of a scoped, name and value symbol table.

Tables using LIKE may only reference flat structures

I wanna have a table parameter in a RFC function module of type CGPL_TEXT1, which uses the domain type TEXT40, which is a char 40.
I tried to create it:
IT_PARTS_DESCRIPTION LIKE CGPL_TEXT1
But I keep getting this error
tables using like may only reference flat structures
I am also not able to use TYPE. If I do so, I get this error:
Flat types may only be referenced using LIKE for table parameters
Don't go there. For RFC-enabled function modules, always use a structure as a line type for your table. The RFC protocol itself also supports unstructured tables, but many adapters don't. So you should
declare a data dictionary structure Z_MY_PARTS_DATA with a single field DESCRIPTION TYPE CGPL_TEXT2
declare a data dictionary table type Z_MY_PARTS_TABLE using this structure
use that table type in your function module.
Look inside the dictionary for a table type which has only one column representing Your Text.
If You cannot find it, just go the proper way and define a z structure and a z tabletype based on that structure. This is the proper way and I also prefer to use this ( even sometimes, when I would not really need it, i do this ).... because the structures sand table types can be documented.

Naming conventions for the same variable as a different type?

Many people believe Hungarian notation is bad. How then do you name a variables that represent the same value casted to different types?
I've got a variable called value, that might be a string, or a decimal. What would you call the different formats? strValue, decValue? valueAsString?
I think it would largely depend on the context. For instance if the string value was named age, and the decimal was the parsed value then perhaps parsedAge or something along those lines. Really it comes down to what makes sense given what you are doing and the lifetime of that variable. If it only exists long enough to actually collect and parse the value, then I would give the better name to the parsed variable or worry less about the naming of the intermediary.
If you actually need to hold on to both values, then I might consider creating a struct or some similar data structure that represents the various forms for that data value to prevents the need to shift between string and decimal formats etc.