Re: [fluid-dev] Fluidsynth changes

[Paul Millar]

Hi Miguel,

Its always good to hear ideas about alternative approaches.  I've some 
comments I've included below.

On Thursday 19 April 2007 23:31, Miguel Lobo wrote:
>    - Translating from C to C++, using classes and templates to increase
>    code reuse where possible.

OOP is very powerful programming methodology, facilitating concepts like 
polymorphism.  However, there seems to be a mass amnesia that other languages 
both exist and also work.  OOP (and C++) code is not prima facie better than 
code written in a non-OOP language.

Code-reuse is (generally) a "good thing".  Do you know of specific instances 
(within the current code-base) where code is duplicated?  These should be 
checked.

Personally, I'd be against a wholesale change to C++ for a few reasons:

I've found OOP code tends to be more impenetrable to the casual programmer: 
you need to understand more of the whole program before being able to do 
anything.

Also, the GCC C++ ABI has a history of being "unstable": it changes with most 
releases of GCC.  Supporting the different ABIs would be awkward (either to 
us, or the distros).  Different compilers have different C++ ABIs, so 
fluidsynth.dll compiled with GCC would not work with code generated with 
MSVC.  Whereas the C ABI has be constant for many, many years now.

I'm currently linking against fluidsynth with some C code.  If this 
translation goes ahead, I'd need some C linkage.

>    - Changing the naming conventions / indentations / so on to follow Qt
>    code style.

This is a topic that has provoked many, many discussions (or flamewars) in 
other projects.  I'll limit this to just some observations.

Coding styles is something people often feel strongly about.  Imposing a 
coding style "artificially" is a good way of pushing developers away.  Any 
coding style should emerge naturally from the developer community.

Despite different documents assertions, there is no "one true way".  People 
tend to forget this.

Re-writing an existing project's code to conform to a new coding standard 
seems like a waste of time to me; it would also likely introduce bugs and is 
a little bit fanatical.

>    - Changing the build infrastructure from autotools to QMake, which is
>    IMO simpler and provides support for MSVC.

I don't really know QMake, but what can it do that you can't do with autotools 
and make?

One should be able to either run MSVC command-line tools through Gnu make 
(either via Cygwin or MinGW's MSYS).  If you want them, the MSVC project 
files can be dynamically generate from the CVS tree with some simple 
scripting language.  For example:
        http://www.winehq.com/site/docs/winedev-guide/testing-windows

>    - Splitting the Fluidsynth library into several "components" [...]

Yes, sounds good.  This could be some kind of plug-in structure, using the OS 
native DSO mechanisms (doesn't require the code to be C++, though)

>    - Removing the parts of Fluidsynth that don't fit into that vision,
>    such as much of the user interaction stuff (command handlers and so on),
> the midi router, etc.

Well, I've some code that can connect to a remote fluidsynth running as a 
server.  I'd be a little upset if support for that were removed.


> For the moment I've half-jokingly called this project FSNG [...]

Well, good luck with it!

I don't see any strongly compelling reason for any of these changes.  If you'd 
like to contribute, I'd say adding a unit-test framework would be much more 
beneficial.

Cheers,

Paul.

pgpch_quGk7cM.pgp
Description: PGP signature