9 Mar
2004
9 Mar
'04
4:15 p.m.
[Fons Adriaensen]
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.
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.
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.
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
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. 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. 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. 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.