What about for instance arrays that
should maintain scope inside a specific
abstraction so that you can have multiple
independent abstractions? $0 is very useful IMHO
and is also necessary to stay due to backwards
compatibility concerns. Therefore, I think the
discussion should be limited to a simple yes or no
for $0 substitution inside a message as it does
not introduce a myriad of other questions.
Having message recognize it as such
(the code already seeks to resolve dollarzero but
fails because the canvas was not set as current
which should be a simple addition of a couple of
lines of code) makes sense even if the only
benefit is not having to do [$0] or what you are
suggesting, namely [zerofy-me]. It is also worth
noting that there is no reason why the two could
not coexist.
Yet, as it stands right now, $0,
contrary to what has been already said in both
threads on this topic, is an anomaly inside a
message box and behaves like nothing else anywhere
else in the code and as such this should be a
no-brainer fix, just like having a trigger with
static values, like [t 0 f 1] for opening a gate,
passing a value, and then immediately closing it.
This is what pd-l2ork does (and so does Max). So,
rather than putting redundant messages with static
values below the [t b] outlet, one object solves
it all. To me this is the same situation where
message can do it all, and if that makes my
patching quicker, I am all for it.
On Sep 10,
2014 12:48 PM, "Jonathan Wilkes" <
jancsika@yahoo.com>
wrote:
Two
things:
1)
the lack of "$0" in messages is only a
symptom of a bigger problem with scope
of binding symbols in Pd. I'd rather
see new objects (or wrapper objects)
that handle scope in a sensible manner
which doesn't require typing "$0-" at
all. There's already no need for $0
in your preset_hub/node design. Why
not extend the hub/node idea and get
rid of the need for $0 completely?
[hub]/[node]
= [send]/[receive]
[hub~]/[node~]
= [throw~]/[catch~]
etc.
2)
On a more superficial note, isn't the
problem that Pd doesn't store stray "\n"
characters in message boxes? The only
time I can think of when one would have
a real desire for $0 in a message box is
when initializing a bunch of receivers:
[;
$0-foo 1;
$0-bar
2;
$0-flub
3;(
But
if the box stored "\n" you could get the
same clean format with commas:
[foo
1,
bar
2,
flub
3(
|
[zerofy-me]
<- add a "$0-" to the selector
|
|
[send]
No
ugly zeros, no leading semi-colon,
everybody wins!
-Jonathan
On Wednesday, September 10, 2014
2:27 AM, Ivica Bukvic <ico@vt.edu>
wrote:
On Sep 10, 2014 1:17 AM,
"Chris McCormick" <
chris@mccormick.cx>
wrote:
>
> Hi Ivica,
>
> On 10/09/14 04:19,
Ivica Ico Bukvic wrote:
> > Yet, I wonder why
message shouldn't be able to
pre-parse $0 into a valid
> > dollarzero (canvas
instance), when there will
never be a message one
> >
> > Thoughts?
>
> There has been a lot of
discussion regarding this
over the years which
> might be good to read
to get an idea on the
different
> philosophical/language
design issues:
>
> <
http://comments.gmane.org/gmane.comp.multimedia.puredata.general/56365>
Thanks, Chris,
for bringing this to my
attention. Since one of
Miller's core ideas behind
pd is absolute backwards
compatibility, most of
alternatives suggested in
that thread would cause
unacceptable breakage with
backwards compatibility or a
really kludge workaround for
the support of legacy
patches. It seems to me Phil
really has a point I
completely agree with. FWIW,
I am looking to implement
this in pd-l2ork and as soon
as I get a better idea about
the recursion Miller
mentioned and how to
circumvent it, it should
find its way into pd-l2ork's
source.
Best,