Re: Some thoughts about OO programming
From: TGOS (tgos_at_invalid.invalid)
Date: 10/07/04
- Next message: MSCHAEF.COM: "Re: Some thoughts about OO programming"
- Previous message: Thad Smith: "Re: sliding median filter"
- In reply to: MSCHAEF.COM: "Re: Some thoughts about OO programming"
- Next in thread: MSCHAEF.COM: "Re: Some thoughts about OO programming"
- Reply: MSCHAEF.COM: "Re: Some thoughts about OO programming"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 07 Oct 2004 19:19:32 GMT
On Thu, 07 Oct 2004 08:46:14 -0500 mschaef@io.com (MSCHAEF.COM) wrote in
comp.programming:
> What concept doesn't have flaws?
I know, but you always hope there is a way around them and the inventors
of the concept just overlooked it, or they dumped it in favor of a
compromise.
E.g. primitives in Java are a compromise. Actually everything could be
an object, but if numbers were objects (and JIT compilers wouldn't
change this behind the back of the programmer), the speed would be
several times slower (e.g. int values would be always passed by
reference and not by value - and we know that memory access is slow).
> Can you post more information on what you've done so far? I think it'd
> probably make for interesting reading.
Well, I haven't written anything down so far ;)
I have thought about a virtual machine, that is pure OO and that only
works with 16 instructions. I played around with several concepts of JIT
compilers, that try to make code as machine friendly as possible (with
inlining). The machine would neither be stack, nor register based; it
would be instruction line based. And I still haven't made up my mind,
whether I use a real garbage collector, reference counting or manual
memory managemen (I thought about combining two schemes, too).
Basically I took Java and Smalltalk as example and try to change
everthing I don't like about these two languages. The idea was to also
steal a bit from C++ and mix it up with procedural and aspect
programming concepts.
> I'd rather put a method 'fly()' in Bird, to avoid the problem you mention.
> Asking animals if they can fly is the logically the same as switching on a
> type code which is exactly what polymorphism is supposed to help fix.
Well, it was just an example.
But you are aware that bats can fly and they are no birds :P
Okay, here's an example from another group, a bit less concrete,
therefor more abstract ;)
We have a company named Alpha. Alpha designs a class named ClassA.
ClassA has methods methodA1(), methodA2(), ..., methodA30(). ClassA
describes objects that do something, we don't care what they are good
for.
Company Beta wants to write a class ClassB. The function is very similar
to the one of ClassA. Let's say the difference is how both handle the
internal size of something in a different way. Instead of writing ClassB
from the scratch, which is reinventing the wheel and against the OO
concept, ClassB simply inherits from ClassA. Caused by the different
internal behavior, it has to overwrite methodA3, methodA5 and methodA10,
otherwise it wouldn't behave correctly anymore to the external world
(i.e. when being used as ClassA). Further it offers two new methods,
methodB1() and methodB2(), which are only used by Company Beta.
Now Alpha decides to add methodA31() to ClassA. Unfortunately this
method didn't exist when ClassB was planed, designed and written. So
this method is not overwritten, however inherited by ClassB.
Since methodA31() returns a value, that depends on the internal handling
that ClassB changed, it will return a false value for ClassB. Beta would
have to overwrite it to fix this.
> Yeah, in general that's called the fragile base class problem. It's one of
> the reasons people tend to like interface inheritance, etc.
But interfaces mean you have to write code over and over again. Hundreds
of classes may all do the same in the method and they all then have to
reimplement it. This is not effective.
> Another reason this is beneficial is that the fragile base class problem
> extends to things like class layout. That is, if I give you an object
> library and you compile against it, the code the compiler emits for yor
> code is going to be full of assumptions like The _foo field of the Bar
> class is at offset 48 from the beginning of the object. If I add a field
> to a base class in my library, that can change the offset of _foo and
> require all code that links against my library to be recompiled.
Not in case of Java or .NET
Here the code is not bound to addresses, but to names.
The address mapping is there performed during loading of the classes by
the JIT compiler.
In Smalltalk neither. I don't know about C++, but at least in C,
libraries are loaded by the dynamic linker of the OS and it
automatically fixes addresses accordingly, by laying out DLLs and then
fixing function pointers.
> That's not necessarily true. It's perfectly possible to define tool
> objects that can manipulate images. Rather than saying this:
>
> Image img = new Image("foo.bmp");
>
> img.GaussianBlur(12);
>
> You might say this:
>
> Image img = new Image("foo.bmp");
> GaussianBlurFilter filt = new GaussianBlurFilter(12);
>
> filt.apply(img);
But how can the filter access the image data?
If Image stores everything in a byte array and offers getBytes() to
return a reference to the array, this destroyes data encapsulation.
Ideally only methods of an object can access instance variables. If I
offer a getBytes method, I could as well make the array public and
create a method-less object.
> Not necessarily. It's pretty easy to use techniques like copy-on-write
> to minimize this.
But manipulations always have to write :P So there is no gain.
-- TGOS
- Next message: MSCHAEF.COM: "Re: Some thoughts about OO programming"
- Previous message: Thad Smith: "Re: sliding median filter"
- In reply to: MSCHAEF.COM: "Re: Some thoughts about OO programming"
- Next in thread: MSCHAEF.COM: "Re: Some thoughts about OO programming"
- Reply: MSCHAEF.COM: "Re: Some thoughts about OO programming"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
