And what the **** has all this to do with object orientedness?

  It seems to me that most people have a misleading concept on what object
orientedness really means.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Abe Heckenbach wrote:

>    6. why not give each object, including group objects, and cameras a
> name, so it can be easily referenced later(so it can be removed, moved,
> scaled, change properties like color...(animator's might like this;>)

This is in the direction of OO-features in the scene language - a popular(?)
topic in these groups. I think what you're thinking of is something like
this:

#declare Foo=difference{
  box{1,-1}
  union{
    sphere{0, 0.5 translate x*1}
    sphere{0, 0.5 translate x*-1}
  }
}

#declare Foo.subobject[1].subobject[0].scale=2;
#declare Foo.subobject[1].subobject[1].location=<-1,1,0>;
#declare Foo.pigment=color{rgb 1};
// etc.

This is exactly the type of features I'd like to see as well - BUT, not for
the price of leaving backwards-compability behind.

(See my longer post in the "Object oriented POV scene language?" thread.)

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration


Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse

Post a reply to this message

Mikael Carneholm wrote:

> (See my longer post in the "Object oriented POV scene language?" thread.)
>

Oops...forgot to mention that it's in povray.programming.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration


Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse

Post a reply to this message

What would be the advantage of transforming subobjects after the CSG has
been declared?
  I think that internally povray would have to create a whole new object
anyways for this.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:

>   What would be the advantage of transforming subobjects after the CSG has
> been declared?
>

I think the main advantage of OO (from my point of view) would be _reading_
the location/rotation/scale etc. of objects, instead of (as in the example):
setting the values. Of course, there are also situations when setting the
values of object attributes should be useful, but this (rather meaningless)
example was what I could come up with at the spur of the moment. :)

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration


Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse

Post a reply to this message

>I think the main advantage of OO (from my point of view) would be
_reading_
>the location/rotation/scale etc. of objects

I don't think that will work.  If I'm not mistaken, POV-Ray builds a
transform matrix for each tranformation and keeps multiplying these, so
in the end you'll be lucky for the program to spit out one matrix in the
end.

-Mike

Post a reply to this message

In povray.general Mikael Carneholm <sa9### [at] idautbhbse> wrote:
: I think the main advantage of OO (from my point of view) would be _reading_
: the location/rotation/scale etc. of objects, instead of (as in the example):
: setting the values.

  Sorry for whining, but you (and apparently everyone else) keep calling
this object oriented although it isn't.
  Yes, this is an essential part of an object oriented language, but it's
not object oriented in itself.
  What you are talking about are modules. A programming language can use
modules without being an OO language (for example modula2 is one of those).
These languages have modules which have member functions and member variables,
public and private parts and so on. This, however, is not yet OO.
  For a programming language to be OO it has to have modules as in any
modular language AND it has to have support for inheritance, dynamic binding
and polymorphism. A program is object oriented when it uses these features
(mainly inheritance and dynamic binding). Else it just uses modules.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:

>   Sorry for whining, but you (and apparently everyone else) keep calling
> this object oriented although it isn't.
>   Yes, this is an essential part of an object oriented language, but it's
> not object oriented in itself.
>   What you are talking about are modules. A programming language can use
> modules without being an OO language (for example modula2 is one of those).
> These languages have modules which have member functions and member variables,
> public and private parts and so on. This, however, is not yet OO.
>   For a programming language to be OO it has to have modules as in any
> modular language AND it has to have support for inheritance, dynamic binding
> and polymorphism. A program is object oriented when it uses these features
> (mainly inheritance and dynamic binding). Else it just uses modules.

Who said OO-POV shouldn't allow inheritance and polymorphism? If the examples in
my long post does not look like inheritance and polymorphism to you, I apologize.
But, for clarity, here they are, again:

// A "base class" (object) for our worm:
#declare worm_part1=sphere{
 0, 0.5
 pigment{color rgb 1}
 ref{next}  // tells POV that this object has a reference, called "next"
}

// Inheritance...don't you think, Warp? :)
// IDENTIFIER = like ANCESTOR, or actually: SUBOBJECT = like SUPEROBJECT (is
"from" better than "like" maybe?)
#declare worm_part2=like worm_part1{
  pigment{color rgb 0}  // leaves everything like worm_part1, except the pigment.
}

// references can also be declared to "point" to a certain objects from the start:

#declare worm_head=sphere{
 0, 0.5
 texture{some_texture}
 ref{next, worm_part1} // REFNAME [,OBJECT]
}

