[PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

[Roman Haefeli]

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







	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de