Warp wrote:
> 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 

Right. But it also makes no sense for it to be read/write.

I can't think of examples that should be modifiable *and* copyable. If it's 
modifiable, you don't want multiple copies floating about.

>   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).

I'm speaking of semantics, not efficiency. In Smalltalk (and most LISP 
implementations), for example, integers are just like any other object. But 
since they don't have any post-construction members that modify the object, 
they can be represented internally as values.

If your value is "money" you'll want a class with value semantics. If your 
value is "city+state+postal code" you likely want a pointer to a 
non-modifiable value.

I *really* don't see a good use for classes that can be values or references 
both, depending on the variable, like C++ allows. Sure, a class that's a 
value class? Yep. But individual objects having either value or reference 
semantics depending on how you declared the variable holding them? Seems 
like overkill to me. Do any good examples come to mind?

>   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.

I don't think you really modify pixels, do you? You create a new pixel and 
store it over top of the previous pixel. You wouldn't want to modify a pixel 
and have all the red pixels in your image turn blue or something, no?

I also don't see any good point for making pixels or integers into objects 
if you have the choice not to. (Obviously, if you're running Smalltalk and 
*everything* is an object, including the stack and the executable code, it's 
different.) But I don't see any compelling reason to code like pixels have 
"behavior" and "state" as such.  Images don't saturate themselves, nor do 
pixels, for example. IIRC, in Smalltalk, pixels weren't objects. You had 
bitmaps as the objects, and if you needed you could make a one-pixel bitmap, 
but all of the methods were designed for big bitmaps.

>   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.

I don't think that would be as much of a problem if you could use something 
other than objects in Java. I.e., if you could declare a "structure" and 
deal with it that way, I don't see the problem much.

>   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.

Kinda. Only if you don't want a class that's "image" (or "bitmap") to be the 
lowest level in your class hierarchy. Now, obviously I haven't written as 
much complex OO image processing software as you have :-) but I wouldn't use 
OO inside the loop.

Unless your compiler is smart enough to ditch the vptr (or its equivalent) 
when you put the pixel into an array-of-pixels, I don't see using 
distinguished-caller syntax as all that beneficial. And in languages that 
don't use distinguished-caller syntax, you can't even easily tell by looking 
at the interface that a pixel without any virtual methods isn't an object, 
for the languages I know that don't use distinguished caller syntax.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message