Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
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.
tekkub ... i think i can speak for alot here and say "We Know and Understand this..."
but the problem is that these libs are being reStructured to work with a new framework.. or with out one.
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
this proccess has always been left to the perticular author... and not all of them are still arround or want to reconfigure their addon to use a new Major Revision Lib... and we are still even MID Proccess and not all libs are converted over.
your argument holds water.. but is not an significant issue at this time. Once Ace3 / Rock Stabilizes then your argument MUST be evaluated.
by providing compatibility layers between major libs .. it is an appeal to the masses.
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.
"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.
Fine picky, fixed. I still said static memory in the other topic.
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, it's probably technically true that you gain a little performance by adding a compatability layer so you don't have 2 majors running that are doing the same thing.
While we call it major/minors for the sake of simplicity, UberLibrary-1.0 and UberLibrary-2.0 are two entirely different libraries to the stub, we use the wording majors (<name>-<major:1.0/1.1/1.2/2.0/3.0/ect>) because it makes more sense then renaming UberLibrary to ZOMGHAILibrary when you want to bump the major.
For example, lets say I have Foo thats running UberLibrary-1.0 and Bar thats running UberLibrary-2.0 both using UberStub
UberLibrary-1.0 loads and registers itself with UberStub.
Foo loads and says "I want UberLibrary-1.0"
UberLibrary-2.0 loads and registers itself with UberStub
Bar loads and says "I want UberLibrary-2.0"
Even though both do the same thing, UberLibrary-2.0 contains changes that aren't backwards compatible with UberLibrary-1.0 this way with different majors Foo and Bar can run without any issues due to the incompatibilities.
UberLibrary-2.0 when it loads could go "No, UberStub, UberLibrary-1.0 is actually UberLibrary-2.0-Compat" and instead of the functions that Foo calls going to UberLibrary-1.0 they go to UberLibrary-2.0-Compat which then calls UberLibrary-2.0.
See? That ruins the entire idea of using majors and it's completely pointless, an author should setup there addon to include the library they need and so has no requirement for using a compatability layer. I haven't looked into how WAU does it, but I'd assume that it either downloads all the libraries as LoD, or it downloads all the libraries that the addon uses and names it by the major version.
Compatability layers are stupid, it's essentially a way to say "**** you" to the person who did the library that you made the layer for.
--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."
Let's flog this dead horse with a concrete example using AutoBar & the PeriodicTable-2.0 -> PeriodicTable-3.0 transition.
Ok, as an author I bitched about having to upgrade but the reasons were compelling: compressed & thus smaller data sets, better organization etc. Therefore I chose to upgrade.
The new stuff was completely incompatible with the old: keys changed, data sets got moved around, merged split apart, dropped.
What would a CL layer have done? Well:
*It would have had to maintain a table translating the old keys to the new ones
*It would have had to add old comapatability sets for each set that got merged, dropped or split
*There would be this redundant code sitting there unused by any mod that did upgrade
*Time would be spent on CL & debugging the CL & debugging old crappy unupdated mods just because maybe the CL broke something
What happens in the long term? PeriodicTable-4.0:
*Needs a CL layer for the CL layer
*Needs CL for 3.0
*Needs double the implementation time because of all this completely uneccessary stuff
*More time debugging CL
PeriodicTable-5.0:
*CCCL
*Triple the imnplementation time
*Features dropped because the code is starting to become total crap & a nightmare to upgrade.
*Fulltime person now devoted to dealing with CCCL etc. ssues in old mods
PeriodicTable-6.0:
*CCCCL
*Never released for use as the CL stuff was too complicated for a human to upgrade within the lifespan of the universe
*Who cares about its features, nobody got it working.
Hopefully this clears up any confusion. If it does not, may I point out a real life example in Microsoft Vista? It took Microsoft over 10 years to give birth to Vista because they maintain backwards compatability all the way to the days of DOS or something sick like that. CL is crap & if u can avoid it you do so. In the case of libs simply using the old libs for lazy mods is all the CL we need which is: ZERO.
Let's flog this dead horse with a concrete example using AutoBar & the PeriodicTable-2.0 -> PeriodicTable-3.0 transition.
Ok, as an author I bitched about having to upgrade but the reasons were compelling: compressed & thus smaller data sets, better organization etc. Therefore I chose to upgrade.
The new stuff was completely incompatible with the old: keys changed, data sets got moved around, merged split apart, dropped.
What would a CL layer have done? Well:
*It would have had to maintain a table translating the old keys to the new ones
*It would have had to add old comapatability sets for each set that got merged, dropped or split
*There would be this redundant code sitting there unused by any mod that did upgrade
*Time would be spent on CL & debugging the CL & debugging old crappy unupdated mods just because maybe the CL broke something
What happens in the long term? PeriodicTable-4.0:
*Needs a CL layer for the CL layer
*Needs CL for 3.0
*Needs double the implementation time because of all this completely uneccessary stuff
*More time debugging CL
PeriodicTable-5.0:
*CCCL
*Triple the imnplementation time
*Features dropped because the code is starting to become total crap & a nightmare to upgrade.
*Fulltime person now devoted to dealing with CCCL etc. ssues in old mods
PeriodicTable-6.0:
*CCCCL
*Never released for use as the CL stuff was too complicated for a human to upgrade within the lifespan of the universe
*Who cares about its features, nobody got it working.
Hopefully this clears up any confusion. If it does not, may I point out a real life example in Microsoft Vista? It took Microsoft over 10 years to give birth to Vista because they maintain backwards compatability all the way to the days of DOS or something sick like that. CL is crap & if u can avoid it you do so. In the case of libs simply using the old libs for lazy mods is all the CL we need which is: ZERO.
I suspect that there will never be a compat layer for PT, but it seems to make sense for me, Parser for example. VampircTouchFu needs Parser 1, and i think so do a few other mods, but then a bunch other need Parser 3 [now 4] If Parser 4 can provide the compat layer adequately, I rejoice, if it doesn't then yes Tek, its my own fault and I either need to bug CKK [in this case] or just load the old lib.
In fact I did this today when Crayon compat didn't work and broke 3 of my addons.
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.
WARNING: I do not want a flame war here (even if I think it's nearly impossible to avoid it), I'm asking my questions on general frameworks, don't think about Ace, Dongle, Rock, or your dog's framework. Don't do it. Save the world, keep this thread clean.
Something has been bugging me for a few days now, and I'd like to have some explanations on this.
Everybody seems to agree that running several frameworks at the same time is not a problem, the user will not see the difference, bla bla bla... But hey, I was thinking a bit about how works a framework, and I'm surprised about this.
Running two frameworks means:
- Running two OnUpdate() managers at the same time.
- Possibly running two libraries that do the same thing but that runs on each framerwork separately.
- Having two configuration managers loaded (i.e. /slah, gui, ...)
So how the hell having two framerworks (or more!) would not change anything to the CPU and memory usage?
Thanks for your answers ;)
If you consider the impact of each addon running standalone, running 3 frameworks is an improvement from this point of view. But I think some of your worries are non-issues.
The OnUpdate thing is one. A single OnUpdate manager in a library still has to call several OnUpdate functions for the several addons using it, which all use different code in their OnUpdate handler. I can't see this being any different than merely using multiple OnUpdates for each addon, and having the code split up. Hell, that might be slightly quicker even. All this does is lessen the amount of frames created for said processes and simplify the use of OnUpdate really.
Having multiple frameworks do the same code is really the same. Generally it's expected that each addon will do this work by itself anyway. And the libraries still in most cases have to split up the task to serve each addon. For instance, events. Normally addons could just run scripts by a frame and that's it. With a framework a check needs to be done on which events are registered and then each event is dispatched for each addon. If anything, that's more work than addons doing it independently.
Configuration managers are going to work the same way. Every addon still needs to register its configuration and have it handled so all you're losing is a couple frames that build the menu itself, which are a negligible loss.
So while there might be places a framework can help with speed by handling tasks in a single place, there are also parts where it could be slower. There isn't really any noticeable loss OR gain to using a framework, which is really what every developer is trying to tell you here: Stop caring about what framework your addons use and just use the addon; you don't need to know the framework exists and it makes no difference to you.
This thread is horribly one-sided, and largely without technical merit.
Compatibilty layers are part of having an existing codebase which you wish to support. They play important and useful roles in the long term.
For example, applications can often be ported to new environments, or integrated with other systems by replacing the libraries they use with "complatibilty layer" libraries which give the old code a new runtime execution environement. The reason for doing this is simple - you dont have to change the old code.
Also, running multiple versions of a library may not be realistic it depends on the library and what it does - you appear to be claiming it does not, and that they always can.
I don't think you have reached a conclusion of any sort - or that this thread has made any progress towards that end.
The closest parallel I can think of is MS - SideBySide execution (and virtualization/isolation). Embedded libs are a mixed up combination of staticly linked library concepts. However they lack the completeness the MS system ahas
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.
I've got a crap computer. Pure crap. That's a total understatement. It's a store-bought shelf computer that was lower mid-grade in late 2002 and isn't compatible with a lot of the newer technology today. I lag, and I lag badly. Even the slightest overuse of the CPU is noticeable to me at least a little.
Before the port to Rock I was running around 90% Ace2 addons and the rest were framework independent. I had a noticeable amount of lag, as I expect. After the port it just so happens that I also decided to throw in a couple addons to my package written on Dongle, so within a couple days I went from a single framework and some independent addons to 3 frameworks and several independent addons. Just as referance I run a very heavily modded UI. After the switch and addition to my UI, my memory went up by a light and totally negligible 1 MiB. That's it. And my lag? Well, it actually lessened noticeably, and I hadn't removed anything.
Running multiple things won't hurt, and there's real-world evidence of it. Multiple libraries merely give coders a chance to diversify their code a bit more, and as a result you will actually often see improvements when the coders make the decision to change.
Now as far as where this thread's gone on compat layers and all other stuff you guys are discussing, I really don't want to bother to comment right now. There are more than enough brilliant minds around this community that know their fair share of the subject to give you a great idea on it. But as far as the original issue in the post I don't think you need to worry.
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.
You may not see the problem, but the parallels to MS, "dll hell", and their solutions to it are there - one would be wise to at least see the problems which they had, and what solutions they came up with.
I don't see any problems wrt compatibility layers. The only thing that is done wrong is pushing them into the library where they don't belong.
It's fine to provide them as standalone versions or seperate librarys so those who run standalone (meaning those who should know what they are doing) can fetch the layer and redirect the calls from the old lib to the new one.
But besides that a new major version of a lib shouldn't mess with other major versions when it comes to calls.
I don't mind compatibility layers being integrated when they're just simple renamings of existing calls.
More complicated things I'd probably push out into separate libraries, depending on how much extra code it is compared to the library. :)
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
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.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumbut the problem is that these libs are being reStructured to work with a new framework.. or with out one.
this proccess has always been left to the perticular author... and not all of them are still arround or want to reconfigure their addon to use a new Major Revision Lib... and we are still even MID Proccess and not all libs are converted over.
your argument holds water.. but is not an significant issue at this time. Once Ace3 / Rock Stabilizes then your argument MUST be evaluated.
by providing compatibility layers between major libs .. it is an appeal to the masses.
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.
Fine picky, fixed. I still said static memory in the other topic.
While, it's probably technically true that you gain a little performance by adding a compatability layer so you don't have 2 majors running that are doing the same thing.
While we call it major/minors for the sake of simplicity, UberLibrary-1.0 and UberLibrary-2.0 are two entirely different libraries to the stub, we use the wording majors (<name>-<major:1.0/1.1/1.2/2.0/3.0/ect>) because it makes more sense then renaming UberLibrary to ZOMGHAILibrary when you want to bump the major.
For example, lets say I have Foo thats running UberLibrary-1.0 and Bar thats running UberLibrary-2.0 both using UberStub
UberLibrary-1.0 loads and registers itself with UberStub.
Foo loads and says "I want UberLibrary-1.0"
UberLibrary-2.0 loads and registers itself with UberStub
Bar loads and says "I want UberLibrary-2.0"
Even though both do the same thing, UberLibrary-2.0 contains changes that aren't backwards compatible with UberLibrary-1.0 this way with different majors Foo and Bar can run without any issues due to the incompatibilities.
UberLibrary-2.0 when it loads could go "No, UberStub, UberLibrary-1.0 is actually UberLibrary-2.0-Compat" and instead of the functions that Foo calls going to UberLibrary-1.0 they go to UberLibrary-2.0-Compat which then calls UberLibrary-2.0.
See? That ruins the entire idea of using majors and it's completely pointless, an author should setup there addon to include the library they need and so has no requirement for using a compatability layer. I haven't looked into how WAU does it, but I'd assume that it either downloads all the libraries as LoD, or it downloads all the libraries that the addon uses and names it by the major version.
Compatability layers are stupid, it's essentially a way to say "**** you" to the person who did the library that you made the layer for.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt's been two minutes, you lost your chance!
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."
Ok, as an author I bitched about having to upgrade but the reasons were compelling: compressed & thus smaller data sets, better organization etc. Therefore I chose to upgrade.
The new stuff was completely incompatible with the old: keys changed, data sets got moved around, merged split apart, dropped.
What would a CL layer have done? Well:
*It would have had to maintain a table translating the old keys to the new ones
*It would have had to add old comapatability sets for each set that got merged, dropped or split
*There would be this redundant code sitting there unused by any mod that did upgrade
*Time would be spent on CL & debugging the CL & debugging old crappy unupdated mods just because maybe the CL broke something
What happens in the long term? PeriodicTable-4.0:
*Needs a CL layer for the CL layer
*Needs CL for 3.0
*Needs double the implementation time because of all this completely uneccessary stuff
*More time debugging CL
PeriodicTable-5.0:
*CCCL
*Triple the imnplementation time
*Features dropped because the code is starting to become total crap & a nightmare to upgrade.
*Fulltime person now devoted to dealing with CCCL etc. ssues in old mods
PeriodicTable-6.0:
*CCCCL
*Never released for use as the CL stuff was too complicated for a human to upgrade within the lifespan of the universe
*Who cares about its features, nobody got it working.
Hopefully this clears up any confusion. If it does not, may I point out a real life example in Microsoft Vista? It took Microsoft over 10 years to give birth to Vista because they maintain backwards compatability all the way to the days of DOS or something sick like that. CL is crap & if u can avoid it you do so. In the case of libs simply using the old libs for lazy mods is all the CL we need which is: ZERO.
I suspect that there will never be a compat layer for PT, but it seems to make sense for me, Parser for example. VampircTouchFu needs Parser 1, and i think so do a few other mods, but then a bunch other need Parser 3 [now 4] If Parser 4 can provide the compat layer adequately, I rejoice, if it doesn't then yes Tek, its my own fault and I either need to bug CKK [in this case] or just load the old lib.
In fact I did this today when Crayon compat didn't work and broke 3 of my addons.
So I think we agree.
[btw i run gratuity as a standalone ;0]
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI believe that between Tek's diatribe on the matter and ToadKiller's blunt answer we've come to a conclusion?
don't add compat layers. now get ck to un do what he did :P
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.
If you consider the impact of each addon running standalone, running 3 frameworks is an improvement from this point of view. But I think some of your worries are non-issues.
The OnUpdate thing is one. A single OnUpdate manager in a library still has to call several OnUpdate functions for the several addons using it, which all use different code in their OnUpdate handler. I can't see this being any different than merely using multiple OnUpdates for each addon, and having the code split up. Hell, that might be slightly quicker even. All this does is lessen the amount of frames created for said processes and simplify the use of OnUpdate really.
Having multiple frameworks do the same code is really the same. Generally it's expected that each addon will do this work by itself anyway. And the libraries still in most cases have to split up the task to serve each addon. For instance, events. Normally addons could just run scripts by a frame and that's it. With a framework a check needs to be done on which events are registered and then each event is dispatched for each addon. If anything, that's more work than addons doing it independently.
Configuration managers are going to work the same way. Every addon still needs to register its configuration and have it handled so all you're losing is a couple frames that build the menu itself, which are a negligible loss.
So while there might be places a framework can help with speed by handling tasks in a single place, there are also parts where it could be slower. There isn't really any noticeable loss OR gain to using a framework, which is really what every developer is trying to tell you here: Stop caring about what framework your addons use and just use the addon; you don't need to know the framework exists and it makes no difference to you.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCompatibilty layers are part of having an existing codebase which you wish to support. They play important and useful roles in the long term.
For example, applications can often be ported to new environments, or integrated with other systems by replacing the libraries they use with "complatibilty layer" libraries which give the old code a new runtime execution environement. The reason for doing this is simple - you dont have to change the old code.
Also, running multiple versions of a library may not be realistic it depends on the library and what it does - you appear to be claiming it does not, and that they always can.
I don't think you have reached a conclusion of any sort - or that this thread has made any progress towards that end.
The closest parallel I can think of is MS - SideBySide execution (and virtualization/isolation). Embedded libs are a mixed up combination of staticly linked library concepts. However they lack the completeness the MS system ahas
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.
I've got a crap computer. Pure crap. That's a total understatement. It's a store-bought shelf computer that was lower mid-grade in late 2002 and isn't compatible with a lot of the newer technology today. I lag, and I lag badly. Even the slightest overuse of the CPU is noticeable to me at least a little.
Before the port to Rock I was running around 90% Ace2 addons and the rest were framework independent. I had a noticeable amount of lag, as I expect. After the port it just so happens that I also decided to throw in a couple addons to my package written on Dongle, so within a couple days I went from a single framework and some independent addons to 3 frameworks and several independent addons. Just as referance I run a very heavily modded UI. After the switch and addition to my UI, my memory went up by a light and totally negligible 1 MiB. That's it. And my lag? Well, it actually lessened noticeably, and I hadn't removed anything.
Running multiple things won't hurt, and there's real-world evidence of it. Multiple libraries merely give coders a chance to diversify their code a bit more, and as a result you will actually often see improvements when the coders make the decision to change.
Now as far as where this thread's gone on compat layers and all other stuff you guys are discussing, I really don't want to bother to comment right now. There are more than enough brilliant minds around this community that know their fair share of the subject to give you a great idea on it. But as far as the original issue in the post I don't think you need to worry.
Yes, I do. And having a compat layer is the closest I can get. Stop ruining my idealism!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou may not see the problem, but the parallels to MS, "dll hell", and their solutions to it are there - one would be wise to at least see the problems which they had, and what solutions they came up with.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorIt's fine to provide them as standalone versions or seperate librarys so those who run standalone (meaning those who should know what they are doing) can fetch the layer and redirect the calls from the old lib to the new one.
But besides that a new major version of a lib shouldn't mess with other major versions when it comes to calls.
More complicated things I'd probably push out into separate libraries, depending on how much extra code it is compared to the library. :)