Hi IOhannes, list,
Can you tell me if there is any policy about zexy aliasing internal objects? Mainly I want to know if it is your intention to maintain compatibility between builtins and zexy objects with the same name.
Thanks,
Jamie
If you use Pd-extended, then you can use the namespace prefixes, i.e. zexy/pack, and used any zexy object on any platform without conflicts with the objects included in Pd vanilla.
.hc
On Mon, 2011-09-19 at 12:00 +0100, Jamie Bullock wrote:
Hi IOhannes, list,
Can you tell me if there is any policy about zexy aliasing internal objects? Mainly I want to know if it is your intention to maintain compatibility between builtins and zexy objects with the same name.
Thanks,
Jamie
-- http://www.jamiebullock.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-09-19 13:00, Jamie Bullock wrote:
Hi IOhannes, list,
Can you tell me if there is any policy about zexy aliasing internal objects? Mainly I want to know if it is your intention to maintain compatibility between builtins and zexy objects with the same name.
there are 2 cases here:
[unpack]; the policy is, that they ought to be compatible, but enhanced versions of the original objects. since in fact they are not, the shadowing of the built-in objects is currently disabled, and you can only access these objects via [zexy/pack] resp [zexy/unpack])
[wrap] come to my mind); the policy here is, to keep the old zexy behaviour as long as this "enhances" (aka "adds to") the original behaviour. if the internal object had an added feature, i would most likely add this feature to the zey object (though this never happened, afair). if the internal object breaks compatibility, i will most likely keep the original zexy behaviour (unless the break is indeed a bugfix); afair, this has not happened so far.
fgmasdr IOhannes