Well, this is not my idea. I think it is better to return a function table, and that is what COM does, so the name is misleading.

The COM idea is that IUnknown is a base interface or base class, and every COM interface inherits from it. It has three functions QueryInterface, AddRef, and Release. We can add these to Csound and make a COM object out of it, we can only add QueryInterface and have COM without memory management.

Anyway, the function table idea works the same as your one-function idea in terms of acquiring new functionality without breaking existing APIs. The only difference is that with function tables you only need to call QueryInterface one or a few times to acquire the entire API.

Best,
Mike


-----Original Message-----
From: Richard Dobson 
Sent: Nov 9, 2005 12:49 PM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] Syntactic sugar request

Michael Gogins wrote:

> This is not quite correct (at least, it is not like COM). What is returned
> should be a function table, i.e. a pointer to an array of function pointers,
> not  a single function pointer (that would be just like COM).
> 

But my proposal is precisely not to return a whole API table, but to return very 
possible a single function that has been defined after the API was frozen for 
release. After all, csoundQueryInterface is itself an API function.  Maybe the 
object returned will contain a mini function table with a single function in it; 
but that is an implementation detail. I am trying to describe the "big picture" 
here.

So, there will be a csound object called "csound",  adn you will be implementing 
an App a year from now that happens to know that, say, Stephen has defined a new 
API function defined in some headerfile , and Istvan has 
define a new API function defined in the header file . These 
functions by definition cannot be in the "canonical" API.  Older applications 
will not know about them, and can still use the latest build of csound.lib, 
because the canonical API structure has been preserved.

But: the new app does know about the new functions and can access them via 
QueryInterface. It has no need to obtain the whole API function table ~again~.


>
> Another thing is, you can only call QueryInterface in COM off an existing
> object. So the way this would be used in the Csound API is create an instance
> of Csound, then call QueryInterface off the instance to obtain the API
> function tables.
> 

Exactly. That is what my example was intended to demonstrate; ~except~ that it 
does not access the API table (you already have that, by definition), but 
enables access to more recent functions OUTSIDE the frozen canonical API table:


> csoundQueryinterface(csound,CSOUND_TABLEGET_ID, csoundTableGet); 

Which as I indicated would be in C++ semantics:

csound->QueryInterface(CSOUND_TABLEGET_ID, csoundTableGet);

But please note I am not trying to dot all the i's and cross all the t's here; 
just to suggest the ~principle~ of a mechanism to access API functions defined 
too late to get into the full canonical API function table - hence, a way to 
freeze the API at some point without losing the possibility for new functions to 
be defined in later versions of csound.

But maybe it is all too complicated, and rebuilding apps each time the API is 
changed is easier.

Richard Dobson








-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, forget about the COM comparison then, any similarity is purely 
coincidental and is only  in the  name "QueryInterface". I was not advocaing any 
of the other COM stuff you mention. So we could call it "LoadAPIfunction" 
instead. Whatever.

Richard Dobson


Michael Gogins wrote:

> Well, this is not my idea. I think it is better to return a function table,
> and that is what COM does, so the name is misleading.
> 
> The COM idea is that IUnknown is a base interface or base class, and every
> COM interface inherits from it. It has three functions QueryInterface,
> AddRef, and Release. We can add these to Csound and make a COM object out of
> it, we can only add QueryInterface and have COM without memory management.
> 
> Anyway, the function table idea works the same as your one-function idea in
> terms of acquiring new functionality without breaking existing APIs. The only
> difference is that with function tables you only need to call QueryInterface
> one or a few times to acquire the entire API.
> 
> Best, Mike
> 




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net