In article <Xns94937169A2BACseed7@news.povray.org>,
 ingo <ing### [at] tagpovrayorg> wrote:

> If I want to read and understand those future OO-scenefiles, I'll have to 
> learn the new features. "Use" is more than just writing scenes.

And reading and understanding the ugly, complex hacks used to work 
around the lack of object oriented features would be easier?

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

andrel wrote:

> is better left out. At this point I cannot judge very well because I
> still have no good perception of how an OOPOV would look, but perhaps

There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?

Post a reply to this message

Tom Melly <pov### [at] tomandlucouk> wrote:
> There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?

  If it were solely up to me, it would look as much as C++ as possible.

  However, it's not up to me. (Fortunately? ;) )

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

"Tom Melly" <pov### [at] tomandlucouk> wrote in message
news:4033cd07@news.povray.org...
> andrel wrote:
>
> > is better left out. At this point I cannot judge very well because I
> > still have no good perception of how an OOPOV would look, but perhaps
>
> There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?

I'm sorry; I know you didn't ask me. I have some ideas of how it could look:


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

show red_sphere
show green_sphere


Off the top of my head, I could see this being useful. You could also do
this:

red_sphere.pigment.color = new Color.White

which you can't do right now.

Post a reply to this message

In article <cjameshuff-9D70B1.13425418022004@news.povray.org>, 
cja### [at] earthlinknet says...
> In article <4032CB5A.9277B9BA@pacbell.net>, Ken <tyl### [at] pacbellnet> 
> wrote:
> 
> > Not me. It would add another layer of complexity that I don't want to have
> > to bother to learn. OO is for programming not a scene description language.
> > If I wanted to learn programming I would do that rather than using POV-Ray.
> 
> You only say that because you don't know what it would add. It would not 
> add complexity, it would greatly simplify many things.
> 
> 

I am seriously confused about what it would simplify... SDL already does 
most everything that OO stuff can. The one and only thing I can think of 
is the ability to over-ride specific attributes, the way you can replace 
an existing function in an object with a new one:

#define Motorcycle1 = object {Motorcycle}

object {
  Motorcycle1 {
    #replace Motorcycle1.Handlebars.texture{blah....}
  }
}

So you could start with an entirely prebuilt object and change any single 
item in it by directly replacing that item. However, for it to work, each 
individual object would need a unique name or you would need to have some 
way to index which of the objects in a CSG you are applying the changes 
to or adding/removing.

Is the above sort of what you are talking about? Because otherwise I 
don't get what OO feature you are talking about that the SDL doesn't 
already support in some fashion...

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Dan P wrote:

> "Tom Melly" <pov### [at] tomandlucouk> wrote in message
> news:4033cd07@news.povray.org...
> 
>>andrel wrote:
>>
>>
>>>is better left out. At this point I cannot judge very well because I
>>>still have no good perception of how an OOPOV would look, but perhaps
>>
>>There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?
> 
> 
> I'm sorry; I know you didn't ask me. I have some ideas of how it could look:
> 
> 
> 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))
> 
> show red_sphere
> show green_sphere

I do not see why the current syntax with macros does not suffice here.

> 
> Off the top of my head, I could see this being useful. You could also do
> this:
> 
> red_sphere.pigment.color = new Color.White
Well if it allows you to have an object that is called red_sphere but
is actually white then we are in deep trouble.

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

Post a reply to this message

"Christopher James Huff" <cja### [at] earthlinknet> wrote
> In article <Xns94937169A2BACseed7@news.povray.org>,
>  ingo <ing### [at] tagpovrayorg> wrote:
>
> > If I want to read and understand those future OO-scenefiles, I'll have to
> > learn the new features. "Use" is more than just writing scenes.
>
> And reading and understanding the ugly, complex hacks used to work
> around the lack of object oriented features would be easier?

Or understanding entries to the short code contest? ;)

But seriously, I've seen plenty of scene files where I don't have a clue what's
happening, like where they use some feature of pov that I've never seen before.
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.

Though I do think OO would run the risk of getting too far away from the SDL
being a language to describe scenes (objects that are conceptual not visible!?).

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

