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