[PD-dev] bind abstraction-canvas to full classname

[B. Bogart]

Hmmm,

I've tended to create dynamic arrays of abstractions using [constructor]
which used to be part of pmpd...

Anyhow each abstraction gets an instance # when its being generated, and
then I have a

[r local]
  |
[route $1]
  |      |
local   global


So that each abstraction only responds to messages with its ID prepended.

I never used namecanvas...

,b,

IOhannes m zmoelnig wrote:
> Mathieu Bouchard wrote:
>
>> On Sat, 14 Jan 2006, IOhannes m zmoelnig wrote:
>>
>>
>>> abstractions require the .pd extension. with the 2nd patch i submitted a
>>> ".pd" is appended to the canvas-receiver of an _abstraction_. the "new"
>>> (currently: additional, but see the other mails on this topic)
>>> canvas-receiver consists of the classname (== relative-pathname +
>>> filename). there is no check whether the classname (how you call the
>>> object) contains a relative (or even absolute) pathname.
>>
>>
>>
>> What's the use of being able to contact one (and only one) instance of
>> an abstraction via a receive-symbol?
>
>
> do i guess this is a rhetoric question?
> btw, my patch does not contact one (and only one) _instance_ of an
> abstraction, but _all_ instances.
>
>>
>> How do I know which instance I am contacting?
>
>
> you don't.
> that is the nature of send. you do not know who is listening.
> (but of course you know that)
>
>>
>> And then, why is [namecanvas] marked as obsolete?
>
>
> well, i keep asking this question since several years. (since i first
> discovered that [namecanvas] is marked obsolete.
>
>
> mfg.asdr.
> IOhannes
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20060114/702e05a9/attachment.pgp>