New instance system?

Reporter: fundies  |  Status: closed  |  Last Modified: October 22, 2017, 02:27:27 PM

I'm goin through compiler sources and a new instance system is mentioned a few times in particular relating to extensions but what is the new instance system and how should it differ from the current one?
JoshDreamland  
I'm not sure if it's referring to the "new instance system" that I already implemented, or the changes to the instance system that I had planned. The extension one sounds like one of my plans, which is just keeping another list of instances by extension class (in the way that we have a list of obj_0 instances; we'd also have a list of my_extension_class instances).

The other big plan I had for the new instance system was to encapsulate all those list globals (including the self object global, used by, eg, with) in a class, which would be instantiated on a per-thread basis. That would give us a much higher degree of thread safety, and allow users to create threads to run scripts (they can already do this, but it will cause crashes if they interact heavily with the instance system in any thread).

fundies  

https://github.com/enigma-dev/enigma-dev/blob/master/CompilerSource/compiler/components/write_object_data.cpp#L87

I'm intrested in this obsurd cast method here which is again casted here

https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Universal_System/Extensions/Paths/path_functions.cpp#L64

surely theres a better way to do this....

JoshDreamland  

The only other way to do that is to rebuild all the extensions any time the set of selected extensions changes. Or, as I said above, to maintain a list of properly-cast pointers so the extension can just iterate that list.

Alternatively, path_start can just be a member of the class being cast to, and GCC will handle the correct cast of the this variable. ENIGMA's compiler doesn't currently support that, though.

In fact, perhaps what I was alluding to in whatever material you read was my intention to eventually make all the methods that operate on locals be members of the class containing those locals.

fundies  

What do you mean by pointers to the extensions? pointers to the paths resources? also where would this list go
JoshDreamland  

Some extensions (including paths) add local variables to all objects. They do this by declaring a class that contains those local variables, then specifying in their configuration file that object_locals should inherit from this class. Without knowing what object_locals is, though, it's impossible to cast from it to the correct extension class (the compiler implements this behind the scenes as a simple pointer addition, but you still need the offset).

The list would go with the object-specific instance lists. We'd have a series of object-specific instance lists, followed by a series of extension-specific instance lists.

Please sign in to post comments, or you can view this issue on GitHub.