On Thu, 2010-12-16 at 14:04 +0100, Roman Haefeli wrote:
On Wed, 2010-12-15 at 23:41 -0500, Ivica Ico Bukvic wrote:
AFAIK, a2l can be replaced by the vanilla [list].
Then I agree with your decision to drop aliases altogether.
To me this discussion sounds like: "Aliases are hard to implement when using the libdir format (which was not intended by original author anyway), so let's drop them". IMHO, that's a weak base for such a decision.
Actually, they are not hard at all. I already tried building the whole thing with aliases and it boils down to changing a few lines in the installer. That said, I've reverted it back as I philosophically agree with Hans. There is no reason for those aliases to exist other than backward compatibility. Then again, it is exactly this kind of backward compatibility (imho) that has been keeping Pd from evolving faster. At some point one simply has to leave some things behind to be able to move forward faster. And these aliases are such an easy fix that even in the context of backwards-compatibility it is a matter of a simple script updating your old patches and replacing object aliases with the original ones.
Perhaps all libs should be looked over for redundant copies and only the most stable/polished iterations should be left in the final build.
I agree, but I guess it's not that simple. How can one decide which classes are 'valuable' enough to keep and which aren't? There's much personal taste involved. Personally, I tend to be as restrictive as possible and I rather use [list prepend bla]-[list trim] instead of [whateverlib/prepend bla], although the vanilla-only approach requires two objects for what could be done with only one object when using an external. And still, if the decision is to include an external, which one of several flavours? It's not only about stability and cleanness, if all flavours are stable, but work slightly different from each other.
Also, it's problematic to include modified libraries while keeping their original name. It would make the portability of patches much more complex, more complex than it is now. A patch using zexy in Pd-extended wouldn't necessarily work in Pd-l2ork. Stating that the patch is dependent on the zexy library would not be sufficient info to ensure that it works where zexy is installed.
I tend to think, that the best option would be a transition to a reorganized library library, which uses names not based on authors but on functionality. New patches could use the new, clean and stable libraries, while old ones would still work with old (current) libraries. Such a transition would allow to drop aliases, to drop superfluous object classes, and to create libraries with meaningful names.
Good points. Time permitting, I may put this on my todo list...