moin moin,
On 2007-08-01 05:05:27, Hans-Christoph Steiner hans@eds.org appears to have written:
On Jul 31, 2007, at 4:21 PM, Bryan Jurish wrote:
also, i seem to recall hearing or reading recently something to the effect that "multiple-object libraries are deprecated" -- is there any knock-down drag-out argument why this should be so?
This has been discussed quite a bit on the lists and at the Pd Con 1. Here's the basic synopsis with the problems with the multi-class-single-file libs:
- no way to sort out name conflicts
- every object is loaded regardless of whether it's used.
- does not work with namespaces (i.e. [moocow/any2string])
(2) is certainly true. That's the whole point of multi-object libraries, isn't it? I think it can even be advantage, if a large shared codebase is used by multiple objects in a library (take gfsm as an example: a full static build takes almost 3 times the memory of a dynamic one: memory is cheap, but that's no excuse for inefficiency!)
Frankly, I just don't believe (1) or (3) is actually the case. I'll grant that multi-object libraries don't get you either (1) or (3) "for free" (as the filesystem does), i.e. without changes to the pd core, but they're most definitely solveable problems. (OK... I admit I don't really want to solve them either, but I'd prefer to hunker down on fixing the "real" problems than to see Pd go the way of java just because it seems like the path of least resistance)...
Plus once libdir format is more flushed out, there will also be embedded help, examples, etc. and a common library format regardless of which language the objects are written in (Pd, C, etc.)
This is all great, but I don't think any of it actually conflicts with multi-object libraries -- you'd just have a multilib as an external in its own directory: so what?
marmosets, Bryan