You know what, all along the hundreds of lines I've been reading in
the list about $0, I don't get a single consistent reason why it hasn't
the same behavior in object and message boxes.
Matteo Sisti Sette a écrit :
Mathieu Bouchard wrote
(and a few other people wrote something similar):
$0 in objectboxes is already inconsistent with $1,$2,$3,... in
objectboxes, so, it's not clear that $0 in messagebox has to be consistent
with anything at all.
$0 is inconsistent with $1, $2 etc strictly speaking, but you may think of
$0 as of an "implicit creation argument". The name $0 has the same scope of
the names $1,$2, in the sense that: in any two places where two $0's would
have the same value, two $1's would have the same value. Both are values
that are generated at the time of creating the object (semantically I mean,
I don't know if it is so in implementation and it is irrelevant) and don't
change later.
So it is not *so* inconsistent.
Making $0 mean in a message the same it means in an object box, would make
it *a lot* more inconsistent with $1,$2 in messages than $0 is with $1,$2 in
object boxes.
$1,$2... in messages are evaluated at the time the message box receives its
input and generates its output; they are arguments of the message it
receives. The "natural" object-counterpart of $0 would be a number that is
unique to that particular message event (not message box) or message tree,
though that would be of little or no use..... or wouldn't it?
Also, consider the following goal:
(*) give direct access to (implicit and explicit) creation arguments ($n) of
the patch within a message
Making $0 mean the same in a message box than outside it would address goal
(*) only for the particular case of $0 and not for n>0, and I personally
think this isn't an elegant approach.
Also, any future attempt to address (*) for n>0, would probably result more
difficult or have to be more inconsistend if the $0 case has been treated
this way.
I am personally strongly against implementing $0 in messages meaning the
same as $0 outside them. It would introduce further inconsistence. If there
actually is some inconsistence now, it is not a good reason imho to
deliberately introduce more inconsistence.
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6905&d=17-8
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
begin:vcard
fn:Patrice Colet
n:Colet;Patrice
adr;dom:;;;Nice;;06100
email;internet:[EMAIL PROTECTED]
tel;cell:06 32 66 03 57
x-mozilla-html:FALSE
version:2.1
end:vcard
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
