[PD-dev] class_addmethod2

[Mathieu Bouchard]

On Fri, 16 Dec 2005, Frank Barknecht wrote:

> Maybe a "best of both worlds" approach could be used, that allows both
> long names and short aliases for methods, that accept veryveryverymany
> arguments and thus aren't readable with A_POINTER,... anyways.

I'm not very much concerned with methods that accept veryveryverymany 
arguments (except in the case of undifferentiated A_GIMME args, a la [list 
append] and such). The readability aspect I had in mind is that the 
declaration of methods should be formattable as a nice table that lists 
you all the methods of a class in a way that does fit on a page. You 
*could* use tools that would generate the big picture from a more 
verbosely written code, but it's easier to get the big picture for free as 
you're writing the code (or reading it).

> I could think of using a field delimiter like ":" in the argument type
> string: "p:f:f:s" or "A_POINTER:A_FLOAT:A_FLOAT:A_SYMBOL" then could be
> allowed. And we would get rid of A_NULL in both cases.

I think that atomtypes are very few and will most likely stay rather few,
so it's easy to remember the abbreviations of them all, and we'll never 
come close to run out of letters of the alphabet, unless we change the 
typing paradigm completely, but that would require a completely new API 
anyway.

Note: I don't even know whether it will be possible to add A_STRING and
A_LISTPTR, because reference-counting would require that t_atom gets a
constructor and a destructor, which would be a change to Pd's external API
which wouldn't be backwards-compatible.

 _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada