Type improvements

[fmagin]

Extracted from #4

[justfoxing]

typeName is only a Jython thing, this won't work for other environments

[justfoxing]

As mentioned, only true for Jython. I think it might make more sense for your usecase to explicitly query for the typeName object in your code, instead of embedding it here.

[justfoxing]

Why add _name, what do you get that's different from _type?

[fmagin]

For a Class like ghidra.GhidraApplicationLayout _type will be something like JavaClass and __name__ is GhidraApplicationLayout. But I need the ghidra.GhidraApplicationLayout which is in .typeName for a Class object

[fmagin]

Ok, seems like this doesn't work as I thought overall.

What would solve my problem is maybe some way to register functions for attributes that retrieve the attribute on object creation so I don't have to waste bridge traversals when I expect that I will need this for many objects/classes anyway and it is just a string.

Batch Get somewhat alleviates this, but I think the cost of adding a few strings for every object creation is basically zero, while having to traverse the bridge later (even for a batch call) is around 10-20ms of latency. I think if it is really just one batch call per object introspection it is acceptable, but this would also require that accessing __class__ is properly faked by the bridge (it currently isn't but I am also looking into that). Otherwise it is already 10ms to get __class__, then 10ms to get typeName. This tends to quickly add up into noticeable latency, especially if it is fore autocompletion that times out after ~300ms. I will play around with my code some more and keep the feedback from this in mind, and see what would be other good approaches. I think Jython environments will require some extra tricks on the server side to handle properly, but I am not yet sure how to accommodate that without overcomplicating the code.