[A83] Re: libraries
[Prev][Next][Index][Thread]
[A83] Re: libraries
> Well, as I mentioned, I was thinking of creating a widget set library.
> By providing such a library, applications could just say: I want to have
> a text box control here on the screen and a button there. The library
> would take care of reading user input, and notifying the application if
> the button would be pressed. Though this isn't really that useful for
> games, I believe this might make programming other applications much
> easier.
If you want to write something specific purpose like a windowing system,
then yeah, it could be useful. But I wouldn't expect many, if any, people
to take advantage of it. Though it could save you some space if you are
writing multiple apps with it. General purpose libraries do not work.
> One advantage when compared to static linking of a library (e.g.
> embedded in the application) is that dynamic libraries can be easily
> upgraded if a bug is found in the library: just replace the library, and
> all applications using it will no longer suffer from the bug.
This is a calculator. That won't happen. And with things this simple, any
"bugs" in a library are more than likely not going to affect an application.
In fact, programs will more than likely break if the bug is fixed. You
would expect most anything to be caught in testing of the individual app.
This isn't Posix, where functions do different things under different
conditions, and have a variety of effects.
> And they (potentially) save you space. Especially when you create
> libraries that only contain functions for one specific purpose, the
> overhead generated by infrequently called functions is minimal.
Potentially being key here. Applications don't use them. Anything general
enough to be useful is in the ROM. Everything else is too specific.
Libraries have been tried several times. It has never worked, and more than
likely never will work. Take several programs written by different people,
and see if you can abstract parts of them out to a shared library. If you
can do this and have it be worthwhile, I would be very surprised. You would
gain a lot more by implementing a general compression system, like the one
for the 86. Oh wait, the 83 doesn't have enough RAM... (gee, let's add all
this flash space and no ram, that's a real great idea...and then kill off
the 86 because it shows how much the 83 sucks)
> I agree with you about the dependency problem, but I think it is
> solvable by storing the dependency information (e.g. which version of
> which library an app requires) directly into the app. One might even
> create a program which automagically transfers the app itself and all of
> its dependencies to another calc, or from pc to calc.
Dependency problem? Versions? What are you talking about? Stop the
insanity! This is a calculator, and one with hardly any RAM. I think Kirk
Meyer wrote a program for the PC to show which libraries an 89 app requires.
Fortunately most authors included the libraries they used with their
program. It was usually fine for the real calc if you used it a lot and had
everything on it, since you'd already have the libraries, but if you just
wanted to try a program in VTI, it would suck. If you think that you would
have version dependency problems with libraries, then you really, really
need to rethink the idea.
In any system, libraries shouldn't have version dependency problems. Why
does Red Hat and all distributions based on it sucks? Because RPM sucks.
Why does RPM suck? "Dependency hell". Why do you see different RPM's for
different versions of Red Hat? One package should work for virtually all
Linux distributions. It's the same vendor, and you need different packages
for different releases! When you change a libraries' interface, you rename
it. Simple as that. Debian understands this. Red Hat does not.
Sorry, little rant about Red Hat there. But anyway, point to remember is
that you shouldn't need to track versions of things. If you change an
interface, rename it, so both versions can exist on a system, keeping
existing applications from breaking.
References: