Roman Haefeli wrote:
hi all, hi IOhannes
after having installed pd 0.42.0test5, i assumed to have discovered a behaviour change of [unpack] and [pack], until i noticed:
a) zexy comes with its own version of [pack] and [unpack]. why are they called the same? i really don't get that.
because they are meant as a better (but obviously buggy) replacement of pack.
b) in pd 0.42.0test5 they seem to override the built-in classes. is this a bug? if yes, pd's or zexy's?
it's a feature of Pd.
c) the zexy versions can explicitly be called by using the 'zexy/' prefix. how is that possible, although zexy was compiled as multi class library? is that _the_ solution to have multiclass libs and separate namespaces at the same time?
this is because zexy's [pack] explicitely asks to be named [zexy/pack].
the reason for this is, that i wanted to make explicit that this is not the built-in pack. so people could basically chose which flavour they wanted. the other reason is of course, that prior to 0.42, there was no way to overwrite a built-in, so i had to come up with a different name (and [zexy/pack] was somehow more appealing than anything else).
now all of this would not be a problem, if my object's "primary" name would not be "pack" - which it is in order to express the intention of this object. it was a safe thing to do in the olde days :-) (and it would be even less a problem if it behaved comaptible with the original [pack])
i will fix the name-clash asap.
the more interesting thing would be an idea to make zexy's pack really compatible with the built-in version. the best thing i can currently come up with is to make zexy's pack interprete its arguments differently. e.g. [zexy/pack f s] would output [list f s( and zexy's [pack f s] would output [list 0 symbol( but still would output [list s 0( when somebody would send a [list s 0( _into_ this object.
fmga.fdas IOhannes