"Warp" <war### [at] tagpovrayorg> wrote in message
news:4035eb87@news.povray.org...
> Darren New <dne### [at] sanrrcom> wrote:
>
> > Imagine Java with no inheritance of functions, only "inheritance" of
> > what java calls interfaces. Does it stop being "object oriented"? Most
> > people working in the field of designing programming languages I think
> > would say "no, it's still OO".  It still has objects, dynamic dispatch,
> > memory management, classes, instances, etc. Just not inheritance.
>
>   If you inherit class X from class Y you are saying "X is a Y" (that is,
> it implements everything Y implements and behaves like Y).
>   Y may be completely abstract, meaning that it does not implement
anything
> itself. However, deriving a class from it still means that the derived
> class "is a Y".
>   If you make a class which implements an interface you are doing
inheritance.
> Limited perhaps, but still inheritance.

I have to disagree with this: If X derives Y, X is still X, but inherits the
methods and members of Y. Also, Y is not an X -- for example, if Y was a
Stream and X was a RandomAccessStream, A RandomAccessStream contains methods
and members of a Stream, but it is still a RandomAccess Stream. A Stream is
not a RandomAccessStream from the other way around as well so X cannot
actually be Y. The Stream may contain functionality to connect to some
device, but doesn't have the capability of randomly accessing it. The
RandomAccessStream has ability to connect to some device because it
inherited that ability from a Stream. That is why the use words like
"instanceof" instead of "equals" to check if a class inherits from another
class.

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> 32 comparisons for /one lookup/. Multiply that by, say, 100,000 lookups for
> fur.

  Using 'new' will not help. There will still be 100000 lookups in a loop
regardless of whether there's a 'new' or not.

  The whole point in this is whether 'new' is useful or not. It isn't.

  Besides, there's no need to initialize an instance with the = operator.
You don't have to do that in C++ so why would you need to do it in this
scripting language?
  You can simply say:

  Color myColor(.1, .2, .3);

  (Instead of "Color myColor = Color(.1, .2, .3);")

  No need for 'new', and there's no ambiguity.

> >   There's a reason why in Java everything is not an instance of a class.

> I think everything should have been.

  Really? Then good luck trying to write things like "a = b+c;" in Java...

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> I have to disagree with this: If X derives Y, X is still X, but inherits the
> methods and members of Y. Also, Y is not an X -- for example, if Y was a
> Stream and X was a RandomAccessStream, A RandomAccessStream contains methods
> and members of a Stream, but it is still a RandomAccess Stream. A Stream is
> not a RandomAccessStream from the other way around as well so X cannot
> actually be Y.

  Then perhaps you should read some book about OO programming.

  The "is-a" relation between inherited classes is one of the fundamental
properties of object-oriented programming. If you don't understand that
then you still have much to study.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:40363a68@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > 32 comparisons for /one lookup/. Multiply that by, say, 100,000 lookups
for
> > fur.
>
>   Using 'new' will not help. There will still be 100000 lookups in a loop
> regardless of whether there's a 'new' or not.
 >
>   The whole point in this is whether 'new' is useful or not. It isn't.
>
>   Besides, there's no need to initialize an instance with the = operator.
> You don't have to do that in C++ so why would you need to do it in this
> scripting language?
>   You can simply say:
>
>   Color myColor(.1, .2, .3);

For the initial instance, sure; that's why C++ didn't both putting a new
there. But, what about assigning myColor again? Are you saying just do
another Color myColor(.1, .2, .3)? I'd find that just confusing. But, that's
me.

>   (Instead of "Color myColor = Color(.1, .2, .3);")
>
>   No need for 'new', and there's no ambiguity.
>
> > >   There's a reason why in Java everything is not an instance of a
class.
>
> > I think everything should have been.
>
>   Really? Then good luck trying to write things like "a = b+c;" in Java...

Smalltalk does that nicely... I don't see the problem.

One of the disconnects here is that I keep thinking in terms of a compiled
language, not a scripting language. It would be nice if we could compile
parts of our scenes into objects. But, I fear I'm opening a Pandora's box
even suggesting such a thing. It would make for interesting conversation, I
think (but most likely, just flames).

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   In what basis can you call it an OO language?

