I understand what you're saying, and I too would avoid traps.

But it isn't much of a trap. If the implementation changes, the alias changes, but Csound keeps working in its C++ API. Then we would have to write some glue code to keep the C API working.

Actually, I don't much care which way the alias goes. Csound could be implemented as a simple C++ class aliased to a C API, or it could be implemented as a C API with a virtual function table and aliased to a simple C++ class. I prefer the first because it automates a lot of maintenance. But the second would still permit a C++ programmer to derive a new class from CSOUND.

Regards,
Mike

-----Original Message-----
From: jpff@codemist.co.uk
Sent: Aug 13, 2005 3:44 AM
To: csound-devel@lists.sourceforge.net
Cc: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] ENVIRON

As you explained it, it relied on an implementation detail rather
than a language feature, and so I for one am not happy with building in
a trap.
==John ffitch


-------------------------------------------------------
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