NG Feature request: extension slot

BlitzMax Forums/Brucey's Modules/NG Feature request: extension slot

Yasha(Posted 2015) [#1]
Would it be possible to get an extra slot added to NG's BBClass, for (explicitly permitted) use as a general-purpose runtime extension data pointer?

The old BBClass had its famous reserved methods, which didn't do anything, and with the recently-added interfaces feature have finally been removed and replaced with something else. Upon looking at it, being able to add extra information to class descriptors (in the same way as NG does for itables) would be also fantastically useful for minor (loadable) language extensions or interop languages and experimental things like that, saving a lot of performance that would otherwise be lost to map lookups. Of course there's no unused space in BBClass any more...

So since there are no more unused words to overwrite (although that strategy will presumably continue to serve for the BRL compiler), would NG be willing to add-and-bless an "officially empty" slot - no need for three, can store a pointer to whatever is needed in just one - that can be dedicated to runtime-loadable class extension data, guaranteed not to be used by future expansion and left available for runtime code to write to?

i.e.:


I'm hoping it's still early enough in NG's lifecycle that there are no binary compatibility issues to be caused by such a change.


Brucey(Posted 2015) [#2]
That should be fine.
Implementation will just need some BRL headers and bcc updated.

Is that what you want to call it?


Yasha(Posted 2015) [#3]
Thank you!

The name seems like as good a one as any. Whatever doesn't conflict.


Brucey(Posted 2015) [#4]
Done :-)


Brucey(Posted 2015) [#5]
I've refactored things a bit, so we again have a "reserved" pointer in the class...
...
	BBObject*	(*SendMessage)( BBObject *m,BBObject *s );

	BBINTERFACETABLE itable;
	void*   extra;
	void*   reserved;

	void*	vfns[32];
...



Yasha(Posted 2015) [#6]
Interesting. This presumably keeps the layout the same in both NG and BRL...

Does that mean there's no feature macro for C code to identify NG? Ideally I'd rather have C work out the correct location using language-level information as far as possible, rather than have BlitzMax code fumble around with a magic-number pointer offset.


Brucey(Posted 2015) [#7]
Does that mean there's no feature macro for C code to identify NG?

Sure there is. You never asked 'til now : BMX_NG

In BlitzMax, you can use ?bmxng


Yasha(Posted 2015) [#8]
Good to know. Sorry, didn't mean to doubt you.

I'm just curious about the layout change - reusing the slots in the BRL version is driven by necessity, but in the layout shown in post #5 you're now splitting the vtable by overlaying other data onto the _reservedN_ methods (which are still declared present) - my instinct would have been to just remove them, and put all non-method-pointer data ahead of the start of the vtable. Compatibility issue..?


Brucey(Posted 2015) [#9]
I don't think it makes a huge difference - as far as NG is concerned - as they are all just pointers (function or otherwise), but I can see how you'd prefer non-function pointers be grouped nicely at the top.

Changing it doesn't affect NG at all, as everything is directly referenced, rather than by magic-number pointer offsets as per the legacy code.