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

[Hans-Christoph Steiner]

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