Subject: Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)
From: Tim Goetze (tim_AT_quitte.de)
Date: Tue Mar 09 2004 - 22:05:16 EET
[Fons Adriaensen]
>> without making an absolute estimate of the complexity of your snippet,
>> and presuming it will compile and work flawlessly, i think it is safe
>> to say it is more complex than the PortInfo proposal.
>
>But still trivially simple. If someone writing a host falls over this,
>he will probably never reach the end. There are much more complicated
>issues to deal with.
on which i would rather like to see people concentrate. i'm also not
particularly happy with your 'trivially simple', and the sentence
following it. what may come easy to you can be hard for others, and
vice versa.
>> also still in dire need of explanation is the fact that an array is
>> referenced as 'PortNames' but contains data that will not fit this
>> name.
>
>"For historical reasons". It's in the good company of the 'gecos'
>field in /etc/passwd for example.
even if we retreat to such a weak excuse, this certainly doesn't
qualify for making life for new authors simpler (on which we seemed
to be in agreement).
also, even for seasoned developers, maintaining a combined
port names + n * (value labels) array can become a burden all too
easily i fear.
>> i do admit the mechanism is elegant, and makes for a compact object
>> file. but these are secondary virtues, with no good reason given why
>> they should preceed primary virtues: readability, simplicity, fool-
>> proof operation, versatility.
>
>I never claimed compactness or versatility as a virtue. It *is* readable
>and simple. Nothing in C is ever foolproof - an invalid pointer will
>hit you no matter how you implement the enums. There's the demolition
>tool to test for this.
if you don't even see compactness as a virtue, there's only elegance
remaining to recommend your proposal. elegance at the cost of
increased complexity in understanding and implementation, no matter
how you look at it.
>> lastly, you still haven't given a good reason why non-integer values
>> should not be associated with labels.
>
>As I said, it's a different problem. And your proposal is a clean way
>to solve part of it. But IMHO it should be generalised, but then it
>probably enters the RDF domain.
you have yet to prove it's a different problem, and tell us what
points need to be generalized beyond the solutions we have proposed.
amicalement,
tim
This archive was generated by hypermail 2b28 : Tue Mar 09 2004 - 22:23:58 EET