 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
> though this thread
> makes it clear that at least some people consider them to be of great
> interest. It's almost at the 200 message mark...
I am still unconvinced that the greater majority will be served by the
addition of OO capabilities. I see a handful of dedicated programmers
in this discussion discussing what makes a program OO compliant but the
average joe-blow POV-Ray user is conspicuously absent in this discussion.
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.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <403C146F.38604E10@tag.povray.org>,
Ken <ken### [at] tag povrayorg> 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
|
|
| |
| |
|
|
|
|
| |
|
|
