Here is a list of what I'd like to change in [clr]:
will be done in the class constructor
about the last point: I know that in "real" externals selectors declaration is done in setup() and inlet/outlet creation in new() but here we only have what corresponds to new(), I mean we can't register methods before actually initializing the object. So I think the best thing to do is what Mathieu calls "following C# conventions" and use the class constructor: this is what C# developers are used to.
But, Thomas, feel free to change anything needed to make it work with your loader patch (hadn't tried it yet..)
ciao, davide
----- Original Message ----- From: "Mathieu Bouchard" matju@artengine.ca To: "Thomas Grill" gr@grrrr.org Cc: pd-list@iem.kug.ac.at; "'Hans-Christoph Steiner'" hans@eds.org; "Davide Morelli" info@davidemorelli.it Sent: Friday, January 20, 2006 11:32 AM Subject: Re: R: [PD] Re: [PD-announce] clr: externals in CLR assemblies
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list