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.

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

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

bit of insight conveyed to me, apparently has to do with the #create mechanism and #constrList being formed. which is a bit tricky when the ctor arguments are a bit differently shaped from a base class type to derived one. the workaround is tricky, selecting around #create when specifying a #base and doing the ctor chaining manually, which seems to resolve the issue.

In T170647#2563304, @michaelwplde wrote:

In T170647#2563281, @michaelwplde wrote:

Probably been covered before, having had a couple of learning moments doing appropriate method, ctor, dtor chaining. #base. prefixing works for academic use cases, IAnimal to ICat or IDog, for instance.

But if your hierarchy is deeper than a couple of levels, then I think perhaps prefixing to the interface is probably best. Say, IAnimal to IDog to IAustralianCattleDog. For instance, IDie (loosely, [_sides]) to IHeroSystemBody ([_sides, _zeroes, _twos]) to IHeroSystemBodyRoll ([_sides, _times, _summary, _zeroes, _twos]), attributes loosely illustrated. Plus "Roll" method behavior comprehension, i.e. "IDie.#create", "IDie.Roll", "IHeroSystemBody.#create", and so on

Such chaining may be set during "#create" ctor, or perhaps could be part of the formal type decl itself, in order to ensure appropriate declarations are being made. Would need to tinker with that what works, seems best, etc.

Starting to notice what others have reported concerning spurious, possible scheduled unscheduled, #create callbacks. Put some systemChat reports into my #create callbacks to examine the method chaining, and I am definitely seeing multiple "default" callbacks going on.

As observed, for instance with reports such as, meaning, should SHOULD report what I passed during createHashMapObject, correct? Ultimately... I see one such report on up the chain. Then there is a second pairing involving a _this "default" what looks like default arguments.

systemChat format ["[fn_hmo_onCreateHeroSystemBodyRoll] [_this]: %1", str [_this]];

That buggerboo is going to need addressing before HMO could be considered "ready" for prime time IMO, FWIW.

The pattern even looks a bit combinatorial, IOW (in other words), as you hike the callbacks on up the method chain, that introduces another combination to the resolution.

Definitely not what I would expect be happening creating a single instance HMO.

In T170647#2563281, @michaelwplde wrote:

Probably been covered before, having had a couple of learning moments doing appropriate method, ctor, dtor chaining. #base. prefixing works for academic use cases, IAnimal to ICat or IDog, for instance.

But if your hierarchy is deeper than a couple of levels, then I think perhaps prefixing to the interface is probably best. Say, IAnimal to IDog to IAustralianCattleDog. For instance, IDie (loosely, [_sides]) to IHeroSystemBody ([_sides, _zeroes, _twos]) to IHeroSystemBodyRoll ([_sides, _times, _summary, _zeroes, _twos]), attributes loosely illustrated. Plus "Roll" method behavior comprehension, i.e. "IDie.#create", "IDie.Roll", "IHeroSystemBody.#create", and so on

Such chaining may be set during "#create" ctor, or perhaps could be part of the formal type decl itself, in order to ensure appropriate declarations are being made. Would need to tinker with that what works, seems best, etc.

Probably been covered before, having had a couple of learning moments doing appropriate method, ctor, dtor chaining. #base. prefixing works for academic use cases, IAnimal to ICat or IDog, for instance.

In T170647#2563059, @michaelwplde wrote:

Have my eyes on the XPS OOP effort going on, aimed at leveraging the HMO work. I understand couple of improvements, corrections, in the dev queue around that effort. Meanwhile, trying to make a somewhat uninformed usage involving some forms of method, ctor chaining. I wonder if the internals are prohibitiing some key liberties I am taking in order to achieve that.

Have my eyes on the XPS OOP effort going on, aimed at leveraging the HMO work. I understand couple of improvements, corrections, in the dev queue around that effort. Meanwhile, trying to make a somewhat uninformed usage involving some forms of method, ctor chaining. I wonder if the internals are prohibitiing some key liberties I am taking in order to achieve that.

TL;DR will review some of the comments eventually... however, can I suggest a more elaborate page detailing just _what is a HashMapObject_, particularly nuances along the lines of #Flags, what they are, what can they be, "sealed" for starters. thank you...

BIS how is drama whatever an appropriate response? Can you please deal with spammers like this? Thank you...

I want to report, matter resolved, sort of. In a dedi mp mission, slot 2 images work as expected. I would be curious then to see what happens after that in a self-hosted mission, dev/test scenario, where it was not working as expected.

I see I may not be posting the only report in this regard. Any update, suggestions, workaround, why this does not just work?

Agreed, confirmed on my end; problem with the _Arma Script Profiler_ mod. When I load with ASP, crashes. When I take it out of the mix, loads fine.