On Feb 16, 2009, at 5:52 PM, Roman Haefeli wrote: > On Mon, 2009-02-16 at 22:58 +0100, Frank Barknecht wrote: >> Hallo, >> Matt Barber hat gesagt: // Matt Barber wrote: >> >>> At least we know it was an intentional difference: >>> >>> http://lists.puredata.info/pipermail/pd-list/2008-04/061603.html >>> >>> For extended would it be possible to exclude cyclone pow~ from the >>> library, or less drastically patch both cyclone and vanilla pow~ to >>> throw a warning, as was discussed last april? >> >> This is not related to Pd-extended which AFAIK doesn't include >> cyclone >> as a library (a "-lib" loadable one), but when loaded as a lib, >> Cyclone >> does some magic to even overwrite Pd internals. I made a little check >> now and actually Cyclone then is very smart and aliasses the >> builtins to >> different names. >> >> Running "pd-0.42 -lib cyclone" gives this: >> >> ... >> warning: class 'pow~' overwritten; old one renamed 'pow~_aliased' >> ... >> >> and now the [pow~] behaves like in Max, while [pow~_aliased] is the >> new >> pow~ from 0.42. That's pretty cool, actually. > > from what i have understood, it is not cyclone's ability to replace > built-ins, but it is a so called new feature of pd 0.42. the same > happens also with zexy's [pack] and [unpack] and many others. > > why is that so cool? i personally find it _very much_ confusing, that > you cannot be sure anymore to use only pd-vanilla classes, when > libraries are loaded. this new feature makes it impossible to stick > with > only-vanilla classes in one patch, where another one in the same > instance of pd loads some libs. for me, the vanilla classes were some > last 'safe' ressort, which is now polluted and messy, and i have to > rely > on thirdparty authors, and i need to trust them, that they write their > externals compatible to the internals, so that my patches don't break. > shouldn't the core library considered to be holy and untouchable, at > least this one? > > then again, as you say, this new features introduces _another_ > difference between pd-extended and vanilla: overriding internal > classes > works only with libs and not with single-class-per-file collections. > > why keeping backwards compabitility (which is the mentioned reason, > why > this new feature was introduced) on _any_ cost, even on cost of > breaking > patches and introducing new incompatibilities? > > i am confused / confused / confused..... > > roman
I think Roman is illustrating the dangers of this overriding approach very well. I think that this also highlights the advantages of making the vanilla internals into a distinct library and having the library configuration as part of the patch. Then you can specify [import vanilla] and you will be sure that your [pow~] will be the vanilla pow~ regardless of the user's local setup. That means that your patch is much more likely to run on many more machines. .hc ---------------------------------------------------------------------------- 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
