Darren New <dne### [at] sanrrcom> wrote:
> I actually have a pretty hard time coming up with a class I think should be 
> both read/write and copyable, at least without some custom "clone" function. 

  I might not have understood exactly what you are talking about, but two
examples come to mind: A class which represents a numerical value (eg. a
complex or a rational number), and a pixel class.

  The class which represents a numerical value is a good example of a
value-based object for which reference semantics make little sense (beyond
being used as function parameters so that the function can change the
original value rather than the local copy). If you use ints in a value-based
way, it would feel natural to use eg. a complex number class in the same way.

  The advantage of value-based objects is that they are both fast and
consume less memory when instantiated in large amounts (eg. into an array).
An array of numerical objects is going to consume considerably less memory
than an array of references to numerical objects. They are also fast because
passing references around is most probably not going to have a speed
advantage over passing object copies around, especially since cloning
objects is always slower than copying the values of the objects.

  A pixel class is another good example. Maybe even a better example.
A pixel is often an object which has the same size as the natural word
size of the architecture (eg. 32 bits), or at most double that (at least
if you are using integral color components). A pixel class is also something
which is usually instantiated *a lot*, as well as copied and modified
extensively.

  If you are making a program which handles huge images (or even animations),
you really *don't* want to waste memory needlessly on references to pixels.
You really want arrays of pixel objects, because that's the most efficient
way of storing raw images in memory.

  This is one of the main reasons why I dislike the design of the Java
language. You simply *can't* have both abstraction *and* efficient memory
usage of small objects. In Java all objects are allocated dynamically, and
there's no other way of handling those objects than through references.
This is a huge waste of space and resources with something like a pixel
class.

  The only alternative is to completely bypass encapsulation and directly
use arrays of ints. This flushes all what's good and useful in OOP down
the drain.

-- 
                                                          - Warp

Post a reply to this message