I think there's a lot of confusion between OO objects and pov's object {}. I
never intended for the two to be the same thing.

What I need for my scene is the concept of a data structure which can hold a
series of "function" calls (actually macro calls) according to what type of
structure it is. It does not need to be associated with anything renderable.
This just extends the range of possibilities for how pov's macro language can be
used to perform calculations or procedural scene generation, etc.

I can see some uses for having OO objects associated with pov objects, but I
think it would REALLY defeat the point if you are forced to have that
association. For example, you could create a tree using an object that creeps
along the trunk, leaving a trail of spheres, then spawns another object for each
branch, etc... so there would be many more spheres than there are OO objects.

Anyway, just my 2 cents. I'm gonna get on and write my macros :)

-- 
Tek
www.evilsuperbrain.com


"Patrick Elliott" <sha### [at] hotmailcom> wrote in message
news:MPG.1a9d8de2d9dc8dc39899ad@news.povray.org...
> In article <cjameshuff-9D70B1.13425418022004@news.povray.org>,
> cja### [at] earthlinknet says...
> > In article <4032CB5A.9277B9BA@pacbell.net>, Ken <tyl### [at] pacbellnet>
> > wrote:
> >
> > > Not me. It would add another layer of complexity that I don't want to have
> > > to bother to learn. OO is for programming not a scene description
language.
> > > If I wanted to learn programming I would do that rather than using
POV-Ray.
> >
> > You only say that because you don't know what it would add. It would not
> > add complexity, it would greatly simplify many things.
> >
> >
>
> I am seriously confused about what it would simplify... SDL already does
> most everything that OO stuff can. The one and only thing I can think of
> is the ability to over-ride specific attributes, the way you can replace
> an existing function in an object with a new one:
>
> #define Motorcycle1 = object {Motorcycle}
>
> object {
>   Motorcycle1 {
>     #replace Motorcycle1.Handlebars.texture{blah....}
>   }
> }
>
> So you could start with an entirely prebuilt object and change any single
> item in it by directly replacing that item. However, for it to work, each
> individual object would need a unique name or you would need to have some
> way to index which of the objects in a CSG you are applying the changes
> to or adding/removing.
>
> Is the above sort of what you are talking about? Because otherwise I
> don't get what OO feature you are talking about that the SDL doesn't
> already support in some fashion...
>
> -- 
> void main () {
>   If Schrödingers_cat is alive
>     call functional_code()
>   else
>     call crash_windows();
> }

Post a reply to this message

"andrel" <a_l### [at] hotmailcom> wrote in message
news:403### [at] hotmailcom...
>

> > "Tom Melly" <pov### [at] tomandlucouk> wrote in message
> > news:4033cd07@news.povray.org...

<snip />

> > red_sphere.pigment.color = new Color.White
> Well if it allows you to have an object that is called red_sphere but
> is actually white then we are in deep trouble.

Heheh :-)

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

Could do red_sphere.pigment.image_map.file and stuff too. Any level of
indirection. OO gives smarter people than I the ability to do things I'd
never dream of with it. The more flexible the code can be, the more people
will find ways to do new, interesting stuff.

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> new ColoredSphere
> new ColoredSphere

> new Color.White

  Aaargh! No, no and no.

  The fact that you must fill your code with the 'new' keyword in Java does
not mean it's a good thing.
  Why force the user to do that? In all those cases the 'new' keyword is
obsolete. It contributes nothing to the code.

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

Patrick Elliott <sha### [at] hotmailcom> wrote:
> I am seriously confused about what it would simplify... SDL already does 
> most everything that OO stuff can.

  It certainly does not.

  One of the basic features of an object-oriented language are modules.
  A module (in OO languages usually called a class) has a state (defined by
its attributes, ie. member variables) which can be modified with the methods
(ie. member functions) of the module. In well-designed OOP the state of the
module is private and can only be modified through the public methods (the
principle of abstraction, an extremely important principle in good
programming).
  You can create instances of modules, and modules can have other modules
or references to other modules (even of its own type) as attributes. (Among
tons of other things, it allows you to make eg. linked lists of module
instances.)

  A second basic feature of an OO language is inheritance. You can create
