Hello,
indeed, in message boxes, if the variable after the dollar sign doesn't
match a number corresponding to the number of arguments given at it's
input, it outputs directly the variable, if the variable is a number, it
ignores the dollarsign, if the number is greater than the number of
variables only, it outputs an error message.
It just doesn't make easy to find errors.
In object boxes such attempts would result into different error
messages like "$2: argument number out of range", or "$-1: bad type",
that might help for debugging a patch.
For me, dollar sign has exactly the same behavior in objects and
messages, it's just objects and messages that don't do the same things,
and I would think that $0 would decrease performances reached by message
boxes if it would have to give the patch ID instead of ignoring dollar
sign like it actually does.
marius schebella a écrit :
Hi,
the problem is, that $1 (and $<) has a different behaviour in objects
and in messages.
I think that was taken as reason, not to make $0 having the same
behaviour in messages, but giving it no behaviour at all and also no
alternative solution.
but maybe there is another motivation I have not taken into
consideration. and I am also not able to implement any of the discussed
possibilities. I am just trying to find a lobby for either solution.
marius
Patrice Colet wrote:
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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] 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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
