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

Darren New <dne### [at] sanrrcom> wrote:
> >   You can create a new 'Dog' instance using the info in "mom" Dog, but
> > that's not inheritance.

> No, that's delegation, and it's a perfectly valid way of building an 
> object-oriented language with dynamic dispatch, modularization, and all 
> those other goodies. :-)

  Creating a new instance using the data from another instance is
certainly not delegation. It's just (partial) copying.

  If you make string a="abc"; string b=a; you are *copying* the
contents of a to b. That's not delegation.

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

> Yes, but the range of possibilities is wider when you start designing 
> object-oriented languages and paradigms.

  Sure you can misuse inheritance in all kind of ways, but that doesn't
mean all those wrong ways of using it are what inheritance was created
for.

-- 
#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:
> >   Well, that's a question of good modular design.

> Right. And if your language doesn't support modularization, it can't be 
> OO, right? :-)

  You don't need the compiler to have some automatic memory management
system in order for the language to be object-oriented.

> You can do OO programming in C++, by implementing your own memory 
> management.

  If you don't implement your own memory management that doesn't mean C++
is not an OO language. It just means your OO design is crappy, that's all.
  C++ is an OO language regardless of how someone uses it.

> Just like you can do OO programming in C by implementing 
> your own memory management and dynamic dispatch.

  You can simulate a kind of poor OO in C, but I would not call it
an OO language.
  For instance, C's "modules" (structs) can't have a public interface
and a private part and you must make quite ugly hacks to implement
dynamic binding and inheritance.

> >   In a good OO language the state of the module can (or even better, must)
> > be private to the module

> Which is exactly what the automatic memory management addresses.

  Now you completely lost me.
  What the h*** does the state of a module have to do with memory
management?

  I think you are *completely* misunderstanding what the state of
a module instance is.

-- 
#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:
> myWindow.setBitmap(myBitmap);

> Does the window have a pointer to my bitmap, or did it copy the bitmap 
> into its own instance variable? In the latter case, I can free my 
> bitmap. In the former case, I cannot. That's what the internal state of 
> a module (in this case an object instance) has to do with memory management.

  If you have to wonder about things like that, then the abstraction
level of the code is not good enough.

  But anyways, the state of an object is defined by the value of its
member attributes.
  Whether or not it uses pointers or whatever to handle memory and how
you should use the class for it to work properly is irrelevant.

  To better understand what the "state" of an object means, suppose
that you can ask a LivingEntity object "are you alive?" and it
returns true or false.
  One LivingEntity can be "alive" while another can be "dead". That
is their state (or part of it).
  *How* they internally implement this information is irrelevant.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

>   Don't confuse modules with object-orientedness.

Hmm... I just checked online and I failed to find a definition of OO which
doesn't mention inheritance, so it would appear you're right.

The thing is, my understanding was always that the fundamental part of OO is the
concept of objects, not class inheritance, hence it being called "object"
orientation, not "inheritance" orientation. I thought it was about the concept
of objects as instances of a class with associated methods, interfacing with
other objects. Modular code doesn't have instancing, at least not the way I
understand it, it just groups together associated functions and has similar
private/public philosphy.

Ah heck, I know what I want to do, and I'm gonna do it. People can classify it
later! :)

>   So basically you will have interfaces (such as in Java) but no inheritable
> classes?

