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