Forum > Suggestions
Really VOID Class
marcov:
I think that advanced records are chiefly due to generics.
The specialize syntax
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- xx = {specialize } yy<zz>;
doesn't really allow to specify operators and other methods that operate on zz.
Solution to avoid having to navigate all available scopes to find them: bundle them nearly up with the record type.
Martin_fr:
From what I understand the OT wants something like this:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---type TVoid = class {empty} end; TObject = class(TVoid) constructor create; procedure NewInstance; special internal new-instance; procedure AfterConstruction; special internal after-construction;... end;
So TVoid would be a pointer (like any object) to the instance-mem. The instance-mem would have a pointer to the VMT, but the VMT would be 0 bytes.
Technically, even the PVMT could be skipped, and the instance-mem starts at 0 bytes.
That does open a can of worms..... (the likes of which Pandora would gladly have exchanged her gift against).
For starters, the PVMT must have the typeinfo pointer (rtti). That is required for allowing any managed types inside the class.
Sure of course in theory that can be done conditionally. Except then you need some flag that distinguishes a VMT with RTTI from one without....
And the compiler needs to add checks for that flag. Or it needs to add extra duplicated code depending on the type used.... (calls to Initialize for managed fields).
I am not an expert on this. Maybe other options could be found. But it would be a pretty massive and complex undertaking....
Similar for any introduction of "special internal" (all the magic that comes with current classes) the compiler would probably end up adding extra code (compared with today).
So unless someone wants to write half the compiler from scratch....
There are a couple of things were I think it would be nice if they could be controlled away.
They do affect classes, but are not limited too. Mainly RTTI.
Through RTTI classes (and afaik enums/sets) include the unitname into the exe. For Classes its also the class name, and for some other types the typename too.
It's not about the exe size (well there is some deep down instinct from 4 or 5 decades ago, when the byte was still a valuable resource), it's more about privacy/security.
If you have a package with useful classes. One of them sits in a unit, that is called "IllegalMovieDatabase" or "SpyOnGlobalKeyboardHook", but the class can of course be used for other stuff, then you may get some strange feedback if you sell your app to some big company (or even government department), and they find that string in your app.
MarkMLl:
--- Quote from: Martin_fr on September 25, 2021, 05:57:51 pm ---So TVoid would be a pointer (like any object) to the instance-mem. The instance-mem would have a pointer to the VMT, but the VMT would be 0 bytes.
--- End quote ---
Hypothetically: would a TVoid require the capability of virtual methods, or could that be added in its descendants, i.e. TObject et al.?
Object Pascal does a sterling job of providing a robust underpinning to the sort of facility that used to be hardcoded into the typical "4GL". But with types fragmented into classes, objects, strings, dynamic arrays and so on I think it could be argued that anything that provided a common foundation would be a useful abstraction. If TVoid is a zero-length entity from which others might be derived, the suggestion might have some merit.
--- Quote ---Sure of course in theory that can be done conditionally. Except then you need some flag that distinguishes a VMT with RTTI from one without....
--- End quote ---
The "Smalltalk way" would be to move pointers out of alignment by ORing-in one or more low bits on a byte-addressed architecture. In fact I believe that x86 has for some while had a facility (i.e. a bit in one of the configuration registers) to recognise this specific case and react sensibly. ** "Just sayin'" :-)
** I don't, however, know whether this sort of thing can be manipulated at the per-process level. My understanding is that there are a number of things in the architecture which have been added to keep "mainframe" manufacturers like Unisys and SGI happy, and which are likely to be unused by anybody else and possibly redundant from the POV of the original sponsor who has moved on to a different architecture and support chipset.
MarkMLl
Martin_fr:
--- Quote from: MarkMLl on September 25, 2021, 10:26:10 pm ---
--- Quote from: Martin_fr on September 25, 2021, 05:57:51 pm ---So TVoid would be a pointer (like any object) to the instance-mem. The instance-mem would have a pointer to the VMT, but the VMT would be 0 bytes.
--- End quote ---
Hypothetically: would a TVoid require the capability of virtual methods, or could that be added in its descendants, i.e. TObject et al.?
--- End quote ---
It could be addressed per "type" but not per "descendant", as that would create incompatible types. (And of those we have enough)
That is, as soon as a class (or subclass (aka always)) introduces the need for a vmt, it can no longer be stored in anything that does not have that space for the PVMT.
So if TVoid should be a real base class, then it needs to have a PVMT.
And the PVMT points to more than just the virtual methods (for classes, different with old style objects).
The PVmt has pointers for
- the RTTI too(for manage types, even if only in some descendant),
- the parent class type (for is operator).
- other stuff (not reviewed)
The PVMT, could have zero methods in it. But must exist.
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---// TMyObject > TObject > TMyVoid > TVoidvar Foo: TVoid;begin Foo := TMyObject.create; if Foo is TMyVoid then ; // works only via PVmt for TVoid (ref to base class) Foo.Free; // If TMyObject has managed types their memory will leak, unless RTTI (e.g. via PVmt) exists in TVoid.end;
Old style objects have a different vmt, therefore this is not comparable.
And also you can not store a TMyOldChildType in a variable that is TMyOldParentType. (you can have pointers of those types work like that).
But "Dispose( PMyOldParentType(ptr) );" would leak managed types introduced in TMyOldChildType (not tested, but pretty sure)
"AfterConstruction" and "NewInstance" are virtual methods. They could be introduced by a descendent.
Though for "NewInstance" it really makes no sense at all to drop it (from declaration). What would be the gain?
- 1 pointer (2 bytes on some embedded, 4 or 8 otherwise) per class (not instance)
On embedded, how many classes will you have? Say 50, then its 100 to 200 bytes. If unlucky some of it may be eaten by new code that gets generated, as instances still need memory.
- 1 indirect call converted to direct call.
Yet the latter (indirect call) can be removed by WPO (de-virtualization). So no need to alter the type definitions. (not sure if current WPO would do it)
Technically the first (saving the pointer) could also be done by WPO. Once it is entirely de-virtualized, it could be scratched from the VMT. => Only currently that part of the VMT is hardcoded, and can not be altered. Yet making it modify-able is less a task, than any adding (even part of) TVoid.
In the same way, unused methods (access to unit name, access to class name) could be reduced (by WPO), and (again currently hardcoded, not modify-able) the RTTI could shrink. (Again not trivial, but in theory...)
Navigation
[0] Message Index
[*] Previous page