> On 5 Nov 2025, at 11:05, Josep Maria Blasco <[email protected]>
> wrote:
>
> I can see two different topics here:
> Clearly differentiating between object creation and object initialization.
> Making all objects adhere to the "NEW passes all arguments to INI" idea.
> As far as I can see, item 2 can be readily fixed, but we'd run into the risk
> of breaking existing programs For example, TUTOR has been written against
> this anomaly, and would require some changes.
I agree with the risk of regression
Out of curiousity, can you show an example of impact on TUTOR?
>
> We could also opt for leaving things as they are, but then it would be
> imperative to document and explain the anomaly.
+1
>
> Regarding item 1, it would be nice if we could add a new section to rexxref
> (maybe 4.2.8) called "Creation", or "Object creation". It would document the
> whole process of giving birth to an object as composed of two phases,
> creation and initialization. And it should explain that, in some cases, it
> can be necessary (or more convenient) to process the arguments in NEW, and,
> in other cases, in INIT.
+1
That could be illustrated by the Array class versus the Queue class.
Array's NEW checks the arguments and allocate the requested storage.
Then the INIT message is sent with no argument.
Queue is a subclass of Array, so in theory, should follow the same protocol as
Array.
But a design decision has been taken to let pass the NEW arguments to INIT.
QueueClass::initRexx
// It would be nice to do this expansion in the new method, but it sort
// of messes up subclasses (e.g. CircularQueue) if we steal the first new
// argument. We will set the capacity here, even if it means an immediate
expansion
Some native classes respect the protocol "NEW sends the INIT message with all
the received arguments):
Bag, Directory, EventSemaphore, IdentityTable, List, MutexSemaphore,
Object, Queue, Relation, Set, StringTable, Supplier, Table.
Some native classes proceed differently:
- Class, Method, MutableBuffer, Package, Routine, Stem, String and
WeakReference
remove the arguments they use, and pass the rest to INIT
(well, there are special cases where it's not true)
- Array send the INIT message but doesn't pass the arguments
>
> Finally, we should stress on the fact that calling the INIT method for the
> superclass is not mandatory in all cases, but only when the initialization
> is, so to speak, distributed in several scopes. For example, in example 4.12,
> class Savings calls the INIT method of its superclass, because the superclass
> has to store the balance, but class Account does not call the INIT method of
> its superclass (in this case, Object). And, of course, if some of the
> built-in classes needs that its INIT method is called by subclasses, this
> should also be documented.
>
+1
The interpreter could be made more robust to detect when a native INIT method
has not be called by a subclass.
Illustration with Supplier
s = .myUnitializedSupplier~new
say s~available -- Segmentation fault: 11
::class myUnitializedSupplier subclass Supplier
::method init
say "I don't forward INIT"
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
