On Thu, 19 Jan 2006, Thomas Grill wrote:
A thought a bit about the naming of functions for the Pd domain and also the external classes. I find it a bit too verbose. Are you sure that it's necessary to call it "DelegateWithoutArguments" or "PostMessage" when the functions are in their own namespace? It's really my personal taste, but i would prefer sticking closer to the naming of the original PD API functions (and i admit i don't like typing that much...)
What's disturbing about PostMessage() is that, if I guess what it does, it doesn't post what is normally called a Message in Pd, and that may be confusing to people learning the API. Sometimes less is more and thus I think post() is better.
What i'm also wondering about is the mixture of class and objects initialization in SetUp (wouldn't Main be a better choice, since that's already reserved in C#?).
If following C# conventions has any practical advantage, then C# conventions should be followed. For anything else, it should be as close as possible to Pd's C API. Bonus points if there is a way to guess the C# API from knowing the C API or the Flext API.
BTW, anyone looked at SWIG ? It could provide a multilanguage interface to Pd's API and/or Flext's API. SWIG generates wrappers from C++ code to Python, Ruby, Perl, Java, C#, Tcl, PHP, Lua, and several kinds of LISP (Guile, AllegroCL, CMUCL, ...).
SWIG might be the key to unifying the Pd API in various programming languages (currently, PyExt, GridFlow, k_guile, all do things quite differently from each other). Note that I don't want a "common denominator" API which would prevent from using any special features of a given language in the Pd API for that language. Nevertheless I would like language-specific APIs to be easy to guess (deduce) so that it's easy to start writing externals in language X for someone who has general experience in language X and experience in writing Pd externals in language Y.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada