Re: [abcusers] ABCp proof of concept

[Guy Gascoigne - Piggford]

I'd have to opt for the second option.  Where myTune is a C struct and 
it gets passed through to all the relevant apis.  This sort of interface 
can be made to be very OO and is trivially easy to wrap in an OO wrapper 
for say C++ or Python etc.  That seems to provide for maximim flexability.

Bear in mind that you really can write very OO ANSI C, it's just that 
the language doesn't really encourage it.

Guy
Remo D. wrote:
Someone stated that using ANSI C would be best but that we would
definitely want to use the object oriented extensions to make it object
oriented C (not C++)...  Perhaps that is ANSI C today... I dunno... I
haven't programed in C for 5 years and perhaps ANSI has  certified an
updated C spec to include the object oriented routines/extensions.
   

There's no so such extension for ANSI C AFAIK.
When you and Paul talk about OO, I think (please correct me if I'm wrong)
that you really mean an "OO Interface" as opposed to a "functional API".
In other words the problem could be rephrased as follows:
Should we provide classes and objects so to be able to write:
myTune = abc:new();
myTune.Import("filename.abc");
myPart=myTune.Parts[1];
if (myPart.Instrument == "Grand Piano")
  ...
or an API to write something like:
myTune = abcNew()
abcImport(myTune,"filename.abc")
if (abcGetInstrument(myTune,abcParts(myTune,1)) == "Grand Piano")
Am I correct?
NOTE: THE ABOVE CODE FRAGMENTS ARE IN PSEUDOLANGUAGE!
                       R.D.
To subscribe/unsubscribe, point your browser to: 
http://www.tullochgorm.com/lists.html

 

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html