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