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

Difficult to decide for me the Diff I send to Charlie was the first option. But now when thinking about I tend more to 2. Option. ALB42 (talk) 11:25, 23 December 2015 (CET)

VarArgs Versions of Functions

Currently I like the lcl[1] 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)

There is an additional important point: at least "array of const" arguments require Object Pascal (or Delphi) mode. Which means ObjPas unit will be automagically linked to the executable. This inflates executable size, and no way around it, which is a big no-no, especially on classic, but we shouldn't depend on it elsewhere either. Our headers should not depend on Object Pascal mode I think. (This is BTW also the reason why systemvartags exists on Amiga - to avoid forcing the headers into OBJFPC mode.)

Chain-Q (talk) 03:15, 24 December 2015 (CET)

Systemvartags

Remove systemvartags and move all to the units where the nonvarargs version is. ALB42 (talk) 11:25, 23 December 2015 (CET)

See my remark about Object Pascal mode in the varargs question. The reason systemvartags exists is to avoid forcing most of the headers to ObjFPC mode, and thus inflating the executable size with ObjPas unit. So simply moving "array of const" functions is a no-go. We can use an array of longword though, if I remember correctly.

Chain-Q (talk) 03:21, 24 December 2015 (CET)

AmigaLib

I vote for introducing Amigalib to AROS (because the SDK also has it). There should be much more helper functions inside like the SetHook() function. ALB42 (talk) 11:25, 23 December 2015 (CET)

I agree. Chain-Q (talk) 03:51, 24 December 2015 (CET)

DoMethod

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);

ALB42 (talk) 11:25, 23 December 2015 (CET)

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)

MethodID is part of the varargs, but it must be listed in the declaration, due to how C varargs are parsed in C (they're parsed on the callee side relative to the previous argument, which must be named, for this reason). This is why DoMethodA() only has obj and msg arguments, MethodID is part of the msg argument there. And DoMethod() is only a varargs wrapper to DoMethodA() even in C. The additional problem with the version with the separate methodname argument is that the varargs has to be reassembled before calling the underlying DoMethodA(), because MethodID has to be appended to the start of the list. Also we could just add both versions anyway, but I'm a bit afraid this would cause further confusion.

Chain-Q (talk) 03:44, 24 December 2015 (CET)

OpenLibrary/CloseLibrary

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)