Forum > Suggestions
Really VOID Class
damieiro:
In the class model of Free Pascal, derived from Delphi one, we have
TObject. -> https://wiki.lazarus.freepascal.org/TObject
And all derives from it.
I think it's desirable some kind of lightweight class without all the bloat like a
TVoidClass and TObject should derive from the TVoidClass.
TVoidClass shoud be really void (not constructor, destructor, anything), or by default a minimal set.
Even things could have more steps
TVoidClass (a really void one) -> THeapClass (with default constructor and destructor on heap) -> Tobject
This would give full delphi/Embarcadero compliance and could be the way to have a full control on the class.
Embedded systems will make use of these instead of not developed stack object model and when some improvements were doing on the classes, it will be of use for void ones...
*TVoidClass,THeapClass are example names... not the coolest ones :D
marcov:
Moreover what they are exactly good for is unclear too.
damieiro:
Well, i think is good for some reasons:
1.- Less memory use. A void class has minimal memory footprint.
2.- Less side-effects. For example if you don't define an AfterConstruction it will not be called as TObject does. If not a create constructor defined, it cannot be invoked for a descendant class, etc..
3.- Not the main idea of this, but if the model evolves, a void class could help to derive on how to make the memory allocation, and being a stack or heap or other method of allocation being a pure implementation of their descendant classes. For example a Vector class or Sprite class, could use a GPU memory model.
4.- For actually implementation, a TObject would be a descendant from a void.
5.- Are we really using all the data of TObject in our code? I think not.
6.- Could help C++ portability and viceversa. C++uses a "semivoid" . Even a TCpp class could descend from a Void one.
7.- I think on a void class as a tool, not as a trouble ;)
I think in a lot of posibilites, but all are derived from a basic void class..
Awkward:
maybe easier to use standard 'object' type then?
damieiro:
Object would be ok, but It's not valid idea, because.
1.- Object is a stack type one, not heap. (can be heap, but without sugar sintax)
2.- Object is deprecated in delphi and only maintained in fpc, no further development
3.- Object doesn't accept all the syntax and has no sugar-syntax implemented.
The dual model Object/class i think it's a bad idea. And heap classes has it's own advantages.
Even with object, it should be a void Class for completness (and the explained advantages)
Navigation
[0] Message Index
[#] Next page