Hi Paul,
Thanks for your comments.
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.
I would say I am quite familiar with OOP-code written in non-OOP languages such as C. I've even written OOP code in assembler myself and hey, it works and it's not very difficult to understand. However, it's very verbose compared with C++ and it doesn't give you any type safety. To a lesser degree, I think OOP C suffers from the same problems, although as I said reasonable people can disagree.
In short, I would say that my decision to go with C++ is an informed one and not due to amnesia.
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.
I wanted to avoid a very detailed discussion of the current codebase, because I think it's likely to get too specific and unlikely to sway people either way. But anyway, I'll mention a couple of examples: there is a lot of boilerplate code for FluidList's that is repeated in many places, and you can also check fluid_defpreset_noteon in
defsfont.c and fluid_rampreset_noteon in ramsfont.c.
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.
Well, I would say FluidSynth is already OOP, only written in C.
Also, the GCC C++ ABI has a history of being "unstable": it changes with most
releases of GCC.
I think that was mostly true in the past. I know one of the main targets of the G++ developers during the last few years was to stabilise the ABI and, though it took them some time (being no doubt a difficult task), I think they got there by GCC
4.0.x or so.
Supporting the different ABIs would be awkward (either to
us, or the distros).
Speaking of a case I've followed quite closely, yes, supporting KDE in Debian was a bit of a headache for the maintainers during the last ABI change (a few years ago IIRC). In any case even then you could find plenty of C++ libraries in any distro, so it must not have been that bad.
Different compilers have different C++ ABIs, so fluidsynth.dll compiled with GCC would not work with code generated with
MSVC.
That's true. However, I don't see why that has to be a problem. We can easily provide both binaries.
I'm currently linking against fluidsynth with some C code. If this translation goes ahead, I'd need some C linkage.
Well, obviously this translation is not meant as a drop-in replacement for current FluidSynth. By the time it's functionally finished, yes, I would like to provide C bindings, although most likely there will be many changes compared to the current C API.
> - 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'm aware of that. That's why I made a point of mentioning it in my "disclaimer" :)
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.
Well, for some languages there are coding standards that are quite extensively used and adhering to them helps new or casual developers who might not be familiar with a project's specific style.
Despite different documents assertions, there is no "one true way".
I completely agree.
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.
Well Paul, as you said this is a hot topic so perhaps we would do well to avoid emotionally charged words such as "fanatical". Most of the coding standard change was done fairly quickly using a code reformatter called Artistic Style and a simple Python script I wrote in half an hour. If it was a waste of time, it was a waste of *my* time and I haven't seen any bugs as a result yet.
I don't really know QMake, but what can it do that you can't do with autotools
and make?
It's simpler. If it proves inadequate, I'll move to something else; perhaps autotools, CMake, or whatever. My philosophy is that the building system performs a simple task and should be kept as simple as possible.
> - 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)
That's one possibility, although I've never been sure if plugins make a lot of sense for small OSS projects. Bu the main reason for the component split is so that each one is more easily understood and used.
> - 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.
If for some reason the functionality you need was not added to my project, you could always write it yourself or keep on using current FluidSynth versions.
Well, good luck with it!
Thank you. I'm not aiming for world domination; I just want to scratch a personal itch and if it helps other people, all the best.
I don't see any strongly compelling reason for any of these changes.
Then I guess that's the reason you didn't do them ;)
If you'd like to contribute, I'd say adding a unit-test framework would be much more beneficial.
Perhaps, but I'm not interested in doing that for the moment.