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

João Pais jmmmpais at googlemail.com
Sun Feb 22 23:57:37 CET 2009

>> > i think, that the question, why a new object [pack] is named pack is  
>> not
>> > rhetoric at all and isn't answered yet. so lets go again: why is  
>> [pack]
>> > from zexy called [pack]?
>> apart from the specifics of [pack]:
>> if a language allows the overriding of built-in methods, then i do not
>> see why a social codex (which is what you are asking for, right?) should
>> forbid it.
>> especially, if a language introduces ways to override built-in methods
>> after years of existance,  it actually encourages the overriding of
>> built-in methods.
> yo.. your point is perfectly valid. call me stubborn, but i still don't
> see the goal of:
> a) allowing to override internals
> b) actually using that feature
> but you are right: there is no reason, that should discourage you from
> using the new feature.


if the purpose of [zexy/pack] was to override van-[pack], why not send the  
code to Miller and pack it with vanilla right away? why put it in another  
place, where it could be unadvertedly (mis)used by someone? for example,  
if I'm using [pack], I expect an error on the console in case I send a  
wrong list. if my patch starts with zexy's [pack] (I have zexy on my path,  
of course), I won't be in control of what's happening. you can reply "you  
will notice the mistake at another point", and it should be true - but  
only after I come to the conclusion that the wrong [pack] was being used.

the example given by pack can be taken by any other external, of course.  
although this is a kind of "name-usurpation" exception, other  
name-clashing externals aren't as much in sync as [pack] and [zexy/pack] -  
like Gem's counter and other counters, for example.

>> i guess miller has spent countless of sleepless hours thinking and
>> rethinking how to do this best, so we probably should adapt to it.
> whatever conclusion miller came to, i didn't get it.

I also don't understand what you meant, maybe we should ask him?
and about pd-van's new opcodes, I would say that Miller is another  
developer like everyone else involved - and priorities are set by whoever  
gets firstly served (unless a gentleman's agreement is reached?). when he  
(or anyone) adds new externals, he (or anyone) should check if they're  
nameclashing from the pd-extended official release. I don't say to check  
with whatever externals or abstractions anyone has stacked somewhere in  
their computer, but to check with the other official bundle of pd,  
pd-extended. and that's not a laborious task at all, I think.

More information about the Pd-dev mailing list