// Changing the reference of worm_part1:
#declare worm_part1.next=worm_part2;

// Let's create an explicit reference:
#declare temp_ref=ref{worm_head};

// All references are nil:ed from start (if no reference object is
given), so we now can do this:
#while(temp_ref<>nil)
 #declare temp_ref.location = temp_ref.location + <1,0,0>;
 #declare temp_ref=temp_ref.next;
#end

....and this last block would be polymorphism, don't you think, Warp? Well of
course, we don't call common-named methods with different implementations here (as
the well taught OO student points out), but the <object>.location expression is
referencing different object types with common attribute names.

And another thing: OO in POV should be easy enough for everyone to use - one
should not have to study OO theory in order to use it. That's the reason for the
somewhat "crippled" implementation of OO suggested here.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration


Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse

Post a reply to this message

In povray.general Mikael Carneholm <sa9### [at] idautbhbse> wrote:
: // IDENTIFIER = like ANCESTOR, or actually: SUBOBJECT = like SUPEROBJECT (is
: "from" better than "like" maybe?)

  Perhaps the best name would be "is_a".

  1. Inheritance (at least public inheritance) is always an "is a" relation.
The inherited class "is a" base class.
  For example if we have a base class Vehicle and we inherit a class Car from
it and then we inherit a class Opel from it, the "is a" relation is clear:
  Opel is a Car, and Car is a Vehicle.

  2. The "is a" relation means that an instance of the derived class can be
used anywhere an instance of the base class is used. This means that the
derived class must contain all the functionality of the base class.

  The second note is important. Sometimes one can do bad inheritance if only
the first thing is taken into account. For example one could think that
a Circle "is a" Ellipse so one could (wrongly) make an Ellipse base class and
inherit a Circle class from it. However, a Circle does not have the same
functionality as the Ellipse (eg. you can't set two radiuses).

  It is considered bad OO design to inherit from another class only to make
a "copy" of that class with some modification. For example if I have the
class IceCream, which describes a chocolate ice cream and then I inherit
a StrawberryIceCream from it, to make a similar ice cream, but with
strawberry flavor, that's bad OO design.
  The correct way is to make a (possibly abstract) base class IceCream and
then inherit different flavored classes from it, eg. ChocolateIceCream and
StrawberryIceCream. Now there's a true "is a" relation between inherited
and base classes.

  Why do I write all this? Because I didn't like your example:

: #declare worm_part2=like worm_part1{
:   pigment{color rgb 0}  // leaves everything like worm_part1, except the pigment.
: }

  You are making a strawberry ice cream from a chocolate ice cream here :)

: ....and this last block would be polymorphism, don't you think, Warp? Well of
: course, we don't call common-named methods with different implementations here (as
: the well taught OO student points out), but the <object>.location expression is
: referencing different object types with common attribute names.

  That's not polymorphism, it's dynamic binding.
  Yes, a true OO feature.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <399CFECD.630F8C9C@ida.utb.hb.se>, sa9### [at] idautbhbse 
wrote:

> I think the main advantage of OO (from my point of view) would be 
> _reading_ the location/rotation/scale etc. of objects...
...snip...

This won't be possible, even with member variables and macros. 
Transformations(scale, rotate, translate, matrix) are all stored in a 
4*4 matrix, and what would "location" mean? The center of the bounding 
box?

BTW, I would prefer a #reference keyword to your ref {} syntax, it could 
be used outside of objects. Maybe a specific members {} block in objects 
would be a good idea, though...
object {...
    members {
        #reference Next = object {...};// a reference
        #declare Velocity = < 1, 5, 0>;// a public variable
        #local Speed = vlength(< 1, 5, 0>);// a protected variable
        #macro GetSpeed() Speed #end // a member macro
    }
}

All objects would already have public transform and material member 
variables and member macros for operating on them(you could arrange all 
objects in a heirarchy, with "object" being the base object, so the 
language is consistent, but of course, these would be hard-coded...). In 
addition to these inherited members, objects would have variables 
specific to them: spheres would have a "center" vector and a "radius" 
float, boxes would have "point_a" and "point_b" vectors...this would 
allow the current syntax to be retained, but make things easy to do with 
the OO syntax.

BTW, I think the biggest advantage of OOP scripting would be things like 
macros and include files that really emulate objects. You could create a 
"lens flare" object, and have as many of these as you wanted, and it 
would be almost completely transparent to the person using the lens 
flares. Or you could do particle systems, tree/plant objects, 
etc...using them could be much easier than with macros and include 
files, especially when you have many of them.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message