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)

Systemvartags

Remove systemvartags and move all to the units where the nonvarargs version is. ALB42 (talk) 11:25, 23 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)

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)

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)