a new module which implements everything some other module implements
plus more (this is usually called specialization).
  Among other things, inheritance allows making more abstract, generic
functions to handle different types of modules (given that they have been
inherited from a common base class).
  Some modules may even be defined as abstract, meaning that they can't be
instantiated directly (because it wouldn't make any sense) but must be used
through inheritance.

  A third basic feature, related to inheritance, is dynamic binding. You
can declare virtual functions in a base class which the inherited classes
can implement. When a function having only a base class reference calls
this virtual function, the proper inherited function is called (even
though the caller doesn't have any knowledge about the inherited classes).

  The POV-Ray SDL does not implement anything of this.

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

Warp wrote:

> (the principle of abstraction, an extremely important principle in good
> programming).

I rest my case.

-- 
Ken Tyler

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:40348068@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > new ColoredSphere
> > new ColoredSphere
>
> > new Color.White
>
>   Aaargh! No, no and no.
>
>   The fact that you must fill your code with the 'new' keyword in Java
does
> not mean it's a good thing.
>   Why force the user to do that? In all those cases the 'new' keyword is
> obsolete. It contributes nothing to the code.

I see what you're thinking of on this. I think it is there for clarity -- 
the compiler could always check to see what has been defined and decide to
either create a  new class there or use the reference. I believe (and this
is just a personal thing) that the readability of the code is just as
important as the execution of the code because, even if you write a program
in a vacuum without anybody else seeing it, /you/ still have to look at your
code later. Thing is, I see people write really hard-to-read code often and
I figure it could be: a. they don't want you to understand their code, b.
they think it will go magically faster if it is all scrunched together and
the variable names are shorter, c. they want to put as much on the screen as
they can, d. their fingers really hurt and typing causes physical distress,
e. they are so amazingly smart that they can instantly conceptualize the
code no matter how obfuscated it is, or f. they just have bad habits and
don't care. I'm guessing f. :-)

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> I see what you're thinking of on this. I think it is there for clarity -- 
> the compiler could always check to see what has been defined and decide to
> either create a  new class there or use the reference.

  The reference to what?
  The thing after 'new' is a type. How can you make a reference to a type?
Where should the reference point to?

  You can make your scripting language interpreter so that instances are
always created dynamically for simplicity (that way you don't have to
make the distinction between a local variable and a reference because
everything is a reference, like in Java). However, the 'new' keyword
does not contribute anything to this. It's obsolete and can be
completely left out without the expressive power of the language
being degraded.

  Have you ever wondered why you are not forced to define all your
objects in POV-Ray inside object{} blocks, why you are not forced to
put all your material and texture statements into material{} and
texture{} blocks, etc?
  Because forcing the user to write something unnecessary is only
a burden, not a help.

  Even more, object{}, material{} and texture{} are sometimes necessary.
However, I can't imagine a situation where 'new' would be necessary
(assuming we are dealing with a language where all class instances
are created dynamically, as 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

Darren New <dne### [at] sanrrcom> wrote:
> >   One of the basic features of an object-oriented language are modules.

> FWIW, there are many modular languages that aren't OO.

  So?
  I didn't say modules are a sole feature of OO languages. I said that
modules are a minimum requirement for a language to be OO.

  A good example of a modular language which is not OO is modula. It has
modules (created not very surprisingly with the keyword 'module') which
contains member variables, member functions, private and public parts, etc.
However, since it does not have (AFAIK) inheritance and dynamic binding
it's not an OO language, only a modular one.

> >   A second basic feature of an OO language is inheritance.

> FWIW, there are many OO languages that don't support inheritance.

  Then they are not object-oriented languages. Some kind of inheritance is
a basic feature of object-oriented languages.
  The whole idea of object-orientedness is that you can have a hierarchy
of objects (from more abstract to more specific). If you can't build such
hierarchy, then it's not object oriented.

> Inheritance is something different, designed to 
> allow you to share code between different parts of your program, to ease 
> maintenance.

  Nope, that's a way too narrow way of defining inheritance.

  It's true that inheritance can (and should) be used to group common
code into a single module. However, that's not the only (and depending
on who you ask not even the most important) reason for inheritance.
  There are other ways of grouping common code into single modules,
such as composition (ie. a class having another class as member variable).
You don't necessarily need inheritance for this.

> >   A third basic feature, related to inheritance, is dynamic binding. 

> Dynamic binding is not really necessarily related to inheritance, and 
> vica versa. That's just an artifact of how popular OO languages handle it.

  Lack of dynamic binding would make inheritance more or less obsolete.
If you are going to use inheritance without dynamic binding you could
as well use compositionality instead.

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

"Warp" <war### [at] tagpovrayorg> wrote in message
news:40350372@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > I see what you're thinking of on this. I think it is there for
clarity -- 
> > the compiler could always check to see what has been defined and decide
to
> > either create a  new class there or use the reference.
>
>   The reference to what?
>   The thing after 'new' is a type. How can you make a reference to a type?
> Where should the reference point to?

I made everything objects. I don't know what I was thinking there, though -- 
it should be new Color(Color.White), not new Color.White. I'm braindead
today.

>   You can make your scripting language interpreter so that instances are
> always created dynamically for simplicity (that way you don't have to
> make the distinction between a local variable and a reference because
> everything is a reference, like in Java). However, the 'new' keyword
> does not contribute anything to this. It's obsolete and can be
> completely left out without the expressive power of the language
> being degraded.

To create the object dynamically without the new keyword, the interpreter
would need to look up whether what proceeds it is a Class or something that
the user already defined. That would not effect small scenes, but in scenes
with hundreds of thousands of objects, it would show in the parse time. By
using new, the interpreter /knows/ that what follows it is a class.

>   Have you ever wondered why you are not forced to define all your
> objects in POV-Ray inside object{} blocks, why you are not forced to
> put all your material and texture statements into material{} and
> texture{} blocks, etc?

Nope. You're right -- object is implied.

>   Because forcing the user to write something unnecessary is only
> a burden, not a help.
>
>   Even more, object{}, material{} and texture{} are sometimes necessary.
> However, I can't imagine a situation where 'new' would be necessary
> (assuming we are dealing with a language where all class instances
> are created dynamically, as in Java).

I think it would be a really good idea to make everything an instance of a
class. I'm thinking more like Smalltalk where there are no primitives
(that's what I was thinking when I did the Color.White screw-up -- no
primitives). If the parser is written correctly, this should not affect
parse time. However, what I was thinking was more something that isn't like
a scripting language, but instead, enables structured OO programming for
complex logic and true abstraction.

Post a reply to this message

>   Then they are not object-oriented languages. Some kind of inheritance is
> a basic feature of object-oriented languages.

I'm not entirely sure that's true. The concept of an object does not implicitly
require inheritance, since the principles of modularity with private states etc
can still apply, and as such a language can be oriented about objects without
needing inheritance. Though all the OO languages I know of do have inheritance.

I'm trying to thing back to the OO analysis and design course I did on my
degree, but I can't honestly remember whether it considered inheritance to be
fundamental to OO...

> > Inheritance is something different, designed to
> > allow you to share code between different parts of your program, to ease
> > maintenance.
>
>   Nope, that's a way too narrow way of defining inheritance.
>
>   It's true that inheritance can (and should) be used to group common
> code into a single module. However, that's not the only (and depending
> on who you ask not even the most important) reason for inheritance.