> That it has objects. Classes are a help, too.

  Then a modular language like Modula3 would be an OO language. It isn't.

> >   Having modules is not sufficient.

> OO without inheritance != modules. That's kind of the point I'm making.

  Classes without inheritance is simply a modular language.

  Don't get confused by the *name* "object-oriented". It's just a name
picked for shortness and clarity. It does not mean that having "objects"
is enough for a language to be object-oriented. The term means a lot
more than that.
  If you have modules only, that's not object-orientedness.

> >   If you inherit class X from class Y you are saying "X is a Y" (that is,
> > it implements everything Y implements and behaves like Y).

> Yes? So?

  So you are inheriting, thus you have inheritance, thus object-orientedness.

> That may be how you define it. However, note that with only interfaces, 
> you can't get a heirarchy like you're talking about.

  If you can't inherit one interface from another, thus being able to
construct a hierarchy, then it's not an object-oriented language.
What you have is basically a modular language with simple interfaces.

> >   If you make a class which implements an interface you are doing inheritance.
> > Limited perhaps, but still inheritance.

> And it's also possible to have OO languages in which there is no 
> inheritance. "Delegation-based OO" is what it's called.

  I believe you can make a hierarchy of more specific classes depending
on more abstract classes with that, can't you?

> >   (By the way, what does memory management have to do with OO?)

> The same thing modularity does. If you have to know what the lifetime of 
> an object and all its sub-objects are, then you've broken the 
> modularity. If I have to know whether my "window" instance holds onto a 
> reference to the "bitmap" item inside my "picture" instance, then the 
> author of "efficient_window" is not free to cache that information in an 
> implementation that inherits from "window".

  I may be unusually dumb today, but I did not understand anything of that.

  You are making some point about someone breaking modularity by bad
object-oriented design, or something similar. What escapes me completely
is what this has to do with object-oriented languages. (OO languages
provide you the tools; OO design is a completely different issue.)

> FWIW, Alan Kay, the guy who invented "OO", decided that dynamic dispatch 
> and memory management were the two requirements for OO.

  Those may be *minimum* requirements, but are they *sufficient*
requirements? I strongly don't think so.
  If a language doesn't even have the concept of a "module" in any shape
or form, then that language simply can't be an OO language.
  Modules are an essential tool for encapsulation and abstraction.
You simply can't have objects if you don't have modules.

  It would be quite funny to have an object-oriented language with
no objects whatsoever.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message
news:403646af$1@news.povray.org...
> Dan P wrote:
> > However, it is
> > certainly true that if all primitives were represented by a class, it
would
> > take more memory,
>
> Actually, it's not. Especially not for compiled, strongy-typed languages.

Even better! :-)

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:40363b1e@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > I have to disagree with this: If X derives Y, X is still X, but inherits
the
> > methods and members of Y. Also, Y is not an X -- for example, if Y was a
> > Stream and X was a RandomAccessStream, A RandomAccessStream contains
methods
> > and members of a Stream, but it is still a RandomAccess Stream. A Stream
is
> > not a RandomAccessStream from the other way around as well so X cannot
> > actually be Y.
>
>   Then perhaps you should read some book about OO programming.
>
>   The "is-a" relation between inherited classes is one of the fundamental
> properties of object-oriented programming. If you don't understand that
> then you still have much to study.

Let's think of it in more familiar terms because computer-science is
confusing. When mom squirted you out, you became an object derived from
attributes of your mom and your dad. Are you your mom or your dad? If you
were to clone yourself, is that clone a clone of your mom or your dad? If
you have a child, is that child you? No, although the child may inherit some
of your traits, like your eye color and sunny disposition, that child is not
you, it just inherits some attribute from you. Now, let's say the world sees
your son and asks, "Is he a Warp?" They would be asking, "Is he your child,"
or, "Is he in Warp's family?" That is the sense in which a person talks
about an object "being" another object.

Post a reply to this message

In article <4035e6de@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>> I think it would be a really good idea to make everything an instance of a
>> class.
>
>   There's a reason why in Java everything is not an instance of a class.

