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

    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

On Sat, 21 Feb 2004 22:26:59 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:

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

This might be a 'learning' problem if you aren't aware of the
operators 'hidden' complexity. 

>So do functions.

Yes, same problem here. There's no correlation between length of
function name and complexity. 
If you call a Trace() function you should know why.
May be to write a trace record to a log file, may be to start a render
that will be finished some months later.

>[...]

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

May be, but it isn't speed.
For example, I have rewritten POV-Ray's core using VECTOR, COLOUR and
some other classes (with appropriate operators).
It was as fast as the original version but shorter and IMHO much more
readable.
The macros required to do trivial colour/vector arithmetic are
'information hiding' in the worst sense. They blow up source code and
add visual noise which makes it sometimes almost impossible to see
what's going on.
OK, I'll stop now ;-)

>I still haven't heard one yet.


-- 
Andreas

Post a reply to this message