I agree. For example, the only reason I'm planning to implement inheritance is
so that I can have an interface class with virtual functions. No shared code
whatsoever.

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> To create the object dynamically without the new keyword, the interpreter
> would need to look up whether what proceeds it is a Class or something that
> the user already defined. That would not effect small scenes, but in scenes
> with hundreds of thousands of objects, it would show in the parse time. By
> using new, the interpreter /knows/ that what follows it is a class.

  Believe it or not, there are faster ways of searching than linear search.

  Even if you have 4000 millions of names, you can find a specific one
by doing at most 32 comparisons.
  In the same way, adding a new name to the set of existing names requires
at most 32 comparisons and other operations.

  Besides, what does it help to tell the interpreter that "what follows is
a type"? By that you can at best just cut the amount of items to search
to half (to 2000 millions in the example above).

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

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

Tek <tek### [at] evilsuperbraincom> wrote:
> >   Then they are not object-oriented languages. Some kind of inheritance is
> > a basic feature of object-oriented languages.

> I'm not entirely sure that's true. The concept of an object does not implicitly
> require inheritance, since the principles of modularity with private states etc
> can still apply, and as such a language can be oriented about objects without
> needing inheritance. Though all the OO languages I know of do have inheritance.

  Don't confuse modules with object-orientedness.

  As I explained previously, modules are a minimum but not sufficient
