Page MenuHomeFeedback Tracker

[HashMapObject] Chaining #create ctor strategy
New, NormalPublic

Description

If I understand the #create coallescing strategy... A brilliant idea crossed my mind how to facilitate #create ctor argument chaining, in a way that is respectful of typical OOP patterns.

Rather than apply a single _this ubiquitously over the #constrList ARRAY, allow each of the methods to transform the current _this for the next parent call in succession.

Prototype SQF might look like this:

// Assuming in derivation order, from most recent to parent
private _ctors = _self getOrDefault ["#constrList", []];
{
    [_self call [_x, _this]] params [["_next", []]];
    _this = _next;
} forEach _ctors;

Allowing the current ctor _x to return a _next or may return nothing at all, defaults to [] for the next ctor in succession.

Thoughts, concerns, questions? What do y'all think?

Maybe this could be got into the next dev branch, and assuming it isn't too disruptive of early HMO adopters.

Details

Severity
Feature
Resolution
Open
Reproducibility
Always
Operating System
Windows 10 x64
Category
Feature Request
Steps To Reproduce

Under the currently deployed HMO pattern, if I understand things accurately, createHashMapObject is applying the same _this ubiquitously across the range of all coalesced #create methods.

However, assuming prototypical OOP patterns, I do not think one can necessarily depend upon ctor params lists being the same. In fact, most commonly they are not, and some form of appropriate relay is to be expected.

Event Timeline

michaelwplde updated the task description. (Show Details)Feb 6 2024, 4:55 PM
michaelwplde updated the task description. (Show Details)Feb 6 2024, 5:12 PM
michaelwplde updated the task description. (Show Details)Feb 6 2024, 5:17 PM

Could even optimize the core of the approach a little bit further.

_this = [_self call [_x, _this]] param [0, []];
// _next ctor _this arguments:          ^
// default to empty array:                 ^^

Could also facilitate via #flags for that matter, if it is considered an early adoption breaking change.

With an eye on #constrList constituency, might also default member #type #create functions with a sensible default along similar lines. i.e.

_self getOrDefault ["#create", {_this}];

Again, could be #flag opted in either way, assuming early adoption, breaking changes, etc.

This comment was removed by LouMontana.