Introspection Questions: structures & Enums

General
1

If a class property is a Structure, is there any way to get information about the structure?

If I can’t get the members, can I at least get the Size in bytes for the structure?

Thanks,
-Karen

2

A more basic question… is there a direct way to tell a property IS a structure at all? Introspection.ProperType has no isStructure property…

The only was I can see that MIGHT work is

DIM IsStructure  As boolean =  thePropertyType.IsValueType and NOT thePropertyType.isEnum AND thePropertyType.FullName.Instr(".") > 0

Since a structure has to be defined either on a class or a module the Fullname should always have a “.”… is there any other way that can be true for a different value type?

-Karen

3

Looking the the docs more closely I think I see there is a better way to find out if it is a structure:

DIM IsStructure As boolean = thePropertyType.IsValueType and NOT thePropertyType.isPrimative AND NOT thePropertyType.isEnum

Are there any issues with that? If not is there a way to get the size in bytes?

4

Another question this time on Enums…

There is a propertyInfo.IsEnum, but there is there a way to determine the datatype for the enum?

An Enum can be specified to be any integer type: Int8, Uint8, int16, Uint16, Int32 Uint32, int64, Uint64, integer
Thanks
karen

5

BTW the IDE is rather Schizophrenic about Enum Datatype… It seem to think Enums should always be defined as integer.

You an type in any legal integer type in teh definition, in but if you type Uint8 and hit return the entry is partially deleted back to just “U”…For it to stick you have to first click on the Enum name

If you manage to have an enum defined as a Uint8 and then cut (or copy) and paste it somewhere it change step type to Integer.

This is 2019R1.1 but it has been that way a long time, I did not see any release notes saying that was fixed, dose i bet it is still that way in R3.

I just got used to fixing the type when I need to.

-Karen

6

To answer one of my own questions, yes there is a way to get the structure size via introspection:

Dim theSize as integer = PropertyInfo.Value(theClassInstance).StringValue.LenB

So if my way of determining if a property is a structure is reliable, while we should be able to get at the structure elements too, my immediate needs for structure property information via introspection have been met…

Still need a way to get teh datatype of an enum… Any ideas?

For Enums HaveElementType should be true and we should be able to call GetElementType to get that information…
however I think this is another casualty of enums originally only being thought of as type Integer , even though we can define specific integer types.

That thinking was built into the IDE and still has not been totally rooted out there!

  • karen
7

enums basically turn into integer literals when compiled
there’s almost no runtime overhead to them because of this - and why they basically are just integers

8

what not using a class instead of a structure, you could add methods to the class if needed.

9

[quote=467836:@Norman Palardy]enums basically turn into integer literals when compiled
there’s almost no runtime overhead to them because of this - and why they basically are just integers[/quote]

I’m confused…

They do have a specific integer type don’t they?

Are you saying that the integer type we enter into the definition does nothing? If so why can we specify the type?

10

I’m writing some general purpose code and classes can have structure properties… And for somethings I do find structure properties more convenient.

  • karen
11

ok, it always depends how you use it.

12

They do

Because you always have been able to - it pretty much doesnt matter because you cant use an enum like a bit mask etc so its not really material if you say its a Uint8 or Unit16 etc - its just a typed ranged value that is based on an integer

The way enums are handled in the compiler you could write an enum

   enum MyEnumName
        firstValue
        secondValue
    end enum

and use it like

    dim someProperty as MyEnumName = MyEnumName(0) // or myEnumName.firstValue

All the checking that is needed to make sure you’re using the type defined by the Enum correctly is done at compile time NOT runtime

13

Pretty much is not never…

But because Enums CAN be converted to integers they can also be used as general purpose named group of integers of a specific type …

And for some uses (What I am doing right now for one which can’t know the specific enum use at compile time) the size range can matter for writing optimal generic code in some situations.

That is why want to be able to get the specific type through introspection. It would be much better if I did not have to assume all enums are Int64.

14

the only code that needs to know if it is a uint8 etc is code that converts TO a specific integer type
and if thats what you’re doing then you probably do NOT want an enum

15

[quote=468015:@Norman Palardy]the only code that needs to know if it is a uint8 etc is code that converts TO a specific integer type
and if thats what you’re doing then you probably do NOT want an enum[/quote]

As i said usually, but not always!

I am writing a generic binary serialization method for a bunch of records (be they from a recordSet, An array of class instances or each record entered individually in code) sent as a batch, and I am trying to keep the size of the data sent as small as possible in bytes… So it can not know up front the enum size or it’s specific usage when it is a property of a class.

So while the enum, as an enum would be used in code as you would expect, when it is being serialized I want to use as few bytes as possible… the difference between 1 byte and 8 byte for each such field can add up if one has a large number of records and several such fields.

  • Karen
16

I suspect how you serialize and deserialize (the actual code) will have far more impact on things than 1 byte vs 8 bytes will

17

I am making the representation as compact as I can… in any case, as enums do have a specific integer type, that information should be available via introspection.

  • Karen
18

there’s lots of info that isnt accessible via introspection
cant get event lists from classes (implemented or available) etc because, as part of compiling, that info is stripped
enums are like that

19

I keep running into Xojo limitation because features are either not made logically complete or not updated when new capabilities are added…

In this case the last bit of information I wanted is the integer type of an Enum … the possibilities are 10 possibilities:
Int8, Uint8 Int16, UInt16 Int32, UInt32 Int64, UInt64 Integer,UInteger

If I understood what he said, according to Norm the Enum definition itself is stripped during compilation and the the value treated as it it was just an integer of teh type teh enums is defined as no introspection can’t give more info on teh enum…

But thinking about that, it means:

  1. since introspection know the property is an enum, and the value retrieved should be of the type the enum was defined as , the complier must know what type is and so it should be getable (though Integer and UInteger would be lost as their specific bit size datatype so what the compiler would know)…

  2. I can get a sample enum integer value as a variant via PropertyInfo.value, and variants know their underlying datatype… A viable workaround I momentarily thought!

But alas here is where Xojo not being a-n-a-l (in this usage that is not a swear word!) about things foils me yet again!

VarType only knows 2 integer types, not the 8 (or 6 spending on how you look at it) that the language supports.

So a VarType report of Int32 can be any one of these in actuality: Int8, Uint8 Int16, UInt16 Int32, UInt32

And a reported VarType of Int64 can be either Uint64 or Int64

And what sense does that make?

If the argument is that that the bit patterns for Int8, Uint8 Int16, UInt16 Int32, UInt32 all fit into int32, then why not just have VariType only report Int64 for all integers?

But why treat integer that way at all. After all, from teh beginning varitype knew the difference between singles and doubles and all singles will fit into doubles!

The reason is likely historical and not logical… When variants and varitype came into existence Xojo did not have all those integer datatypes…

And when they were introduced, instead of fully supporting them, it looks like they did a quick and dirty patch by adding a single varitype for Int64 INSTEAD of fully supporting all the integer datatypes individually … which is what the most robust , logical and intuitive thing for the long run would have been.

This is type of thing that I find most annoying about Xojo as a language… lack of logical follow through/incomplete implementation.

In this case ,at least I can tell if I can get by with 32 bit integers or if need or 64 bit values… but i SHOULD be able to do better.

-Karen