requirement for an OO language.
  If you have modules with no inheritance and no dynamic binding what
you have is a modular language, not an OO one. Modula3 is an example of
this.

> I agree. For example, the only reason I'm planning to implement inheritance is
> so that I can have an interface class with virtual functions. No shared code
> whatsoever.

  So basically you will have interfaces (such as in Java) but no inheritable
classes?
  The problem with that is that it forces code repetition, which is not
good (IMHO this is a bad problem in Java interfaces). Besides forcing the
user of the interface to implement things which may be useless, it makes
it too easy to break the true "is-a" relation between base and derived
classes (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).

-- 
#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:
> >   Then they are not object-oriented languages. Some kind of inheritance is
> > a basic feature of object-oriented languages.

> This isn't correct. There are, for example, delegation-based OO 
> languages, wherein you say "Anything I don't handle, that other class 
> over there handles", but it's not an inheritance heirarchy as such. It's 
> merely delegation.

  Who defines that object-orientedness may not have inheritance?

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

> No, this is not correct. While it's true that most popular 
> object-oriented languages support inheritance, you can have OO languages 
> without inheritance.

  In what basis can you call it an OO language?
  Having modules is not sufficient.

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

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

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

"Warp" <war### [at] tagpovrayorg> wrote in message
news:4035e6de@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > To create the object dynamically without the new keyword, the
interpreter
> > would need to look up whether what proceeds it is a Class or something
that
> > the user already defined. That would not effect small scenes, but in
scenes
> > with hundreds of thousands of objects, it would show in the parse time.
By
> > using new, the interpreter /knows/ that what follows it is a class.
>
>   Believe it or not, there are faster ways of searching than linear
search.

Yep, I know; I spent an entire summer building AVL trees and heaps. But it
is /still time/ and, in a loop, that time adds up.

>   Even if you have 4000 millions of names, you can find a specific one
> by doing at most 32 comparisons.
>   In the same way, adding a new name to the set of existing names requires
> at most 32 comparisons and other operations.

32 comparisons for /one lookup/. Multiply that by, say, 100,000 lookups for
fur.

>   Besides, what does it help to tell the interpreter that "what follows is
> a type"? By that you can at best just cut the amount of items to search
> to half (to 2000 millions in the example above).

In a loop, that makes a difference.

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

I think everything should have been. It was just a programmer's decision to
do that, probably because of their C/C++ experience. However, it is
certainly true that if all primitives were represented by a class, it would
take more memory, and even though it might only take a slight bit more
memory, with hundreds of thousands of instances that can show as well so it
might be a good idea to use primitives in a ray-tracing context anyway.

Post a reply to this message

"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

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

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

> Tom Melly <pov### [at] tomandlucouk> wrote:
> > There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?
> 
>   If it were solely up to me, it would look as much as C++ as possible.
> 
>   However, it's not up to me. (Fortunately? ;) )

Very much so... ;-)

POV OO doesn't have the same needs, so it could be simplified quite a 
bit. No need to have any static binding, for one thing. Dynamic typing, 
much less worrying about what type something is. No need for multiple 
inheritance. Forget about templates, don't need pointers, don't need 
primitive types. Pass everything by reference, don't need explicit pass 
by reference. Just straight public inheritance, probably with categories 
and interfaces. I'm undecided about private/protected access. They would 
be a good thing to have from the language design point of view, but 
aren't really necessary...

-- 
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 <40362976$1@news.povray.org>,
 "Dan P" <dan### [at] yahoocom> wrote:

