--- On Thu, 12/16/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] L2Ork Pd update now available To: "Roman Haefeli" reduzent@gmail.com Cc: pd-list@iem.at Date: Thursday, December 16, 2010, 4:00 PM 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.
It's also a matter of the developer writing a script to find all cases of the aliases in the current documentation and change the ones that have the deprecated name-- and if you're keeping the long name and discarding the short, to actually open each modified patch and make sure the new name doesn't collide with, say, a comment, or another object. But most importantly, making sure any externals that are abstractions have the correct name in their guts (which, if not correct, will adversely affect the mood of a user who just went to the trouble of making/running a script to use this flavor of Pd).
-Jonathan
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...
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list