Re: Updates on Eu 4.2.0
- Posted by acEduardo Feb 02, 2022
- 1532 views
As I understand it, RAII is only concerned with stack-allocated objects that are holding heap-allocated resources, and ensuring those heap-allocated resources get released when the stack-allocated object goes out of scope. (Please correct me if I'm wrong.)
I will have to disagree. RAII is a lifecycle management system for all objects in program memory. RAII uses stack context destruction discipline to call destructors for all objects, whether they are allocated in the stack or in the heap.
Since Euphoria operates with value semantics, RAII would be perfect for eliminating the garbage collector.
We could replace the allocation in heap arenas (managed by the garbage collector), with a region allocation system. Each region would be tied to the stack frame of the function that created it, and all objects created in that stack frame would be allocated to the region. Objects that escape function termination via return would be moved to the region of the stack frame above (move-semantics), and objects that are referenced at a sequence should be copied to the region of the sequence (copy-semantics). Coroutines would have their region allocated by the scheduler, so yields would not destroy the objects in use.
So Euphoria could deallocate the regions with a unique free() call when the stack frame is destroyed, and we can add a syntax for object destructors. Copy-on-write would still work the same, but each object pointer would have to carry with it a pointer to the region where it was created.
I believe that object destructors without a object system is incomplete, and object systems are very useful, so we could add a native object/class system for Euphoria.
I envision a object system that is a little different from what most mainstream OO languages have: It would have interfaces, abstract classes (partially implemented interfaces), concrete classes without class inheritance (new classes could only subtype existing classes by adding new constructors, i.e. a simple adapter/decorator system), properties and signals just like Qt MOC has.
So skip implementing memstruct and move straight to classes?
No, I believe that these two features are complementary to each other. Memstructs would become more powerful with classes, and classes could hide implementation details involving memstructs.
Yes, I dream of completely replacing my C/C++ code to use Euphoria in all my projects!
