--- On Thu, 12/16/10, Ivica Ico Bukvic <i...@vt.edu> wrote:
> From: Ivica Ico Bukvic <i...@vt.edu> > Subject: Re: [PD] L2Ork Pd update now available > To: "Roman Haefeli" <reduz...@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 > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list