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.
Hi,
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.