Quote:
Originally Posted by bloodline
Like many things in AmigaOS, the idea is brilliant... but the implementation is a bit “off”... I can’t help but feel BOOPSI would have been better if it had been implemented at a language level like the NeXTStep engineers did with Obj-C. I seem to remember Andy Finkel waxing lyrical over NeXT in an interview once, so that is clearly what they wanted to do.
|
It's a small-talk like "message" passing system. For this to happen at language level, you would have to have a language that supports it. ANSI-C does not, so all the message handling has to be done manually.
Well, as far as the design is concerned.... I'm not so happy about it. First of all, boopsi messages are handled in the input.device task, as part of the intuition input handler to be precise. This means that any long-going activity blocks the mouse and the responsiveness of the system. Instead, the system would have been much better if the activity would be off-loaded to a side-task, and standard exec message communication would have been used. The way how it is done right now means that it is the responsibility of the boopsi to off-load an activity to a potential side task, and intuition is of little help.
Second, the message dispatch system requires each boopsi to go through a big "switch-case" statement, for each layer, at worst up to the root class, so this is not ideal. Hence, there is a lot of almost-identical decisions made multiple times, in each layer of the system. Having particular entry points in the boopsi library would have been better, but there would have been a need to register them somehow.
Third, the system is not ideally documented, so which message is handled exactly how often remains opaque to the user, and incompatible boopsis have been created as a side effect of this.
As messages are "dynamically dispatched" by the message ID only, message IDs will and have been added, so this is a case for better using their symbolic names. There are too many of them, and the set changes and is extensible.