AutoHotkey Community

Yes I read your posts. If I understand you correctly, each function should have another function which calls the original one and the original one with short prefix would still work??

Say we have two functions with same short prefix of "ini" in file "ini.ahk". In both libraries there are functions defined "ini_load()". Ok. My mapping file decides for one of them (may be files renamed or something). Then someone other have a completly another mapping... Also that would introduce in some cases performance hits.

And all that would introduce more work. It would be easier just to rename the library and all prefixes. Then there is no problem. This collections aims that also, to let see other authors which popular libraries have which prefix or filename.

Also I do not want to bind someone to this application / script. The whole Ahk environment should work as it is without this script or collection. The collection is just an archive, not more (with some confort).

#define command is our only help, besides positional namespace command.

About the "incompatibilities list": I have re-thinked about that. There are just a few know of them, if any. It is too early for that. For now, i add incompatibility issues in the "Notes" TAB. If I have more than just some points, then I am willing to at a new tab for this topic.


Thank you for pointing that out. Ill try that and thank Philho later . That is exactly the topic i searched for.

_________________
{1:"ahkstdlib", 2:"my libs", 3:"my apps", 4:"my license"}
--> Don't feed the troll! <--

...so far I wasn't thinking of colliding filenames, just function names...I don't know how AHK's stdlib handling does multiple prefixes, but perhaps...





...now there's a conflict, both authors want the short name ini_load(), so the user chooses who's ini_load() he wants to use by editing the losers *_namemap.ahk...the user either renames the mapping or comments it out...(or stops #Include'ing it if he wants none of that users short mappings)...


...conflict resolved!...

...I agree, which is why I'd prefer #define style for the *_namemap.ahk, then AutoHotkey would remap the functions on load instead of needing to double call functions at runtime...

Awful idea. On the rare chance of a naming conflict Tuncay could ask the authors to change the prefix, pick the newer or better one for inclusion or give users the option which to install into their stdlib folders.

As the site owner Chris would be responsible for expressing this in a site terms and conditions or a notice. This could be a problem for code posted in the past by people who cannot be contacted. I don't think he will be willing to do this. As you said earlier, some script authors also don't want the burden of researching licenses and picking one for their work. The way things are now, that is shifting responsibility to the end user to seek permission or look for copyright notes or licenses is the the ideal compromise.

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

...I, as an author, will choose whatever prefix I want, as my preferred prefix, I will not change mine just because "its taken" by someone else...

My "awful idea" is a way to fix it...let the USER decide which author wins control over a prefix...

It doesn't. A_B_C() may be found in the following order:

• The main script or an #include (of course).
  AHKL/AHKU: %A_ScriptDir%\Lib takes precedence over user lib.
• A_B_C.ahk in the user lib (My Documents).
• A_B_C.ahk in the standard lib (AHK folder).
• A.ahk in the user lib.
• A.ahk in the standard lib.

Only the first underscore has special meaining. As an interesting but not so useful side-effect, functions beginning with underscore may be located in "_function.ahk" or ".ahk" (which is a valid filename).

...while I see the merit in the "main" dir overriding, perhaps the user-specific folder should override the system folder?

The problem would be here the compatibility. Your suggestion assumes that the library with same prefix is exchangeable with the other one. This is not good where libraries are automatically included.

of course, you - as an author - are free to choose whatever you like as a prefix, as long as you're not publish your work. when publishing a script which interferes with a different one, because somebody else got the idea to use the same prefix before you did, the user will get confused by that fact that you've choosen the same prefix but providing a completely different functionality.

especially the part of your quote 'I will not change mine just because "its taken" by someone else sounds to me like big blinders on your head and a profound lack of respect of the work and of the intellectual property of others.

c'me on ... if somebody decides to provide a stdlib for a topic such as a script which converts numbers from metric system to US customary units and decides to name it Center of Metric. as a consequence all functions provided in that function get the prefix COM (as in Center Of Metrics ). some functions need a prior initialization (due to dll usage) so a COM_init() function exists in that package, too.

now how would user A (except in changing every function name from the library) would solve that problem if the user A wants not only to use that metric stuff, but also some decent COM objects from sean's COM StdLib?

and how would user B who downloads A's sample understand the sourcecode by reading COM_Init() - which COM stdlib script is used?

i think, this problem can simply be solved by a naming convention in the spirit of first come, first served. whoever comes after a desired stdLib prefix has been published, simply have to choose a different prefix when it comes to presenting a script as stdLib compatible and ready to use by community. its as simple as that. (also as an option b, one might ask the 1st author if it 'd be a problem to use the same prefix - but this is the wrong way to go )

anything else would either break existing scripts or simply spread confusion. ahk is a language which is designed to be easy. having stdLib scripts which use same prefix would scare away n00bs and confuse those not running away. its simply not the spirit of ahk.

basically the idea behind this is pretty much the same as in business world. you won't be able to name your company microsoft and have a product named windows 7 when you're not affiliated with Redmond's Microsoft. Just because this is about open source software and shared libraries it doesn't mean everybody may use well known stdLib prefixes for own functions and publish these.

by reading the quote again, i can just shake my head about such a small minded perspective
dR

_________________

All scripts, unless otherwise noted, are hereby released under CC-BY

Added this topic to first post:

List of used prefixes and filenames

_________________
{1:"ahkstdlib", 2:"my libs", 3:"my apps", 4:"my license"}
--> Don't feed the troll! <--

...I mean I'm not gonna avoid the best prefix for my functions/library, just cuz someone else "registered" them here 1st (I don't "conform" to standards). I think the "most useful" function/library should win a prefix.

If it helps, I reserve Base_* for me...(not that every one of my functions will use that prefix tho)...I will most likely just implement my "awful idea" & let the user override my function's names...& it'll probably end up being a script to edit all .ahk files...


...case-in-point: who "won" the $ & A prefixes?

The $ is a library for all functions I found, which dont get a separate file. It is a shortcut to "Standard". I am not sure on myself at this. It seems no one other use that.
The A prefix is a library to work with Arrays.

At this point, I am willing to discuss. I do collect just those libraries, and sometimes i find it unnatural how others name their functions and prefix them too. Everyone is welcome to make suggestions for better one.

_________________
{1:"ahkstdlib", 2:"my libs", 3:"my apps", 4:"my license"}
--> Don't feed the troll! <--

Good. May I indicate a few functions of mine?

_________________
"Read the manual. Read it again. Search the forum.
Try something before asking. Show what you've tried."

Antonio França
My stuff: Google Profile

No question, yes! But think about it. The $ is not a solution for the user. Functions in the default $ library are not listed in the gui and not seen as important and useful.

_________________
{1:"ahkstdlib", 2:"my libs", 3:"my apps", 4:"my license"}
--> Don't feed the troll! <--

What about the "Open Documentation" button?
There could be a merged documentation for that $ lib...

_________________
"Read the manual. Read it again. Search the forum.
Try something before asking. Show what you've tried."

Antonio França
My stuff: Google Profile