I don't see what's wrong with multiple stub managed major versions of libraries running at the same time
Nor do I. If you want something which you know only has one instance, period, and embed really isn't what you want. You want a simple standalone library and a ReqDep. That standalone can do everything it wants to support multiple (old) APIs. When you embed a library, you're expecting that version of the library to be there, you're taking the responsibility for the lib off the user.
Well I think most of the CL ideas are for crap like Gratuity-3.0, which is just Gratuity-2.0 switched to LibStub.... where both libraries are exactly the same, minus the stub.
But the problem with that whole idea is, is it REALLY needed? For a standalone, yes a "generic" AceLibrary-based lib could be made that simply provides an "interface" into LibStub that uses the AceLibrary API... but then you get into mixing and all the AceOO and... well suddenly that whole thing doesn't sound fun at all. It sounds like, in some cases, the CL would be LARGER than the library... and suddenly the CL doesn't look compelling over running parallel libraries.
I love LibStub, but on the same front I'm slow to upgrade my embeds because a) the shit still works fine and b) I don't want to take the time to test and fix everything in the transition. It's the same with every other lib upgrade we've had, people don't jump on the new stuff the instant it's available because, in most cases, things work fine as is so there is no gain from the time spent converting. I'll be all over new stuff when I'm writing new addons, but for my year-old stuff that still works, it just ain't worth my time.
It's kinda like those companies that have 10yo mainframes because they still handle what they were designed to do just fine.
--i hvae a better response to this .. give me a minut.
It's been two minutes, you lost your chance!
Quote from Aestil »
but Tek, I don't use embedded libs. So many compat layers are there, and are good for people who prefer to run standalone libs then?
While I can see a case for a CL in that use case... I'm becoming more and more convinced that disembedding is not very advantageous beyond the core libs that repeat in every little addon and large "database" libraries. For my libraries that are used in a minority of addons (like Gratuity and others) I do not intend on providing standalones AT ALL.
CL within a standalone I will accept, as long as it doesn't interfere with an embedded version of the old lib. Embed versions of the new lib SHOULD NOT screw with the old lib. Also, if a user comes running to me crying that an old addon no longer works because they're using a new major with CL instead of the embed I coded and tested against... I will feel no sympathy. I will simply point them at whoever did the CL stuff and tell the user: "it's his fault, it's his problem, sorry."
Compatibility layers aren't needed with libraries! An old mod runs Ace2 version of Gratuity, it works fine. This addon embeds the lib, so it's already being loaded into the system. A CL simply adds more unneeded complexity and processing for what gain? Code duplication on the small scale (2 diff majors of the same lib) is not detrimental... code dupe on the large scale (150 addons declaring their own tooltip for parsing text from) is.
There have been many MANY cases where library upgrades have broken old addons when they shouldn't have (and I'm not talking about bugs in the upgrade path here). I for one, and I can think of a number of other devs, hate it when people screw with libs and break old addons because of it.
Upgrade libraries to LibStub, away from Ace2, make them not framework-dependent, that's a VERY GOOD THING... but don't screw with the old libs. Up the major and move on, it's that simple. Old mods will be rewritten or break in due time, there is no reason to force breakage upon them now, even if it's unintentional.
You don't understand the embed lib design. If you upgrade a lib and maintain backwards compatability (which is what the compat layer is there for in other stuff) then you bump the minor version. That means the change you made won't break old mods using older versions of this major version.
If you change something and DO break backwards-compat, you bump the MAJOR version so that old mods aren't broken.
A "compatibility layer" in between major versions makes no sense, it goes completely against the whole embed design in the first place. If you break compat, then old addons need to evaluate the new version, see if they want to use it, get changed to use it, and tested against it.
To use your PS model... The user had a PS1 for GameA, they had to have it to use it. Later, they got a PS2 because they needed it for GameB. They still have the old PS1 wired up because it's there and it works fine (and in the WoW namespace, one it's there it doesn't go away)... why should the PS2 intentionally smash the PS1 with a hammer and then try to provide the functionality it provided? Now throw a PS3 into the mix... same thing. Yes, I understand that a user would toss the PS1 in a closet because the PS2 provides the same features.... but the Addon embedding the old library expects the old library to be there... it's not written for the PS2 or it'd use the PS2 and never have the PS1 in the picture.
It's an odd comparison I guess, but when you think of it in terms of the PS1 is always there once it's "loaded", then you'll get the embed design.
"Consumption" implies "use", don't play word semantics here :P Users often don't know there is a difference, and simply telling them that "memory use doesn't matter" comes across... well... like KLHTM's dev saying that blizzard's profiler doesn't work and that's why it's numbers for KLH's performance look bad.
Assuming the person who actually makes a library does there job right and is bumping majors on incompatible changes, chances are you're already running a few copies of the same library anyway and it hasn't been that big of a deal yet. The only time you'd ever have a chance to notice a decrease in performance is if you were running two heavy usage libraries like Parser.
Peak memory is immaterial, yes.... but memory consumption rate is a VERY valid performance issue. Don't confuse people with blanket statements.
Quote from Ellipsis »
And then there's the compat layer to add to the new version, and all the addon authors who need to be bugged to change their .toc/externals to use the new library, and...
Which is totally the wrong way of doing embeds. The whole point of majors is to completely separate the new lib from the old one. If old mods use the old lib, yes there is duplicate crap happening, but the old mod needs to be upgraded (or not upgraded in some cases). "Compatibility layers" are crap, either upgrade the old lib and don't break old addons using it, or make a new major that exists in it's own world and doesn't screw with the old addons using the old lib.