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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