No, my point is I don't need inheritance, though I think my system will be quite
capable of doing it (I've not got as far as coding that yet).

>   The problem with that is that it forces code repetition

It only forces code repetition if I want to share code, which I don't. I want to
share interfaces. Though I'll probably write some form of inheritance anyway.

> (in other words, when you make code which handles objects of
> the type of a certain interface you just have to trust that the inherited
> class implements all of its methods properly; you can't force a certain
> method to work always in a certain way).

good point, though my specific problem will only implement methods for things
that are different between objects, I'm going to allow public variables in the
interface class so the code that's processing the objects can just perform
standard manipulations itself. Not true OO philosphy, of course, but it gets the
job done, which is after all why I'm doing any of this!

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

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

>   The "is-a" (and "has-a") relation between classes is a fundamental
> property of object-orientedness.

Minor correction: classless OO languages exist (look at prototype based 
object oriented langauges), and they do have inheritance. Inheritance is 
a necessary aspect of OOLs...if it doesn't have inheritance, it isn't 
OO. Other requirements are polymorphism and encapsulation. Modular 
programming languages have encapsulation of some kind, but lack in one 
or both of the others.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <40343bd7@news.povray.org>, "Tek" <tek### [at] evilsuperbraincom> 
wrote:

> Sometimes I think it's worth reading the manual to find out what it does,
> sometimes I decide I'd rather not know. I don't think OO would make this much
> worse.


It would make it better...as Warp said, abstraction is a key feature of 
object orientation. Say someone makes a lens flare include. Internally 
it make use of all sorts of advanced tricks. You don't have to know a 
thing about that...you just use it as you would any other object.

Say you then decide you want to extend it somehow...make some aspect of 
the lens flares customized. You make a new object based on the lens 
flare object that does what you want. You don't have to know anything 
about how the lens flare object works to do this, you only have to know 
the methods by which you can interact with lens flare objects. The main 
point is that you don't have to worry about as many things at once. A 
side effect is that things get much, much shorter and simpler...instead 
of a long string of macro calls and includes, you put a few objects 
together.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <4033d465$1@news.povray.org>,
 "Dan P" <dan### [at] yahoocom> wrote:

> object ColoredSphere (v, c) inherits Sphere
> {
>     pigment
>     {
>         color = c
>     }
> }
> 
> object red_sphere = new ColoredSphere (<1, -2, 3>, new Color(1, 0, 0))
> object green_sphere = new ColoredSphere (<2, -2, 3>, new Color(0, 1, 0))

Ugh...don't blindly copy other langauges without understanding why they 
do the things they do. Your "new" statements are completely useless, 
they do nothing. Anyway, my idea of the syntax would be more like this:

def ColoredSphere: derive sphere {
    ColoredSphere(cent, rad, col) {
        sphere {cent, rad pigment {col}}
    }
}

def RedSphere: ColoredSphere {< 1,-2, 3>, 1, color < 1, 0, 0>}

ColoredSphere {< 1,-2, 3>, 1, color < 1, 0, 0>}

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <403### [at] hotmailcom>,
 andrel <a_l### [at] hotmailcom> wrote:

> Just kidding, I understand what you mean. My first reaction would be
> that pigments can be much more complicated than just a simple color.
> That is what POV makes exciting. I do not immediately see how you can
> handle that complexity in a understandable way. I will think about that
> (later).

This is not a problem. All pigments are pigments, but you can have solid 
pigments, patterned pigments with color maps, patterned pigments of 
pigments, etc...object orientation simply provides a clean way of 
classifying and managing the types of things.

red_sphere.pigment = solid_pigment {color rgb < 1, 0, 0>}

And now make it dark red:

red_sphere.pigment.color = color < 0.5, 0, 0>;

Or make it darker, no matter what color it currently is:

red_sphere.pigment.color *= 0.5;

Of course, trying to get the color of a patterned pigment is ridiculous, 
and would produce an error...POV would tell you that the pigment doesn't 
have a color. And if you want to get the color of a pigment at a certain 
point, you would do it the same way, without having to think about what 
kind of pigment it is. To use an example in current POV:

#declare MyObj = object {MyObj translate y*2}

This translates MyObj by y*2, no matter what MyObj is. It doesn't matter 
if it's a sphere or box. Now that's a bit awkward, an OO version would 
be more like:

MyObj translate: y*2;

or (Java/C++ style):

MyObj.translate(y*2);

Is that harder to understand? It simply translates MyObj, rather than 
redeclaring MyObj as a translated version of itself.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> def ColoredSphere: derive sphere {

  Is 'derive' any common OO term?

  The keyword I personally would like the most would be 'is_a', even
though I can be happy with just 'inherits'.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message