[PD-dev] info classes

[Jonathan Wilkes]

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 at yahoo.com>
> To: Jonathan Wilkes <jancsika at yahoo.com>; "pd-dev at iem.at" <pd-dev at 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 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
>> 
>