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 <jancs...@yahoo.com> > To: Jonathan Wilkes <jancs...@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 <jancs...@yahoo.com> >> To: Jonathan Wilkes <jancs...@yahoo.com>; "pd-dev@iem.at" > <pd-dev@iem.at> >> Cc: >> Sent: Saturday, March 2, 2013 3:45 PM >> Subject: Re: [PD-dev] info classes >> >> ----- Original Message ----- >> >>> From: Jonathan Wilkes <jancs...@yahoo.com> >>> To: Jonathan Wilkes <jancs...@yahoo.com>; > "pd-dev@iem.at" >> <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 >> > _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