> >   In the same way, adding a new name to the set of existing names requires
> > at most 32 comparisons and other operations.
> 
> 32 comparisons for /one lookup/. Multiply that by, say, 100,000 lookups for
> fur.

And you end up doing 3200000 comparisons, which really won't take long. 
Photon mapping can handle similar searches through millions of photons 
for several lighting calculations per pixel, and still render an image 
with 768K pixels in reasonable time. And that's if it can't figure out 
you're using a type some other way.


> I think everything should have been. It was just a programmer's decision to
> do that, probably because of their C/C++ experience. However, it is
> certainly true that if all primitives were represented by a class, it would
> take more memory, and even though it might only take a slight bit more
> memory, with hundreds of thousands of instances that can show as well so it
> might be a good idea to use primitives in a ray-tracing context anyway.

But we (well, most of us) aren't going to be doing heavy raytracing with 
this language...just specifying a scene for a C++ engine to render. The 
overhead for these things is nothing compared to the overhead of the 
current parser...it could be made much faster and still have the 
flexibility and simplicity of runtime lookups.

-- 
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 <40363a68@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Color myColor(.1, .2, .3);
> 
>   (Instead of "Color myColor = Color(.1, .2, .3);")
> 
>   No need for 'new', and there's no ambiguity.

I think you meant "redundancy"...this is something that really annoys me 
about Java, and about C++ pointers. Though the syntax I favor is more 
like:

def myColor: Color(0.1, 0.2, 0.3);

No more redundant typing, but it always starts with the same keyword, so 
it's a little easier to read.


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

That's not a problem with C++ objects, why should it be a problem with 
Java objects? Or are you assuming that this "Objective-Java" would still 
lack operator overloading?

-- 
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 <4037b30f@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

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

Subclasses are often called derived classes. And "inherits" doesn't seem 
to fit as well...ColoredSphere doesn't inherit sphere, it inherits from 
sphere. And is_a seems to fit better as a boolean:

if(ColoredSphere is_a sphere)
    ...do something...

Or you could do what java does, and use "extends", but that doesn't 
really fit with what I wrote, which declares the class as a value. Maybe 
"extend" would work, but it seems too close to "extends", people coming 
from Java would mistype it a lot. Of course, you could eliminate the 
keyword altogether:

class ColoredSphere: sphere {...

-- 
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:
> don't need primitive types.

  I disagree with this. (Unless you are ready to add operator overloading.)

> Just straight public inheritance, probably with categories 
> and interfaces.

  I have no idea what "categories" are, but interfaces are obsolete.
If you want to make an "interface", just make an abstract class.

> I'm undecided about private/protected access. They would 
> be a good thing to have from the language design point of view, but 
> aren't really necessary...

