🚀 go-pugleaf

Stephen Burke writes:
>TMOTA writes:
>> They do. But imagine having a library of SOURCE code. Imagine saying "I
> 
> The source code is obviously very desirable, it's just that commercial
> companies are understandably reluctant to release it (as are many PD authors).

Hmm.  The whole point is that I'm having to do this, so I may as well give
others the benifit.  I don't expect financial return (although I will retain
rights to stop other people ripping me off).

I imagine that the author of DeskLib has a similar disposition.  So in this
respect, the 'PD' (although of course it's not PD) authors *aren't* at all
reluctant to release the source code.

>> Yes. Annoying, isn't it? And the trouble is that the more the library
>> does for you automatically the more interlocked it gets. To de-interlock
>> the code fragments, you need to drop to a slightly lower level, where the
> 
> I'm not sure that this is necessarily true, it's just harder work for the
> people who write the library. My understanding of the object-oriented
> philosophy (which I admit is very limited) is that it facilitates exactly
> this "de-interlocking" of relatively high-level constructs.

No - object-oriented doen't facilitate de-interlocking; in fact, it
encourages it.  Have a look at the object hierarchy of Smalltalk (or for
that matter, Oberon) sometime.  It's huge!

The interlocking aspect to me, however, is neither here nor there.  Inter-
locking is simply the result of modular designs, and if done properly,
shouldn't cause problems.

The problem with the object-oriented philosophy at the moment, however, is
that C is not object oriented, and doesn't support that kind of design very
well.  In particular, I am having great difficulty with three areas:
constructors (or automatic module initialisation), exception handling, and
naming.  All of these I have work arounds for, although the first problem
is the worst, which is why I will be phasing out the use of main().

>> No, but then again, the windowmanager is in ROM, so it doesn't cost
> 
> Well, there's no reason why RISCOSlib couldn't be in ROM either (or loaded
> as a shared module in RAM). In fact, as I understand it the mechanics of
> making a shared library aren't all that complicated. How about Acorn, or
> failing that some PD person, making a tool to let any library be made into
> a shared module? I can't see it being any more complicated than, say, cmhg.
> Would some Acorn person be prepared to tell us how it's done?

In fact, it could be done a damned sight better than Acorn have done it,
without having to upgrade the OS.  A simple module would do it.  The module
would be responsible for:
  * loading libraries.
  * handling instantiations (when the number of users drops to zero, the
    module can be unloaded)
  * providing the interface between the library, and the application.
  * back-patching (a newer version of the library is loaded while an older
    version is in use).

Not hard at all.  The problem is the amount of time it would take.  I might
look at it.

>> any generic library) it is impossible to supply *just* the needed code
>> without adding any 'unused' or 'unnecessary' code into the bargain.
> 
> This is true, but it depends how much you care. If a 40 Kb program gets
> blown up to 80 Kb I think that's not very serious, especially if it lets
> you write the code in half the time.

Exactly.  I don't care about code-size or even speed very much.  I do care
about development time: this is the most expensive part.  Once an application
has been developed, it can be optimised.  It's stupid to optimise *before*
the application is developed (which is what I think TMOTA is trying to do).

>> library upon the small, useful, stand-alone functions that are handy, rather
>> than an all-singing, all-dancing organism.
> 
> The trouble is that small functions are, by definition, the ones that are
> easier to write yourself anyway.

It's even worse than that!  If you're given a whole heap of little stand-
alone functions, how much of the functionality within them is duplicated
somewhere to make them stand-alone?  And imagine the number of items you
would have to wade through each time you wanted a routine?

This is the advantage of a good modular design - not only does it *avoid*
duplication, but it also provides a method of categorising the functions.

> I would personally like a library which can,
> say, take a draw file and display it in some standard way on the screen with
> essentially a single call.

That;s the sort of thing I had in mind.  Along with 'give me a text editor'
type of functionality.

> Of course, I'd also like to be able to "tweak" it to
> do things slightly differently without having to re-write the whole thing.

Source code provided.

> To take another example, I like the fact that RISCOSlib provides a simple
> way of dealing with the load/save protocols (which is not to say that it
> couldn't be improved). I've also coded these directly in Basic, and it took
> a lot of effort to get it to work.

Yes.  Again, stress resueability -- this is the whole purpose behind what I
want, and if I have to write it, then I guess I may as well give others the
benifit of what I develop...

Anyway, I have some of it almost ready to put together.  In particular, I
have some of the really base stuff done (simple types like integer, cardinal,
logical, character, string, and any associated methods), I've got the message
engine done (used for reporting errors only as yet -- will be expanded!), and
the exception handling done.  I'll try and put the pieces together over the
next two weeks, and let people comment.

								Ug!