Thats generally what people consider a library, a repository of code that multiple addons use.
The keyword here, as Elsia pointed, is PRIVATE
AlarLib IS going to be used by multiple addon, but ALL written by me.
I put in the form of a lib to take advantage of versioning and packagemanger, so I dont have each time to manually build the zip.
If this is fair use of WAU, stop ranting, if its not ask me to remove the crap from WAU.
Tertium non datur (latin, so now is your turn to google for a translation :P )
Now, can we go back to business?
I learnt a lot from this thread... and I am taking the habit of coding as if Xinhuan is watching over my shoulders... while it doesn't improve the pleasure of coding it prolly improve the quality of the code 8-)
I can promise you it'll never get added to AceEvent-3.0 as long as i am part of the decision process about Ace3 features. :)
At last.. I got the answer to my question. That was not "How can I have something fires right when leaving combat?" (believe it or not, I can code an event handler) but "Will ace 3 provide it"?
It took 2 pages of posting.. but at last we had it :)
I for one cant see the reason you are so proud for having removed it, but it's your framework, and it'still a lot useful, so I am grateful you found the time to code it.
Quote from Elsia »
Alar, I think you are holding up well. Multiple people already gave the warning signs that things can be very blunt.
The question of what should be in a library is hostly debated and in general, if in doubt a library will nowadays not carry a feature than carry it.
Not sure I understand what "you are holding up well" means, but looks like you tried to pat on my shoulders.. and I do appreciate :)
I think the big misunderstanding is in what is what. AlarLib was NOT intended to be a "library" in the common sense, it's just a repository of thing I found myself coding in more than 1 addon.
If you read AceEvent-2.0 code, you would know that all ScheduleLeaveCombatAction() does is register a function to callback your registered function when PLAYER_REGEN_ENABLED is fired. If the player isn't in combat in the first place, then the function gets called right away, instead of "storing it" until PLAYER_REGEN_ENABLED arrives.
That's all it really does. Its just a fancy wrapper for what Tekkub wrote.
When I started using internet it was in black and white. Literally. We used Lynx and we paid for every byte we downloaded. So you will not make me to post here 60 lines of ScheduleLeaveCombatAction(). It's just against my nature ;_) .
Besides what you said ScheduleLEavCombatAction maintain a register of actions to be run, each one with its parameters so you can forget all details and just wrap it around for example the change of a flag who affect combat related things.
Besides that, I bet that if I just wrote a new ScheduleLeaveCombatAction and then it was added to AceEvent-3.0 you'd say "Why are you wrapping/recoding it?" :D
I never made assumptions about your mental health. As I said way up there ^... you needed to brace yourself for what we were about to say. This is all constructive feedback you're getting here, because we thought (hoped?) you are open to it for the betterment of your code.
Just to make things clear.. you are probably both underestimating my coding ability and overestimating my english understanding :D
For example, I have no clue about what "brace yourself" mean.
I am open for improvement and criticism, but not when criticism is beating a dead horse. AlarLib-2.0 is a compatibility layer. It's not there to stay. If you are willing to spend some time helping me you should do it in AlarLib.3.0 (in branches now) where I am moving things from AlarLib-2.0 trying to both remove what is no longer needed and clean what i think is still need. Just remember you are talking about code for private use. In now way I assume someone could ever use it besides me.
I do like wrapping, but i try to keep it where it doesnt get executed a lot of times. Main use is for intialization routines, where I think faster coding is superior to optimized coding.
Quote from tekkub »
Yes, we are criticizing your code. We're not doing it to spite you, we want to help make it better. If you don't want us to, just say so and we'll stop.
Uhm... I thin you know that ScheduleLeaveCombatAction was doing far more than
-- Do the crap you want when leaving combat
and that your snippet does a totally different thing. So your answer looked more a way to make me look stupid (or iust more stupid than I am) than a constructive feedback. Reading it with my eyes,, are yiu sure you had found it a "constructive feedback"?
peace and love
The main reason it was brought up is because you load all that code in every addon that uses it, which is usually a bad thing. A good chunk of it is redundant, especially if you're using the ace libs. It's kinda assumed (though not required) that if you're submitting to ace's svn you're using the ace libs.
Tekkub, I didnt wrote AlarLib to interface Ace2. I had AlarLib as a mix between a framework and a standalone soubroutine collection. When I moved to Ace2, i hadnt the time to rewrote all code, so i slammed Ace2 inside Alarlib primarly to use AceDb, AceEvent and AceHooks. The result is quite a mess, but it works and once loaded my addons performs quite well (AlarBgHelper is used by a couple of thousands of people, so I assume it doesnt destroy their PC :) )
So if you want take AlarLib as the "How not code new libraries example", you are welcome. But making assumption on my mental health from it is not correct :D
Btw... going to sleep, past midnight in my timezone
A famous example is when you renamed your library from !AlarLib to AlarLib (why did it have a ! in front in the first place when you can just optdep it? Addon loading order is based on file system, it is only on a NTFS harddisk that loads addons in alphabetical order, FAT32 disks certainly don't.)
I agree. it was a mistake. Who is without sin throw the first stone
Quote from Xinhuan »
Another example is when you put in coroutine wrappers. If you're going to use something in an addon, do it directly in the addon. Don't put it in a library, and then include the library in the addon, and that addon is the one and only addon that would ever use that something and that library.
Code could be in a lot of places, as long it's not duplicated (and my library is only loaded once even if 4 addons use it. Every addon store pointers to function in the single library istance. It's embedded, even if not (yet) in the standard way).
If i feel more confortable with a (in my opinion) more consistent interface for coroutines, just to be sure I dont mess with timers and events, why does it disturb you? Is the code in the wrapper wrong? Does it make bad things to the shared memory or badly affect the garbage colledtor? I dont think, cause it just store pointers to couroutines and set up a simpler way to stop and restart them. If you could point something actually not working as intended or adding lag instead of just the theory against wrappers, it could help me more.
Inside AlarBGHelper coroutine wrappers are called just once at loading (CREATE), and on request when the user enters(START) or leaves (PAUSE) a battleground. A battleground lasts in the range of 10-70 minutes.
So we could have a worst case of 2 call every 10 minutes. I think in this case easier to read and use code is better than optimized code. Do the paused corotines use so much memory to make a problem? This could be an issue I underestimated
But yeah take Tekkub's advice. Code it yourself, it's pure fluff. Which is what most of your library is about btw Alar. Wrappers around every function in existance. Hop on #wowace, and wear your asbestos suit and sunglasses :)
Wow, never thought about me as a legend... :)
Seriously, I am glad you have so much spare time to review a clearly marked "private" library to check its code. I mean, while you were at it you could read the description: "General library for Alar's modules. Internal use."
Honestly, if I choose to have the majority of the code inside a library instead in the addon core, I think it should be my business and business of people using them.
It's not "maybe be useful at some point in time to someone, somewhere"- It's "I need it (or, I needed it and not yet removed the dead code)" and "If it works, dont fix it". I will rewrite it from scratch somewhen, but it will still be "for internal use" and done to make things easier just for me.
If someone else is only thinking about using AlarLib he's a fool :D
There is no fucking reason to use it if you are not Alar. I dont use it for new projects, too!
Last but not least, I'd like for sure joining #wowace but even if I can afford english OR technicalia OR chat slang, i cant afford all of them together.
As you probably guessed, my english is far less than good, and as far as I know I am the only italian guy programming addon. This doesnt help sharing of ideas and knowledge, not to say all documentation is in a foreign language for me