An update for the [classinfo] object:
*** Get methods and args with [classinfo] ***
You can get the number of methods for [bng] (other than built-ins like bang, float, etc.):
[methods( | [classinfo bng]
Or send a float to get the method and args at that index:
[my_numbox] | [classinfo bng]
Above, sending a "0" gives: list click A_FLOAT A_FLOAT A_FLOAT A_FLOAT A_FLOAT
Since all the pd classes are stored as methods to a class named "objectmaker", [mynumbox]---[classinfo objectmaker] lets you peruse all the loaded objects' args at your leisure. Put that all together with an [until] and a [route some-object-name] you can get the argument types for any loaded object. That's pretty handy, so I added some syntactic sugar:
[args( | [classinfo bng]
The above will do all that for you, thus outputting: symbol A_GIMME
This is in addition to figuring out which build-in methods a class accepts (float, symbol, etc.) as well as many of the other class fields. So now you can program 1,000 [random] monkeys building infinite well-formed Pd patches with the correct args and methods!
More useful, however, is that we can now auto-build a help patch with _some_ [pd META] comments already filled in, plus programmatically add argument info to the extant help patches. Of course the A_GIMME example above shows why the author can't be 100% lazy, but it does make it lots easier to make fun of devs who are 100% lazy since 50% of the work will be autocompleted by clicking a button. :)
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Jonathan Wilkes jancsika@yahoo.com; "pd-dev@iem.at" pd-dev@iem.at Cc: Sent: Monday, March 4, 2013 6:35 PM Subject: Re: [PD-dev] info classes
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@yahoo.com To: Jonathan Wilkes jancsika@yahoo.com; "pd-dev@iem.at"
Cc: Sent: Saturday, March 2, 2013 3:45 PM Subject: Re: [PD-dev] info classes
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Jonathan Wilkes jancsika@yahoo.com;
"pd-dev@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