Well, it is certainly possible to make every type a class.  You just need a
fair amount of compiler/interpreter magic to handle with sufficient
efficiency what would be PODs in most languages.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> Let's think of it in more familiar terms because computer-science is
> confusing. When mom squirted you out, you became an object derived from
> attributes of your mom and your dad.

  You clearly need a lot more studying of OOP. You are confusing the
word "inheritance" as used in colloquial language with what it means
in object-oriented programming.

  Base classes are more abstract/generic than derived classes. When you
create a class derived from another class, you are making a specialization
of that more abstract class. The derived class *is* of the same type as
the base class, but more specialized.

  The above paragraph probably doesn't tell much, so let's look at an
example:

  Suppose you have a class called LivingEntity which has certain properties
(such as whether the current instance is alive or dead).

  Now you can derive for example two classes from it: Plant and Animal.
They implement everyting LivingEntity implements (eg. the knowledge of
being alive or dead) plus more. 'Plant' has specific information common
to all plants and 'Animal' common to all animals.
  'Plant' *is a* LivingEntity because it implements everything the latter
does and can be handled as an insteance of the latter. The same goes
for 'Animal'. 'LivingEntity' is more abstract than either one because
it does not specify as much as them.

  Now suppose you inherit the classes 'Mammal' and 'Fish' from 'Animal'.
  'Fish' *is an* 'Animal', and it also *is a* 'LivingEntity' now. It's more
specific than either one because it contains more specialized info common
to all fish (but not common to eg. mammals).

  Now suppose you inherit 'Dog' from 'Mammal'.
  'Dog' is a 'Mammal', an 'Animal' and a 'LivingEntity'. 'Dog' is
more specific than 'Mammal' because it contains specific info common
to all dogs.

  If you have some function which for example handles LivingEntities,
you can give it a 'Dog' because 'Dog' *is a* 'LivingEntity'. You can also
give it a 'Fish'.

  If you have a function which handles Mammals you can also give it a 'Dog'
because 'Dog' *is a* 'Mammal'. However, you can't give it a 'Fish' because
it's not a 'Mammal'.

  'Dog' is a very specialized version of 'LivingEntity' (etc. all the
way down in the inheritance hierarchy).

  Now if you have a "mom" Dog, you can't inherit a "child" Dog from it
because the "child" Dog *is not* a "mom" Dog.
  You can create a new 'Dog' instance using the info in "mom" Dog, but
that's not inheritance.

  Inheritance should always happen like that, from a more abstract
concept to a more specialized concept. You should always be able
to say that the derived class "is a" base class. If you can't say
that, then you have a flaw in your OO design.

  For example, if you want a 'Car' class having a 'Motor', inheriting
'Car' from 'Motor' would be a flawed OO design because 'Car' *is not*
a 'Motor'.
  In this case 'Car' *has a* 'Motor', so compositionality is the tool
to use.

  Of course all this is very basic OO stuff which should be clear to
everyone making object-oriented design and programs.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   I may be unusually dumb today, but I did not understand anything of that.

> I'm saying that if an object's lifetime is controlled by code outside 
> the object, then you have lost the modularity. Objects are no longer 
> independent reusable items.

  Well, that's a question of good modular design. I still don't understand
how it is related to whether a specific language is OO or not.

> Not at all. I'm making a point about languages that don't do memory 
> management aren't OO, exactly because then you no longer have modules.

  So are you saying C++ is not an OO language because it doesn't have
an automatic memory management system?

> >   Modules are an essential tool for encapsulation and abstraction.
> > You simply can't have objects if you don't have modules.

> However, the term "module" is so vague as to be useless. Is UCSD Pascal 
> "modular"? How about machine code? What if each object is in a separate 
> process, so the only communication between them really is "message 
> passing", yet each object is written in a language without modules?

  Defining a module is rather simple: A module is an encapsulated entity
which has a state defined by its member attributes and a public
interface to handle that state.

  In a good OO language the state of the module can (or even better, must)
be private to the module (ie. not accessible from outside the module),
and can be handled only through the public interface.

  A module might not have a state at all (if it doesn't have any
member attributes) but it can have if needed.

  You can have instances of modules and each instance can have its own
state (independent of the other instances). These instances are called
objects.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message