Darren New <dne### [at] sanrrcom> wrote:
> >   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.

  It doesn't make sense for a numerical variable to be read/write? There's
definitely something I'm not understanding here.

  How do you use, let's say for example, a value-based loop counter variable
if it's not read/write? I can't even bend my mind to figure out how you could
construct a loop with a read-only variable.

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

  Maybe we are having a different notion of what "copyable" means, because
I'm not really understanding.

> >   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'm not understanding what you are saying.

  It sounds to me like splitting hairs with semantics. Is "a = 5" modifying
the value of 'a', or is it creating a "new integral value, 5, and storing
it over the old value of 'a'"?

  Internally it's modifying the variable 'a' (the memory location
represented by that variable name is modified to have a new value).
On the language level it's modifying the value of the variable 'a'.
I'm really not seeing how it's not really modifying 'a', but somehow
"creating a new integral value".

  The same with a pixel object. I could say, for example, something like
"image[x][y].setRed(123);" and by doing that I'm *modifying* the value of
the pixel in question. Nothing new is created and nothing is being copied
around. Instead, the pixel object is being modified in-place.

> I also don't see any good point for making pixels or integers into objects 
> if you have the choice not to.

  Then you have a rather odd concept of how useful encapsulation is.

  What would, in your opinion, be the best way of abstracting away the
internal structure of a pixel so that the code used to handle pixels can
be reused for different purposes? If you want to be able to later modify
the internal structure and/or functionality of a pixel in a centralized
place and in such way that it doesn't break existing code, I don't see
any better alternative than encapsulation, and an object-oriented class
is just perfect for this purpose.

> But I don't see any compelling reason to code like pixels have 
> "behavior" and "state" as such.

  Need for "behavior" could be a question of opinion, but pixels not
having state? Exactly how do you expect to store pixel data anywhere if
that somewhere has no state? How do you expect something with no state
to remember the value of the pixel? That seems completely incoherent to me.

>  Images don't saturate themselves, nor do 
> pixels, for example.

  I'm not exactly sure if by "saturate" you are talking about modifying
an image, or something completely different I'm not familiar with. If you
are talking about modifying the image, then why not? Why couldn't you be
able to tell an image "saturate by this amount" and then it does that?

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

  What does it matter what kind of libraries some programming language
offers? The creators of those libraries made their own design decisions,
but why should that matter? I'm talking about your own code.

  Don't tell you you *can't* create a pixel class in Smalltalk.

> Unless your compiler is smart enough to ditch the vptr (or its equivalent) 
> when you put the pixel into an array-of-pixels

  Why do you think I like C++?

  Sure, I can leak and trash memory and crash the program with C++, but
when I know what I'm doing (and I pretty much do), it allows me to do
things efficiently while still maintaining a relly high level of
encapsulation and abstraction.

  Classes with no virtual functions have no vptr. Is this sometimes a
pain in the neck? Maybe. However, when you know what you are doing, it
allows you to write really efficient code.

-- 
                                                          - Warp

Post a reply to this message