[PD] Abstractions search path hirarchy (was: pduino-arduino trouble)

[Mathieu Bouchard]

On Wed, 18 Jun 2008, Hans-Christoph Steiner wrote:
> On Jun 18, 2008, at 7:54 PM, Mathieu Bouchard wrote:
>> On Wed, 18 Jun 2008, Hans-Christoph Steiner wrote:
>>>> and then class-lookup is method-lookup in pd, because it's done through 
>>>> [objectmaker]'s method-list.
>>> Do you have a reference in the Pd code to look at this specific stuff?
>> grep -n objectmaker *.c
> That I can do on my own, I was hoping for some human guidance... :)

Well, I didn't think that I'd have to say to have a look at 
class_addmethod, because we're talking about adding a method to a class.

Anyway, the thing doesn't use linked-lists, contrary to almost all other 
such things in pd, so I was wrong. However, it is true that it appends to 
the end of the list all of the time. It happens just after the 
t_resizebytes call. Personally, I wouldn't touch it, and instead I would 
change the method-lookup order in getfn(), zgetfn() and pd_typedmess().
Then I realise that it is already last-to-first, which is my second 
mistake. I don't know why I had the impression that it was first-to-last. 
On top of that, it's an aspect of pd for which dd is identical. So, I 
should've remembered. You can see that I'm getting a bit rusty ;)

>>> Ultimately, for the canvas-local namespaces to be complete, there needs to 
>>> be a canvas-local method list too.
>> I explained it in detail last year. Got no reply.
> Link?

Ok, I found it, but in the end, it wasn't a full description, and it 
wasn't last year either. Turns out that I optimised-out the description 
from the mailing-list, as the description was going to be a reply to a 
reply that I did not receive.

   http://lists.puredata.info/pipermail/pd-dev/2006-09/007605.html
   http://lists.puredata.info/pipermail/pd-dev/2006-09/007607.html
   http://lists.puredata.info/pipermail/pd-dev/2006-09/007608.html

But basically, the idea is that you have a tree of dummy singleton objects 
that are the objectmakers. They are singleton because each of them has its 
own class. They are dummy because the object itself is never used and 
itself contains no data (this exists because pd has no way to define 
non-object methods, and that's fine with me). Each objectmaker class 
defines the creators as methods: one per class, one per alias, and one per 
sub-namespace. Creators for classes and aliases are as usual. Creators for 
sub-namespaces are forwarders. They replace the selector from the message 
they get, with the $1 of the arglist. $1 is removed from the arglist. So:

   [foo bar baz 1 2 3]

Might be a real creator for [baz 1 2 3] inside namespace representative 
[bar] inside namespace representative [foo]. Or it could be something 
else with less namespace levels and more arguments. If the ambiguïty of it 
icks you, there are other possibilities of design.

Then if you don't want to use Miller namespaces such as in [list ...] 
classes, then you will have to check for namespace qualifiers in the 
classname and split the classname accordingly, sort of like [OSCroute] but 
not really. I used Miller namespaces because it makes less symbols in the 
symbol-table.

I have other ideas as well, such as how to import a namespace without 
copying the method-table, and how to support a namespace that is being 
modified so that all its importing namespaces get the update. It's the 
same solution(s) for both problems.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec