DoSuperMethodA without amiga.lib
Well, the title says it all. This function is in amiga.lib but i don't want to include that in my program - would force me to use a linker and i wouldn't be able to just type "phxass source.s" to make everything. Duh.
Having been deceived by bare intuition, then by gadtools, and not wanting to depend on external libraries, i had a look to see if i couldn't fill in the blanks with boopsi gadgets. But it appears i can't even create a class, due to the lack of a way to forward a message to the parent class... So, how to do it ? Why didn't intuition.library implement that directly ? |
Quote:
|
So all i have to do is to grab the pointer to parent class and call the routine from the hook ?
Assuming a0,a1,a2 are like when i got called, it would then just be : Code:
move.l $18(a0),a0 ; cl_Super |
Well, except that you should better "INCLUDE intuition/classes.i" and make this a "move.l cl_Super(a0),a0", yes.
|
Quote:
Anyway, thanks for your help. I'm really a boopsi noob :D |
Once and for all...
All the routines provided by my lib are designed to augment the programming language. They have nothing to do with the way libraries are used in C ! Actually, if i could have done this in a 100% transparent manner, i wouldn't include any file at all ! So while alas necessary, includes must be as discrete as possible. Not doable if there are many of them, one per internal module of the lib ! Programs just call the routines as if they were regular instructions. Whatever internal library module they are in, is none of their business. There is no fundamental difference in f.e. my square root routine and a new instruction added to 68k that would compute integer 64-bit sqr. Whether something is an external call or a macro or a basic instruction does not matter much anymore. Pushing the concept, any high level feature can be added (screens, windows, files, etc). This all makes asm a higher level language retaining the advantages of the low level. And this is a good thing, as it removes most of the asm programming burden while keeping performance and code density. Forcing user programs to use a linker - a necessary step to hide the OS away while still using its includes - would destroy the concept completely. It is hard to explain, but for once please trust me. |
I ended up moving the other posts to another (locked) thread:
http://eab.abime.net/showthread.php?t=104904 Please keep this one on topic and avoid calling other members names. I'll let Photon, as he is more competent on coding matters than me, review the other posts to see if some posts should be brought back in this very thread or not. |
Quote:
Also what about porting your software to a system which is source compatible with AmigaOS (but not necessarily binary compatible)? Though I appreciate that if you have written in 68k assembly then that’s probably nothing you would care about. |
Quote:
Anyway, this is OT. Please don't resurrect that flame war. Quote:
Anyway, this is OT as well. If you want to discuss that, PM me. |
Quote:
I’m not sure it is off topic to discuss design decisions as to how AmigaOS’s original designers implemented their runtime OOP system. As you asked in your original question, which I think you were right to ask, and I was also curious! It is not unheard of (certainly in the Apple world), for an OS update to break binary compatibility, usually offering developers a grace period where their software will still work, but expecting developers to update their software... often it needs little more than a recompile! Quote:
|
Quote:
Everyone's free to code like they want, right ? Btw. It has already been more than considered : see link at post #7. Flame war ended up with thread split in half and the other half closed. Quote:
And creating a new object type does not look straightforward at all (merely creating it is, but the hook function is another story). Quote:
It is unlikely, however, that a new AOS version will come that breaks compatibility. It would be rejected by the community. |
Quote:
|
Quote:
Quote:
But if something is updated, and you do recompile you program, you would perhaps rather the newer function was used... giving the developers a chance to deprecate poor design decisions? |
Quote:
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. |
Quote:
Why, there isn't even a way to limit graphical operations of gadgets inside their area. Start drawing something, even with provided RastPort, and you get something relative to the window and not to the gadget. Try to use any gadgetclass derived class (like buttongclass or strgclass) and see that there is nothing to provide a nice, standard imagery like gadtools does. You have to do it yourself. And when you try to draw a box with frameiclass you suddenly discover it's totally useless because it's drawn incorrectly, far away from "nice" buttons of gadtools. However ability to draw everything out of the calling task's context is better than what gadtools does (window refreshing fails when the task is busy). Quote:
Quote:
But i can adapt. Even to a totally new design : only thing to change is my system framework, all programs using it would then work again as if by magic. Of course a few numbers to change here and there are far from being an issue ;) |
Quote:
You get the coordinates in the DrawInfo, though. Quote:
|
Quote:
Simple coordinate computation will work, until the gadget is anchored to right and/or bottom edge of window... Quote:
If the frameiclass is used, really i'd like to know how because it's not at all what i got ! |
Quote:
Quote:
Perhaps you are in a position to think about it, moving forward :) Quote:
I could be totally wrong here, this goes far outside of my experience of Operating System design! Quote:
|
Quote:
Quote:
Quote:
Wrong man, wrong time. |
Quote:
|
All times are GMT +2. The time now is 08:49. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.