As far as software engineering practice goes, I agree with Istvan that an adequate degree of encapsulation and abstraction should permit parser development to proceed separately from interface development.

In terms of the current API, if it's not adequate, it should be possible to amend it, i.e. to add new functions and data members, without breaking backward compatability -- BUT ONLY IF THE API FUNCTIONS ARE IN A VTABLE AND NOT DIRECT MEMBERS OF THE CSOUND STRUCT.

If there is a vtable, then new functions can be added at the end of the function table, and new data members can be added at the end of the CSOUND struct, without changing the memory layout of existing code. So, old plugins could continue to work with a new version of Csound, even after the parser is introduced.

This is a second reason, perhaps a more compelling one for Csound developers, to adopt a memory layout that is binary compatible with a C++ API.

I strongly urge that the vtable be implemented before releasing Csound 5.

In the abstract, I propose merely replacing (this of course is just schematic)

struct CSOUND {
 int (*api1)(CSOUND*,...);
 int (*api1)(CSOUND*,...);
 MYFLT data1;
 MYFLT data2;
 ...
};

with:

typedef int (*APIFUNC)(CSOUND*,...)
typedef VTABLE*APIFUNC;
struct CSOUND {
 VTABLE;
 MYFLT data1;
 MYFLT data2;
 ...
};

Best,
Mike

-----Original Message-----
From: Istvan Varga 
Sent: Sep 9, 2005 7:34 AM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] [OT] Does anyone still develop Csound ?

If a new parser that is compatible with the existing orchestra language
can be integrated without breaking external code that uses the API, then
it can be added even after Csound 5 is already released and is no longer
beta. So, there is surely enough time to work on the parser, and it can
be added whenever it is done. Replacing the parser is unlikely to affect
the host API that is fairly high level, and does not depend on internal
structures of the parser at all. Plugin opcodes are a more likely problem
area, but as long as frequently used structures like TEXT (for all the
p->INOCOUNT and others) are preserved, opcodes should continue to work;
also, the API already has functions that allow opcodes to query information
about the number and type of arguments etc. without having to access
internal structures.

John ffitch wrote:

> ...new parser.....
> 
> ==John
> 
> (only joking)


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Does this mean that with the proposed change, calls like

   csound->Message(csound, "blah\n");

should all be replaced with

   csound->vtable->Message(csound, "blah\n");

or even worse, something like

   csound->vtable[135](csound, "blah\n");

Also, is there a reason why function pointers cannot be appended -
mixed with other data - at the end of the public part of CSOUND,
once all the padding reserved for future API functions is consumed
(I do suspect, though, that by that time other binary incompatible
changes will already need to be done, allowing for changing the
layout of CSOUND at the same time) ?

Michael Gogins wrote:

> As far as software engineering practice goes, I agree with Istvan that
 > an adequate degree of encapsulation and abstraction should permit parser
 > development to proceed separately from interface development.
> 
> In terms of the current API, if it's not adequate, it should be possible
 > to amend it, i.e. to add new functions and data members, without breaking
 > backward compatability -- BUT ONLY IF THE API FUNCTIONS ARE IN A VTABLE
 > AND NOT DIRECT MEMBERS OF THE CSOUND STRUCT.
> 
> If there is a vtable, then new functions can be added at the end of the
 > function table, and new data members can be added at the end of the CSOUND
 > struct, without changing the memory layout of existing code. So, old plugins
 > could continue to work with a new version of Csound, even after the parser
 > is introduced.
> 
> This is a second reason, perhaps a more compelling one for Csound developers,
 > to adopt a memory layout that is binary compatible with a C++ API.
> 
> I strongly urge that the vtable be implemented before releasing Csound 5.
> 
> In the abstract, I propose merely replacing (this of course is just schematic)
> 
> struct CSOUND {
>  int (*api1)(CSOUND*,...);
>  int (*api1)(CSOUND*,...);
>  MYFLT data1;
>  MYFLT data2;
>  ...
> };
> 
> with:
> 
> typedef int (*APIFUNC)(CSOUND*,...)
> typedef VTABLE*APIFUNC;
> struct CSOUND {
>  VTABLE;
>  MYFLT data1;
>  MYFLT data2;
>  ...
> };


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net