Oh, cool, yeah, that is a nice design, I see it now. 

but anyways, I still see $0 as locality and the rest as inheritance, as you are just still making a child inherit (by $1) a parent's local $0 ID.

> I personally love the idea of using $0 as the selector 
> of the abstraction -- its name or filename, and $$ as 
> its ID, but too late for that now.

now that wasn't clear for me, but if we keep on it I suggest we might need to change the thread name maybe.

I hope this thread would stick to the point that the find feature could do a better job by finding "$0", and that "$0" could be used in messages since it is useless the way it is.

thanks
alex


On Fri, Nov 13, 2009 at 6:27 PM, Matt Barber <brbrofsvl@gmail.com> wrote:
I am saying two things:

1) Without $0 or something similar, the only way to guarantee similar
locality would be through use of $1 or $n -- you would have to
manually give each instance an instance number.  Sometimes you even
want to be able to group instances in the way you suggested.  I'm not
sure of the history of Pd, but if $0 was implemented after
abstractions with arguments, then manually assigning locality was
probably necessary.

2) Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by
various helper abstractions within a larger, higher-functioning
abstraction.  This is especially the case with dynamic patching --
imagine, say, a "bell synthesis" patch using a dynamically created
bank of enveloped oscillator abstractions.  In that case, you'd want
each oscillator abstraction to [throw~] to the same [catch~] within
the parent "instrument" abstraction.  To do this, you could have
[catch~ $0-out] within the parent, and [throw $1-out] within each
child, while passing the parent's $0 to the children.

So all I'm saying is that $1-$n often plays a really important role in
locality, in addition to a number of other things, and to me it seems
almost natural to use $0 as an analogy for this role.  I personally
love the idea of using $0 as the selector of the abstraction -- its
name or filename, and $$ as its ID, but too late for that now.

Matt

On Fri, Nov 13, 2009 at 3:01 PM, Alexandre Porres <porres@gmail.com> wrote:
> hmm, I am sorry, I don't think I got what you meant... could you give an
> example please?
> The way I see is that $1...$n are related to the inheritance concept. They
> could be used inside [send~] & [receive~] objects to force some sort of
> locality, but you can't really guarantee locality by that, it is just some
> way around that is not 100% safe, cause if you have [s $1-gain] in an
> abstraction, and $1 inheriting "A" for instance, a [s A-gain] object in a
> parent patch (or even on another opened patch) would still get the value
> globally.
> cheers
> alex
>
> On Fri, Nov 13, 2009 at 5:28 PM, Matt Barber <brbrofsvl@gmail.com> wrote:
>>
>> Without $0, one would have to use $1 ... $n for locality.  $0 of a
>> parent patch often needs to be passed as $1 to a child for proper
>> locality, for instance, so I don't think they are necessarily THAT
>> different conceptually.
>>
>> Matt
>>
>> On Fri, Nov 13, 2009 at 11:49 AM, Alexandre Porres <porres@gmail.com>
>> wrote:
>> >> Calling this an exception creates
>> >> the impression, that $1 in a message
>> >> is the same as in an object.
>> > Hmm, I see you have a point! But I am just used to consider "$0" and
>> > "$1, $2
>> > ... $n" different/separate things, being "$0" solely a locality sintax.
>> > Putting them as separate concepts I see "$1, $2 ... $n" as two different
>> > things wether in messages or objects, and that "$0" is just useless in
>> > messages.
>> > Anyway, I am cool with what needs to be done in order to put "$0" in
>> > messages, I still think it's a bit of an unnecessary hassle, but it
>> > ain't
>> > that much of a big deal after all.
>> > The thing that had no other way around was using the Find feature to
>> > actually find them, so I thought about bringing this all up: the
>> > hassle and
>> > the problem.
>> > I now see that uncheking "whole word" in the new version is just another
>> > "way around" rather than actually getting the Find feature to look for
>> > "$0",
>> > or even for the window number once we explicitly tell it which one it
>> > is.
>> > So, nerverminding about "$0" in messages, I would still make a point
>> > here
>> > for the Find feature to be able to find "$0", I hope it isn't much
>> > hassle
>> > getting it to do so.
>> > Thanks a bunch folks!
>> > Cheers
>> > alex
>> >
>> > On Fri, Nov 13, 2009 at 8:03 AM, Roman Haefeli <reduzierer@yahoo.de>
>> > wrote:
>> >>
>> >>
>> >>
>> >> Am 12.11.09 17:21 schrieb "Alexandre Porres" unter <porres@gmail.com>:
>> >>
>> >> > But I totally disagree, I have been teaching a lot basic Pd around,
>> >> > and
>> >> > people
>> >> > always get confused and think they can just throw "$0" in messages.
>> >> > So I
>> >> > have
>> >> > to state and reinforce that there is an exception that it doesn't
>> >> > work
>> >> > on
>> >> > messages.
>> >>
>> >> Calling this an exception creates the impression, that $1 in a message
>> >> is the same as in an object.
>> >>
>> >> > Without an exception at all, it should be easier to get it, as I
>> >> > understand.
>> >>
>> >> Agreed. But currently, the only thing that makes $0 in a message
>> >> exceptional
>> >> is the fact, that it has no meaning at all. Making it be replaced by
>> >> the
>> >> canvas identifier wouldn't make it less exceptional at all.
>> >>
>> >> roman
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ___________________________________________________________
>> >> Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo!
>> >> Mail:
>> >> http://mail.yahoo.de
>> >
>> >
>
>