In article <403C146F.38604E10@tag.povray.org>,
 Ken <ken### [at] tagpovrayorg> wrote:

> How much program bloat will it add and how many people will be served by
> it? If it's just to provide a new toy, for a few dedicated programming
> enthusiasts, rather than to act as a significant improvement for the
> mainstream user, I don't think it is worth the effort.

Honestly, it won't add much bloat. And everyone who uses POV will be 
served by it, even if they don't use the features directly. It would 
make it easier for the programmer types to create extensions for POV 
(lens flares, for example), and make those extensions easier to use.

About the bloat issue: actually, it would be a good idea to replace the 
parser completely rather than trying to wedge OO features into this one, 
in which case the result could be much faster and more efficient than 
the present parser. And remember that non-programmers do use the work 
that programming enthusiasts create. The main point of object 
orientation is to make it possible to have a simple way to use complex 
things, without caring about the guts.

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

Okay, you obviously don't understand my point, so I'll try to come at it from a
different angle:

I'm sure you would agree there are some applications for which assembler is
better suited than smalltalk, right?

One is basically the lowest level of coding, the other is more or less the
highest.

But, most people don't use either! That's because both extremes have problems
caused by being too low level, or too high level.

All that I'm saying is that in my experience the games industry likes to be at a
slightly lower level than C++. Overloaded operators are one of the things we
prefer to do in the low-level way rather than the high-level way.

Obviously it compiles to the same code but so do all high level languages, it
all ends up as assembler in the end. It's just a question of what level you wish
to think & code at.

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

I heard Ken saying "average joe-blow" wasn't participating in this long
discussion, so I'm here.

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-01630D.22313524022004@news.povray.org...
> make it easier for the programmer types to create extensions for POV
> (lens flares, for example), and make those extensions easier to use.

I guess it could be, if I followed any of this talk at all.

> in which case the result could be much faster and more efficient than
> the present parser. And remember that non-programmers do use the work
> that programming enthusiasts create. The main point of object
> orientation is to make it possible to have a simple way to use complex
> things, without caring about the guts.

Simple can be good, but... What I'm imagining happening is that a simple
sphere might look like:

ThisSphere.sphere {<1,2,3>,1}

And continued usage (adding a color for example):

ThisSphere.color {<0.1,0.2,0.3,1,0>}

Where MySphere remains defined but gets additional info attached to it. Or
all at once:

ThisSphere.sphere.color {<1,2,3>,1,<0.1,0.2,0.3,1,0>}

Then raytraced when only the name stands alone:

ThisSphere

And so it's difficult to think of doing this for evermore complicated
things. Am I on the wrong track to believe this way? Such as, perhaps, Ken
has too? Apologies if I've gone astray but I had to reread much of this
thread again and i still am unsure of the potential OO-like SDL has, good or
bad.

Bob H.

Post a reply to this message

Tek <tek### [at] evilsuperbraincom> wrote:
> My point is that a+b takes a different length of time according to the types of
> a and b, where as MyMatrixAddFunction(a,b) takes the same length of time always,

  I would like to see a MyMatrixAddFunction() which adds two matrices
together and which takes the same length of time independently of how
big the matrices given as parameters are.
  That's a big like claiming that std::sort() always takes the same length
of time (even if you use it only with one type of parameters).

  Besides, it's not 100% sure that a function called "MyMatrixAddFunction()"
will always take the same amount of time because you can overload that
function name to do something else with some other types (in the exact
same way you can overload operators to do that).

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

Ken <ken### [at] tagpovrayorg> wrote:
> I am still unconvinced that the greater majority will be served by the
> addition of OO capabilities.

  They will.

  Learning to program OO programs is not the only way of benefiting from it.
It's obvious that if POV-Ray had a full-featured object-oriented scripting
language, only a few percentage of POV-Ray users would learn to use it at
its full strength.
  However, that doesn't mean only this small percentage will benefit from it.

  Having a good, full-featured OO language means that those hc programmers
can make better libraries which are more powerful and very easy to use.
If designed correctly, everyone can use these libraries without much
effort or learning, thus indirectly benefiting from the power of the
language.

  Think of it like this: You don't need to know how your fully graphical
operating system works internally: The hc programmers which made that OS
have already figured out the difficult parts for you and made a simple
user interface for you to benefit from these properties. Even though
you may not know how to program hardware and other types of low-level
things, you still are indirectly benefiting from it because someone else
made an easy-to-use interface to use it.
  However, these few hc programmers need the tools to make their programs.
If they don't have the tools, then everyone is on their own.

-- 
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 <403c3ec3$1@news.povray.org>,
 "Hughes, B." <omn### [at] charternet> wrote:

> > make it easier for the programmer types to create extensions for POV
> > (lens flares, for example), and make those extensions easier to use.
> 
> I guess it could be, if I followed any of this talk at all.