  They are necessary, believe me... ;)

  I would even go so far that member variables are always private (ie.
you *can't* make them public).
  If this is too drastic, then the language would work so that a public
member variable can be moved to the private part and overloaded with
an accessor method (which is used in the same way as when accessing
the variable directly).
  That is, if you had this: class Foo { public: int i; };
you can now replace it with something like:
class Foo { public: int i(); private: int i_; }
  Accessing 'i' would still be the same (ie. eg. "instance.i") but after
the change it calls the method i() instead of reading the variable
directly.
  (For this to work you need to be able to call a method taking no
parameters without parentheses, which shouldn't be any problem.)

  (The idea of all this is, of course, that you can later change
the implementation of 'i' without breaking potentially tons of code.)

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

In article <40369dc3@news.povray.org>, war### [at] tagpovrayorg says...
> 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 it can happen. In VB you can define something as passed ByVal or 
ByRef. ByRef means it will directly manipulate the originally object. 
There are times you want to do this, though it would be patently stupid 
to do so in a case where it was even possible to have more than two 
processes manipulating the same object at the same time.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Patrick Elliott <sha### [at] hotmailcom> wrote:
> But it can happen.

  Of course it can happen. And it can also happen that a function
named "multiply" calculates the square root. But that doesn't mean
it's not avoidable. It just means the design of the program/library
has a flaw.

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

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

> Christopher James Huff <cja### [at] earthlinknet> wrote:
> > don't need primitive types.
> 
>   I disagree with this. (Unless you are ready to add operator overloading.)

I am. I definitely would want operator overloading. I've never seen a 
good argument against it..."you can make the plus operator multiply" is 
not a good argument. I can make a "plus()" method that multiplies as 
well...I can also do a lot of useful things with the ability to use 
operators with my own types.


> > Just straight public inheritance, probably with categories 
> > and interfaces.
> 
>   I have no idea what "categories" are,

Additions to the interface of a class after the main class has been 
defined. For example, a vector class may have an OpenGL category that 
implements methods useful for using vectors with OpenGL, but which isn't 
part of the core functionality of the class, and which does not work as 
a subclass.


> but interfaces are obsolete.
> If you want to make an "interface", just make an abstract class.

Interfaces are not obsolete. As for abstract classes...what are you 
talking about?


> > I'm undecided about private/protected access. They would 
> > be a good thing to have from the language design point of view, but 
> > aren't really necessary...
> 
>   They are necessary, believe me... ;)

Sorry, but I don't. I've never accidentally tried to access a private 
member. They do serve a documentation purpose, but IMO if a language has 
them, they should be defined in a separate place, with only the public 
interface in a header file. But for POV, this would be too restrictive 
and complex, IMO.


>   I would even go so far that member variables are always private (ie.
> you *can't* make them public).

I wouldn't care for this. Think of vector member access...vec.x, vec.y, 
etc...vec.x() just adds more visual noise.


>   If this is too drastic, then the language would work so that a public
> member variable can be moved to the private part and overloaded with
> an accessor method (which is used in the same way as when accessing
> the variable directly).

I have some misgivings about the idea of accessor methods of this type, 
though it makes more sense if you have no public variables. I've 
considered this approach for Ember, which could (eventually) optimize 
the overhead away.


> class Foo { public: int i(); private: int i_; }
>   Accessing 'i' would still be the same (ie. eg. "instance.i") but after
> the change it calls the method i() instead of reading the variable
> directly.

There's also a "modifier" feature I've seen...in Ruby, I think. 
Basically you define a "myMember=" method, and this:

myObject.myMember = foo;

is equivalent to:

myObject.myMember=(foo);

-- 
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 in message
news:cjameshuff-9C23F0.20475321022004@news.povray.org...
> I am. I definitely would want operator overloading. I've never seen a
> good argument against it..."you can make the plus operator multiply" is
> not a good argument. I can make a "plus()" method that multiplies as
> well...I can also do a lot of useful things with the ability to use
> operators with my own types.

Well, I know a good argument against it. So good in fact that it's the reason
why every games programmer I know doesn't use operator overloading: It hides
processing.

i.e. when you compile a+b, you expect it to compile to a simple add instruction,
and these days most processors can do vector maths so I'd certainly support it
being used for them. The problem is if you've defined your own type of data that
has a "+" function, you incur the cost of a function call invisibly in your
code. This is a very bad thing for time-critical applications like computer
games. Things like this make optimising an absolute nightmare.

Of course, for less speed critical stuff like describing POV scenes, I'd
wholeheartedly support it. But I'm just saying there *is* a good argument
against it.

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

In article <403814c4$1@news.povray.org>, "Tek" <tek### [at] evilsuperbraincom> 
wrote:

> Well, I know a good argument against it. So good in fact that it's the reason
> why every games programmer I know doesn't use operator overloading: It hides
> processing.

So do functions.


> i.e. when you compile a+b, you expect it to compile to a simple add 
> instruction,

If I'm adding things that the processor can add.


> and these days most processors can do vector maths so I'd certainly support 
> it being used for them.

And that could be done, as well.


> The problem is if you've defined your own type of data that has a "+" 
> function, you incur the cost of a function call invisibly in your 
> code.

No I don't. I'd have to call that function anyway, so there is precisely 
zero overhead. Even if I was wrapping numeric types that the processor 
could work on directly, the compiler would inline the code, getting rid 
of the function call.


> Of course, for less speed critical stuff like describing POV scenes, I'd
> wholeheartedly support it. But I'm just saying there *is* a good argument
> against it.

I still haven't heard one yet.

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