DoSuperMethodA without amiga.lib

[kamelito]

Morphos is using Objective C, why not AmigaOS.
https://www.morphos-team.net/guide/objective-c

[bloodline]

Originally Posted by kamelito

Morphos is using Objective C, why not AmigaOS.
https://www.morphos-team.net/guide/objective-c

OMG!! Yes that exactly how I imagined BOOPSI to be implemented properly!

-edit- it looks like they have written their own Obj-C runtime, that’s quite heavy going... I use Obj-FW if I need a runtime on a non-gnustep/non-Mac platform!

[Minuous]

Originally Posted by bloodline

AmigaOS is somewhat unusual as the basic operating system remained unchanged for 30 years... only now is AmigaOS 3.1 being updated. As such the API/ABI is literally etched in stone. Make a change now and you burn 30 years of legacy rather than maybe five years...

That's not correct.

[bloodline]

Originally Posted by Minuous

That's not correct.

That’s a fair point! Microsoft actually adopted the strategy of keeping 30+ year old operating system components in their products. And it’s worked well for them. But this is certainly off topic, with little to do with BOOPSI.

[Minuous]

My point wasn't about Microsoft, it was development continued beyond 3.1. Eg. OS3.5 and 3.9 have a full set of BOOPSI classes, which 3.1 lacks.

[bloodline]

Originally Posted by Minuous

My point wasn't about Microsoft, it was development continued beyond 3.1. Eg. OS3.5 and 3.9 have a full set of BOOPSI classes, which 3.1 lacks.

But the underlying architecture of how BOOPSI works has remained unchanged for 30 years! All the flaws and bugs are now part of the design, which (as meynef pointed out) has some advantages that they are at least known and work arounds have become standard part of the architecture, but also limits future development.

[Thomas Richter]

Originally Posted by bloodline

All the flaws and bugs are now part of the design, which (as meynef pointed out) has some advantages that they are at least known and work arounds have become standard part of the architecture, but also limits future development.

Well, I would not call them "bugs" (of course, we have that, too), but "design issues". They cannot be fixed anymore. We have the same thing in the dos.library with its Tripos legacy.