For example, being able to make a lens flare object that you can 
translate around, put in a CSG, etc.


> Simple can be good, but... What I'm imagining happening is that a simple
> sphere might look like:
> 
> ThisSphere.sphere {<1,2,3>,1}

That wouldn't be any syntax I recognize. It could easily end up looking 
like:
def ThisSphere = sphere {<1,2,3>,1}


> And continued usage (adding a color for example):
> 
> ThisSphere.color {<0.1,0.2,0.3,1,0>}

ThisSphere.pigment.color = <0.1,0.2,0.3,1,0>;


> Where MySphere remains defined but gets additional info attached to it. Or
> all at once:
> 
> ThisSphere.sphere.color {<1,2,3>,1,<0.1,0.2,0.3,1,0>}

def ThisSphere = sphere {<1,2,3>, 1 pigment {<0.1,0.2,0.3,1,0>}}

The dot syntax is just about always used for accessing parts of an 
object, not for creating one. Like vector .x, .y, .z, or color .red, 
.green, etc.


> Then raytraced when only the name stands alone:
> 
> ThisSphere

There's several ways adding the object to the scene could be handled, 
this is one way.


> And so it's difficult to think of doing this for evermore complicated
> things. Am I on the wrong track to believe this way?

Yes. You're assuming you would have to do everything in a much more 
complex fashion, this is not the case. The final result could be very 
similar to the current POV language in general use.

-- 
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 <06nn30d5mm6n9obft2tquhgr82le6s4jok@4ax.com>,
 Andreas Kaiser <aka### [at] nurfuerspamde> wrote:

> This was meant from a newbie's point of view where 'a *= b' might
> appear to be faster than a call to 'MyMatrixMultiplyMatrixEq(a, b)'.

And I've seen people ask if functions and variables with longer names 
were slower to access (in C++), I've even seen code with shortened names 
to maximize speed...but this kind of newbie misconception shouldn't last 
long, and is no argument against 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 <403b27c6@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> > Of course, that assumes the compiler's too stupid to turn this into a 
> > direct call in the case that there's no actual dynamic dispatch in the 
> > program. Same kind of thing. Lazy compiler writers. ;-)
> 
>   If a member function has been declared virtual in C++, there's no way
> the compiler can know at compile time there will be no more than one
> derived class implementing that function.

However, there are cases where the compiler can figure out which 
inherited implementation is desired and turn a member function call into 
a static call, or even inline it. Pretty much whenever the exact type of 
the object being referred to is known.


> It can't even theoretically
> check this at linking time because some code in a dynamic library (which
> may change in the future) may implement that virtual function.

C++ doesn't play particularly well with dynamic linking. C++ RTTI and 
virtual functions can cause many problems with it.

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

>   I don't understand where I went off-topic.
> 
>   I said that I don't like Java interfaces and I don't understand why
> there needs to be any. So IMO this new scripting language doesn't need


And that's where you keep going off topic. We're not talking about Java 
interfaces, we're talking about interfaces.

-- 
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-625719.08263725022004@news.povray.org...
> In article <403c3ec3$1@news.povray.org>,
>  "Hughes, B." <omn### [at] charternet> wrote:
>
> > Where MySphere remains defined but gets additional info attached to it.
Or
> > all at once:
> >
> > ThisSphere.sphere.color {<1,2,3>,1,<0.1,0.2,0.3,1,0>}
>
> def ThisSphere = sphere {<1,2,3>, 1 pigment {<0.1,0.2,0.3,1,0>}}
>
> The dot syntax is just about always used for accessing parts of an
> object, not for creating one. Like vector .x, .y, .z, or color .red,
> .green, etc.

Ahh yes, thanks for that clarification. I suspected as much but it was
looking to me like everything was to be built in the same way as accessing
it later.

> > Then raytraced when only the name stands alone:
> >
> > ThisSphere
>
> There's several ways adding the object to the scene could be handled,
> this is one way.

I like not having to use object {ThisSphere}, so this is a good thing I
think. Minimized scripting in the same vein as not needing parent wrappers,
which I believe you actually mentioned back in the thread someplace, could
be nice. Maybe not clear until learning what's what, but easier to write.

> > And so it's difficult to think of doing this for evermore complicated
> > things. Am I on the wrong track to believe this way?
>
> Yes. You're assuming you would have to do everything in a much more
> complex fashion, this is not the case. The final result could be very
> similar to the current POV language in general use.

Okay. But, admittedly, it would still become more code-like for the writers
of it. Yet, presumably, easier to use the result. Regardless, I think all
this will come down to a widened dividing line between casual artists and
data-crunchers. Since no one knows the future for certain it could go either
way, good or bad thing. Maybe no worse than other changes had been. Hmmm...
That's a statement not to be taken too lightly. The halo, semicolons,
patterns... sounds ultra mild compared to most of the talk in this thread.
;-)

Bob H.

Post a reply to this message