Talk:Decisions and Work
Page for Discussions about the Decisions, sort into the right region and do not forget to sign your comment
ABIv0 / ABIv1 in AROS
VarArgs Versions of Functions
Currently I like the lcl way the most, would be even possible to extent it to automatically keep track of strings. (Copy them internally and destroy them when the taglist is destroyed). But for the moment the array of PtrUInt and TAG_() is the cleanest and easiest approach. ALB42 (talk) 11:25, 23 December 2015 (CET)
I prefer currently the 2. Option looks more clear and more close how you would write a Pascal Method
DoMethod(obj, methodname, [param1, params]) -> obj.methodname(param1, param2);
- I have no personal preferences on this matter. The SDK is clear, but interpretation might differ. If using a solution that is not in correspondence with SDK then document it and offer an explanation of why it was chosen to not follow SDK.
- However, please do acknowledge the fact that there are methods that requires no parameters at all and offer an overload version that supports this.
- For me personally, the most important here is the consistency for all supported platforms.
- Molly (talk) 18:24, 23 December 2015 (CET)
DoMethod(obj, methodname, ) -> obj.methodname();
- do not need a special version, just call this way. hmm for my understanding he SDK is not clear in this point because it's C and both possibilities would follow it. DoMethod(obj, MethodID, ...) does not tell where the "[" should be ;-). With the Option 2 you can force to give a MethodID, because the Footprint tell you how to do it: DoMethod(Obj: PObject_; MethodID: LongWord; Params: array of PtrUInt). With the footprint for Option 2: DoMethod(Object: PObject_; MethodIDandParams: array of PtrUInt); is a little bit strange. In the End both no big difference just need a decision for all Amiga-likes.
- ALB42 (talk) 19:35, 23 December 2015 (CET)
I strongly recommend the 1. Option because thats what the people are used to in Windows/Linux. And it work in many sources. If the Library is not there, the application writer has to check for its existence. maybe we can give there a hand by introducing special functions to check if all Libraries open correctly. Sometimes it's wanted the Library is not there (bsdsocket.library for example) ALB42 (talk) 11:57, 23 December 2015 (CET)
- I agree that it could be more convenient to use an already 'proofed' and working method.
- However, this [draft] was meant to experiment with other solutions. (this was done before the 'bug' in exitproc was discovered -> it can be changed).
- I personally would prefer (too soon, perhaps first make it work ?) a solution that goes beyond FPC current default offered solution(s).
- The draft as linked to, offers that possibility, but also can be extended to offer all kinds of user definable manners in which the users want to open libraries. e.g. an extra function UserOpenLibs([INTUITIONNAME, GRAPHICSNAME]), OpenDefaultLibs(); or something similar would be possible.
- In the end and imho, the best solution would be to not depend on this kind of behaviour, but instead, make the 'retrieval' of the library base smarter. Whenever a librarybase is nil (and used to call a library function), the library should be added to a list (to keep reference for auto-closing), and the library should be auto-opened. The fastest would :be some kind of property behaviour, that is able to switch the actual 'retrieval' function, so that when a library is already opened that it will not goes through the 'nil' check code again.
- For ^^ that to be able to happen, i think the easiest would be if there would be a generic entry/exit just before/after unit initialization/finalization is being called. e.g. JustBeforeInitializationOfUnits(), JustAfterFinalizationOfUnits(). e.g. there should be a possibility to 'panic' and exit in a manner that is OS 'friendly', and waste as less resources as possible.
- Of course all the above with the notion that user is always able to open close libraries manually using API calls -> which could cause havoc. For that the library base shall not be user accessible, instead it would be users responsibility to provide a library base if he/she want to do things on own initiative.
- The whole purpose of the draft as linked to, was to offer one generic location where libraries are opened closed, so that additions/expansions/improvements only has to be done at one single location. The fact that including a special autoopen unit that opens the libraries automatically, was a demonstration of what would be possible (that includes checking if a library actually exist on disk and act accordingly).
- Not all above was thinked through extensively, so feedback (especially on impossibilities/issues) would be appreciated
- Molly (talk) 17:35, 23 December 2015 (CET)
- for sure the current method does not work, so one could also think about to implement the easy solution then with more time think about a more advanced solution for later use. Because with the current situation I can not continue on anything in Amigs/MorphOS. top open the Library when a Libbase is nil sounds like a good idea, but its not, how to notice that it didn't work? you have no backchannel to the program how used the call (and maybe didn't know its a library call). Of course an exception would help but then we end up with the same costy exceptions as I described before.
- The librarybases MUST be accessible to the user, especially intuition, exec and such kind, but also other LibBases have interesting fields to use.
- And after all one should remember with LCL/fpgui it still should be possible to write multi platform apps, which should not have some special entrance points, error handlings and so on for our systems.
- at last I'm a big fan of KISS, and the simplest solution is the solution 1.
- ALB42 (talk) 20:07, 23 December 2015 (CET)