R: [PD] Re: [PD-announce] clr: externals in CLR assemblies

Davide Morelli info at davidemorelli.it
Fri Jan 20 12:01:45 CET 2006


Here is a list of what I'd like to change in [clr]:
- rename PostMessage() to post()
- rename ErrorMessage() to error()
- wipe out the SetUp() function: initialization (selectors, inlets, outlets) 
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 at artengine.ca>
To: "Thomas Grill" <gr at grrrr.org>
Cc: <pd-list at iem.kug.ac.at>; "'Hans-Christoph Steiner'" <hans at eds.org>; 
"Davide Morelli" <info at 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 at iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list





More information about the Pd-list mailing list