gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSSound Reimplementation


From: Jamie Ramone
Subject: Re: NSSound Reimplementation
Date: Thu, 16 Jul 2009 10:23:58 -0300

I'd like to chime in here and say that this approach IS actually a
good idea as :

1 ) it does solve the ABI change breakdown problem and

2 ) it is actually much easier to read because it's a prime example of
encapsulation and abstraction, so complexity is hidden.

The use here of encapsulation and abstraction are precisely (among
other reasons) why the object oriented paradigm exists. Leveraging
these concepts allow one to concentrate on a specific problem by
hiding away the details of the rest behind an API, that of the other
objects you're using from within whichever one you're working on. If
the code is hard to read then that api is not well defined, so the
real problem would be to redefine it so as to make it understandable
(read: actually usable). Depending on being able to see all (or most)
of the details at once is not a good idea. Another thing I might add
is that readability is something rather subjective (though there are
generalities like statistics to allow it to be an objective
measurement), so it shouldn't be used to choose or dismiss a program
writing method.

So locality of reference is gone. It gets replaced by messaging an
object. OK. So what? Why depend on locality? Again, I'm hard pressed
to find an objective way to choose one over the other. If the API of
the messaged object is well defined then I find both forms of the code
to be equally understandable. But that's my opinion, some may agree
and others disagree. So this reasoning is also a bad one for judging
the approach.

The performance hurting one I like. This is something that CAN
actually be measured, so it's perfect for considering this approach.
Now, why exactly does it hurt performance? Is the amount lost so much
greater than the amount achieved by the overall algorithm used that it
performs slower than if that algorithm wasn't used? How fast does the
code need to be, minimally? These are the questions one should ask
(and answer) in order to move ahead here.

So I agree with Richard here. However, if no one else changes the code
and you do, and submit a patch as you did, and it does solve the
problems you're looking to solve, then I don't see why your patch
wouldn't be accepted.

-- 
Besos, abrazos, confeti y aplausos.
Jamie Ramone
"El Vikingo"




reply via email to

[Prev in Thread] Current Thread [Next in Thread]