[PD-dev] info classes
Jonathan Wilkes
jancsika at yahoo.com
Tue Mar 5 00:35:15 CET 2013
Ok, I've got some working code for building a simple linked list
of classes and a function to return a class by symbol. This should
be fun.
Should I go ahead and make some convenience functions for
accessing class members? That way anyone who wants to
use this functionality can get info on a class without worrying
about being locked in to the class struct if it happens to change.
-Jonathan
----- Original Message -----
> From: Jonathan Wilkes <jancsika at yahoo.com>
> To: Jonathan Wilkes <jancsika at yahoo.com>; "pd-dev at iem.at" <pd-dev at iem.at>
> Cc:
> Sent: Saturday, March 2, 2013 3:45 PM
> Subject: Re: [PD-dev] info classes
>
> ----- Original Message -----
>
>> From: Jonathan Wilkes <jancsika at yahoo.com>
>> To: Jonathan Wilkes <jancsika at yahoo.com>; "pd-dev at iem.at"
> <pd-dev at iem.at>
>> Cc:
>> Sent: Friday, March 1, 2013 1:27 PM
>> Subject: Re: [PD-dev] info classes
>>
>> Just made a change so that the "args" method grabs from
>> the parent instead of the root canvas.
>
> After some more testing I think this change is wrong. If [my_abstraction]'s
> args are "foo bar" and I'm inside subpatch [pd blah], the tk
> window for [pd blah]
> shows the args as "(foo bar)" and not "(blah)". But this is
> just an effect
> of the larger point, which is that the _abstraction_ arguments are the ones
> that replace dollarsign variables regardless of which subpatch you happen to
> be in. So the "args" method to [canvasinfo] should return the atoms
> that will
> replace $1, $2, $3, etc. in the context of the current canvas. Even for nested
> subpatches, that means the arguments for the root canvas (i.e., containing
> abstraction, or if there's no abstraction then the toplevel patch), so those
> are
> the ones that will be returned. That makes the canvasinfo "args"
> method
> consistent with the rest of the Pd interface.
>
> The only question is how to accommodate a user who wants to grab the args
> of a [pd]. For this I'd like to simply add a method that returns the entire
> object
> box contents for the current canvas. So [pd blah] would return "pd
> blah",
> [foo-abstraction 1 2 3] would return "foo-abstraction 1 2 3", and so
> on. (I suppose
> a toplevel patch would just return a bang since there's no box, and I
> already
> have a "filename" method.)
>
> But what should I call the method? objstring? boxmatter? boxtext? boxguts?
>
> -Jonathan
>
More information about the Pd-dev
mailing list