I think you're extrapolating from your particular use case.
I would say most people use $0 for private variables/resources. In this
case the very point is that those are not accessible from outside. If I
do want to make things accessible from the outside, I wouldn't use $0 in
the first place...
On 02.12.2021 14:25, Antoine Rousseau wrote:
Without the "$$" syntax, I wouldn't see the problem...
encouraging the use of $0 in messages, without allowing to easily
substitute with [another way to identify the abstraction] $1?..
Le jeu. 2 déc. 2021 à 13:18, Christof Ressi <[email protected]> a
écrit :
So I think it's better to keep the $0/$n symmetry.
I think having a "message" object is a better idea [than $$'s
one]
What I like with the $$ idea, is that it would provide a simple
way to merge creation arguments with variable arguments, i.e
compose a message with both the abstraction arguments and the
incoming message elements.
I have to say I quite like the "$$" idea as well, assuming that we
can take the risk of breaking a few patches (if any).
I don't think it's a good idea to add a new object just for this
functionality. For me this would create unnecessary complexity
(you have to learn yet another object).
I'm not sure either. To me, both $0 and $1 etc. can be used to
identify an instance of an abstraction.
IMO $0 is the quick way, but has the limitation to make it
(nearly) impossible to access members from the outside.
That's why it often happened to me to rename an instance [myAbs]
to e.g [myAbs myabs1], then to replace $0 in [myAbs] with $1, so
I can easily access [myAbs]'s members from the parent - from
anywhere in fact (Actually, nowadays I tend to use as few $0 as
possible).
If we could use $0 in messages, then the last operation would be
more complicated (cause you couldn't simply substitute $0 with
e.g $1).
I agree that if we get the "$$" syntax, then it makes more sense
to use "$$0" for the $0 argument! Without the "$$" syntax, I
wouldn't see the problem...
One downside of using "$$0" is that it wouldn't be compatible with
Pd-L2Ork / PurrData.If they have already diverged significantly,
we probably don't have to care, but otherwise...
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
