The key different between your Gem example and the GF vs. Pd [print]
is that you are talking about objects within the same library. The
[print] issue is about a library versus core. Overriding core objects
in a library seems like a bad idea, especially when its so simple to
call it something different.
.hc
On Jun 15, 2010, at 4:07 AM, IOhannes m zmoelnig wrote:
On 2010-06-12 01:23, Kim Cascone wrote:
IOhannes m zmölnig wrote:
most users should never notice (unless in a pleasant way).
if you instantiate a [print] object and don't know whether you are loading a buggy GridFlow [print]
object or a working Pd [print] object then how is this logical, clear or concise?most discussion here is very centered around the patching process. please don't forget about just loading a patch (and about using
premade abstractions for that matter).so if you load a patch with 87 [print]'s in there, what information do you get if Pd prints 86 times "dear user, you are using matju's
special [print], which has problems with parens". and how do you relate one of these warnings to a specific object? (luckily the warning mentions [print] in my example) and what happened to the 1 object that had no printout?and if it only should print once (as somebody suggested on the list): this should actually be done by Pd anyhow.
e.g. zexy comes with a version of "wrap" that is (imo) superior to the one that comes with Pd-vanilla. (and no, i will not remove "wrap" from zexy. it has been there for ages). whenever you load zexy's wrap
(which is normally simply done by loading "zexy", but in PdX it might be very complicated), then zexy will overwrite the built-in wrap by it's own. Pd will then print: "warning: class 'wrap' overwritten; old one renamed 'wrap_aliased'"so you have been warned.
most likely the same happens when you load gridflow (unless matju has done some weird hacking)
doesn't it make more sense to differentiate the two by calling one [gf_print] and the other [print]?
it would offload the task for correctly printing a message from Pd to the user. computers are mainly thought of as devices to offload tasks from the user rather than towards the user (though this often fails)
this way if I want to use a property of the GridFlow [print] object
for some reason I know I can call it using its namewhy would you?
why don't you think just fixing the obvious bug in GF's print won't
help you more?if you don't want to use GF's [print], then you probably don't want to use GF as well. in this case you probably don't want to load GF at
all, which will magically evaporate the problem.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.