 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Then why did you even reply to my message?
You said you'd never seen a good argument against it, I merely wanted to tell
you the argument against it that I've heard, since it was good enough to
convince the programmers I know. I never meant the argument was against operator
overloading being used by anyone, just against it being used in the environments
I've worked in. It was really only inteded as trivia, I never meant to spark
such a long discussion! :)
Though I confess at the time I heard the argument I knew far too little about OO
code, so I've failed miserably to convey the true convincingness of the original
discussion...
Well that's my excuse.
> The only information hidden is that which isn't of any use to the
> situation anyway. You don't need to know exactly how vectors and
> matrices are multiplied,
Yes, *I* do. That's what I'm saying. That's why we don't use operator
overloading, because we prefer to see the information that it hides.
> You regularly have separate programmers coding and optimizing?
Not exactly, but some of us can optimise a lot better than others. Besides we
believe everyone should write code in a way that anyone else can read, and for
our purposes that means at a lower level than true OO.
> Then they're doing it wrong. And what company do you work for? I never
> want to work there.
Naughty Dog, (Jak & Daxter, Crash Bandicoot, and the engine for Ratchett &
Clank), and until recently I worked for Codemasters (on the Toca series of
games). Just a few little multimillion selling titles, I'm sure we don't have a
clue what we're doing.
There are higher level languages and there are lower level languages, you have
to choose what you use according to the nature of what you do. The games
industry has progressed from Assembler to C to using some features of C++, but
(in our case) not all of them, because the nature of the games we develop is
gradually becoming more high level.
In the future we shall doubtless move to a more pure C++ style of code, but it
is naive to presume that assembler is simply inferior to C++. Higher level is
not necessarily better, it depends on the nature of the program you are
developing. We have chosen our level based on many decades of combined
experience of games development, and whilst I may not personaly be able to
explain all the reasons for this (since my OO experience is limitted) I think it
is foolish to assume these intelligent professionals would simply get it wrong.
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> > Interfaces are obsolete of you can make abstract classes.
> Technically, they're obsolete if you have decent multiple inheritance.
> The benefit of a Java interface is that you can be a Stream *and* a
> Thread *and* an Iterator.
Supposing you are happy with the fact that you must implement every
single method of Stream, Thread and Iterator in every single inherited
class... You can't group common functionality in the interfaces.
This is one thing which I have never understood (and probably never
will) about interfaces: They *force* you to perform one of the basic
sins in programming: Code repetition.
I thought Java was designed to force the programmer to make good
code, not bad code. *sigh*
Besides, multiple inheritance was not included in Java because you
can use it "in the wrong way" (same song as with every non-included
feature in Java).
How can you use multiple-inheritance in the wrong way? Well, one
classical example is that you have a Boat class and a Plane class
and you multiple-inherit a Hydroplane class from them. This is
bad OO design (mainly because a Hydroplane is not a boat).
Well, make a Boat interface and a Plane interface and make
a Hydroplane class which implements them. What's the difference?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Actually, I think I am wired a little different. Here's an example: when you
> said to someone, "If you don't know what operator+() does with the type you
> are using, then you should seek another job, IMHO," I thought that was far
> worse than anything I have ever said to anybody on here by at least a factor
> of 10.
Yeah, speaking as the recipient of that comment, I did find it a little uncalled
for. I'm not sure whether Warp was trying to suggest I'm an idiot or simply
assuming that myself and every professional games programmer I know fails to
understand how to write code, but in either case I think he was out of line.
Though my policy is that I don't tend to take offence unless it's a direct
insult. i.e. if you actually think I'm an idiot but you don't say so then we
should get along just fine.
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> > Int foo = container.size(); // <- gets a *reference*
> No, that initializes an Int named foo to the object returned by
> container.size. Not a problem.
And what if you *do* want a reference to the member variable?
You can't?
(One common situation where you want to do this eg. in C++ is when
you have a big container inside another container and you return
a const reference to the internal container; this way the big internal
container is not needlessly copied, which would be inefficient, but you
can read it directly.)
> You could also introduce const references...not sure if its worth the
> trouble.
I think they are useful, as I mentioned above.
Don't know what would be a practical syntax, though.
--
#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:
> Yeah, speaking as the recipient of that comment, I did find it a little uncalled
> for. I'm not sure whether Warp was trying to suggest I'm an idiot or simply
> assuming that myself and every professional games programmer I know fails to
> understand how to write code, but in either case I think he was out of line.
Nope, it was not directed at you personally.
From what I understood, you said something in the lines of "I don't want
to hide a complex operation behind an overloaded operator because then
someone else could use that operator in the wrong way, not knowing what
it really does".
To that I responded basically "if this someone" (ie not you) "uses your
library for some time-critical application and does not know what the
operator does, then he is in the wrong business".
What I meant is that it's not your fault if someone uses your library
in the wrong way without taking care of knowing which functions are heavy
and which aren't.
You can, of course, design the public interface of your library in
such way that even less aware coders are warned about a possible
inefficiency, and I fully understand this ideology. I just opposed
the idea of avoiding operator overloading in all cases.
So no, I was not directing any insult or anything else against you
personally.
--
#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 in message
news:40394cc2$1@news.povray.org...
> > Actually, I think I am wired a little different. Here's an example: when
you
> > said to someone, "If you don't know what operator+() does with the type
you
> > are using, then you should seek another job, IMHO," I thought that was
far
> > worse than anything I have ever said to anybody on here by at least a
factor
> > of 10.
>
> Yeah, speaking as the recipient of that comment, I did find it a little
uncalled
> for. I'm not sure whether Warp was trying to suggest I'm an idiot or
simply
> assuming that myself and every professional games programmer I know fails
to
> understand how to write code, but in either case I think he was out of
line.
>
> Though my policy is that I don't tend to take offence unless it's a direct
> insult. i.e. if you actually think I'm an idiot but you don't say so then
we
> should get along just fine.
As I think more and more about this (I went for a drive to cool off), I
realize what is happening and what I'm doing wrong. I came on these groups
initially because I just made a move to an apartment where I'm isolated and
I needed some social interaction. I felt that, by coming on to a board where
I felt I could contribute, I would fill that need. Colored by the fact that
I am easily at the lowest point in my life of nothing but low points, I
didn't come in with a very thick skin to begin with.
It wasn't your commentary on my code, Warp, that made me angry initially --
it was when you supported Thorsten's personal attack on me that made me
angry with you. I've learned a lot from your critique and I feel honored
that you took the time to teach me how to do it right. Proof's in the thread
on my claim there.
Truth is, almost every one of the messages on this board makes me sad in
some way. Disrespect makes me feel sad -- not even angry, just sad, which
turns to anger when I start to rebel against it. I can't afford to be sad
and it is coloring how I read things and not in a good way. There are povray
boards that are making me happy, however, so I've decided to desubscribe to
this group and stick to the boards that make me happy. I'm not lurking --
not expecting a response -- Chris, you don't have to kill-file me -- I'm not
going to post here again.
For what it's worth, please accept my sincerest apologies for walking in and
stirring things up.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> To that I responded basically "if this someone" (ie not you) "uses your
> library for some time-critical application and does not know what the
> operator does, then he is in the wrong business".
Ah, I see. Yes, that is not an insulting statement to make, I simply
misinterpretted your meaning.
However, I find in my line of work that if you have to rely on people being able
to write good code, you will get an inferior result. We find these practices
make our style of coding easier, hence we use them. For more high-level
applications this approach would bog things down too much.
> So no, I was not directing any insult or anything else against you
> personally.
In that case I shall stick to my policy of generally not interpretting anything
as an insult :)
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40394a33@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> What do you mean "no virtual functions"? If every function is dynamically
> bound, then *every* member function is virtual.
No. Virtual function tables are an implementation detail, the
implementation specifically used by C++. There are other ways of
implementing dynamic dispatch.
> > Again, I'm talking about single inheritance. Multiple inheritance is not
> > necessary, and is needlessly complex.
>
> Who is talking about multiple inheritance here? I'm not.
You're implying it. You say abstract classes can replace interfaces. A
class can have multiple interfaces, but in single interface models can
only inherit from one class. Therefore, I figured you must be talking
about multiple inheritance, because nothing else made sense.
> And multiple inheritance may be complex from the point of view of
> the interpreter/compiler, not from the point of view of the user.
> Why should that be a limit?
Look at virtual inheritance and why it's necessary.
> I don't understand what you are saying.
> Why have *two* types of classes when you can have just one?
I never said anything about two class types...I have no idea how you're
reading what I'm trying to say.
> And why abstract classes are not useful in single inheritance model?
Because you can only inherit from one.
> > Interfaces render multiple inheritance + multiple abstract root classes
> > obsolete, not the other way around.
>
> Interfaces are a poor way of making multiple inheritance. They have
> all the logical problems of multiple inheritance and they force you
> to make code repetition.
They do not have all the problems of multiple inheritance. And a
language could have default implementations for interfaces. Java is not
an example of a perfect, or even very good OO language.
> I have never understood what's so good about interfaces.
They avoid many of the problems of multiple inheritance.
--
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 <40394870@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> If the function is declared in a header file but implemented in a
> separate object file then the compiler naturally can't inline it.
You would be surprised what some modern compilers can do if you care neither
about memory usage nor compilation time...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <403947c4@news.povray.org>, Darren New <dne### [at] sanrrcom>
wrote:
> OK, honestly, I misspoke. Folks were talking about C++ style
> programming, and said something about lacking virtual functions. I
> equated that to lacking dynamic dispatch, because that was kind of the
> environment it was discussed in. The only dynamic dispatch in C++ is
> virtual functions (or pointers to functions).
Ok, I was just talking about OO in general, not narrowing it down to a
specific implementation.
> Sure, messages and methods are more than virtual functions. Objective-C
> basically took the messaging model from Smalltalk and pasted it on top of C.
That's basically it. Works pretty well, actually, though it does look
funny...and no blocks, unfortunately. There is the concept of "higher
order messaging" that might take their place...
> > Virtual functions are just a specific implementation detail, not a core
> > requirement for object oriented languages.
>
> Correct. But I'd contend that dynamic dispatch (i.e., the same name used
> at the same point in the program meaning different invocations at
> different times in the execution of the program) is a core requirement.
I agree.
> > BTW, have you ever looked at Dylan?
>
> No, but I've used Smalltalk. What's unique about Dylan that I should
> look at it? :-)
Well, the name is an abbreviation of "Dynamic language". It's object
oriented and very, well, dynamic. You mentioned Eiffel and said some
things that made me think you were familiar with Smalltalk, so I thought
you might know about Dylan...I don't know a lot about it myself, but it
looks interesting. Hmm...
http://directory.google.com/Top/Computers/Programming/Languages/Dylan/
http://www.cetus-links.org/oo_dylan.html
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:403963c6@news.povray.org...
> In article <40394870@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
>
> > If the function is declared in a header file but implemented in a
> > separate object file then the compiler naturally can't inline it.
>
> You would be surprised what some modern compilers can do if you care neither
> about memory usage nor compilation time...
We enabled link time code generation on the last project I worked on, it made
the game a huge amount faster, and made the link time REALLY slow. Like over 5
minutes just for incremental builds. Nasty. Still a good thing to do on the
final build.
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek <tek### [at] evilsuperbraincom> wrote:
> Ah, I see. Yes, that is not an insulting statement to make, I simply
> misinterpretted your meaning.
I sometimes write things a bit hastily without re-reading them and
thinking if they could be understood in a different way than what I'm
thinking.
> However, I find in my line of work that if you have to rely on people being able
> to write good code, you will get an inferior result. We find these practices
> make our style of coding easier, hence we use them. For more high-level
> applications this approach would bog things down too much.
I just took the "operator overloading is not good" part of your text
and answered to 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> > I don't understand what you are saying.
> > Why have *two* types of classes when you can have just one?
> I never said anything about two class types...I have no idea how you're
> reading what I'm trying to say.
I can't see interfaces as anything else than very limited classes.
For example, in Java I see two types of classes: The regular ones
and the extremely limited ones which they call "interfaces".
What I wonder is why have two types of classes like this when just
one type suffices? IMO interfaces cause more problems than they avoid.
> > And why abstract classes are not useful in single inheritance model?
> Because you can only inherit from one.
So basically what you want is to support multiple inheritance, but
without the possibility of grouping common functionality to the
"base classes" (ie. "interfaces" in this case) but forcing the inherited
classes to implement everything again and again?
> > I have never understood what's so good about interfaces.
> They avoid many of the problems of multiple inheritance.
From the compiler's point of view or the programmer's point of view?
Can you present a good example?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Right. But if you can't do multiple inheritance, you can't do that with
> abstract classes either. Interfaces don't replace abstract classes, they
> replace multiple inheritance. Abstract classes without multiple
> inheritance is not a replacement for interfaces, either.
But why forbid multiple inheritance?
Everyone talks about multiple inheritance like it was a scary monster.
I have never understood why. All the examples of bad usages of multiple
inheritance are of the same type as how regular inheritance can be
used wrongly or how operator overloading can be used wrongly. Or what
the heck, how variable names can be used wrongly.
As with all those other features, multiple inheritance is a very
powerful and useful feature when you know how to use it right.
This is one reason why I hate Java: By trying to "protect" inexperienced
programmers they have taken away useful features from experienced ones who
know how to use the features right. My attitude with Java is "yes, I know
how things can be used wrongly, but I'm not going to, so give me the damn
features, ok?"
> > This is one thing which I have never understood (and probably never
> > will) about interfaces: They *force* you to perform one of the basic
> > sins in programming: Code repetition.
> Well, more like they make it easier for the compiler-writer.
So the maker of the compiler is simply lazy? ;)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > So basically what you want is to support multiple inheritance, but
> > without the possibility of grouping common functionality to the
> > "base classes" (ie. "interfaces" in this case) but forcing the inherited
> > classes to implement everything again and again?
> Right. It avoids a fairly wide range of problems, both semantic and
> efficiency.
So because the makers of the compiler are lazy they force the
user of the language to make bad code?
C++ does multiple inheritance quite efficiently, and even if it didn't,
why should it matter? You just need to know how heavy multiple inheritance
is and then decide whether to use it or not in your application. However,
if you have a place where it would be extremely useful then it's good that
you have the possibility.
One could argue that virtual functions are inefficient because they
produce internally an indirect function call (subroutine call to an
address got from behind a pointer got from behind a pointer), which
potentially make them slightly slower than regular function calls.
Does this mean virtual functions should be left out? Of course not.
You just need to be aware of what they do.
> Also, diamond-shaped inheritance is problematic, semantically speaking.
> For one: If D inherits from B and C, and both B and C inherit from A,
> and A declares instance variables, how many copies of that instance
> variable show up in D?
Diamond-inheritance is truely rare, so if you want to forbid that
special situation IMHO you can. However, don't forbid *all* multiple
inheritances because of one specific case.
In C++ if you want the base class to appear only once in the
bottommost inherited class in diamond-inheritance, you can make
the member variables of the base class virtual.
> A is a vehicle
> B is a plane
> C is a boat
> D is a hydroplane
That was a classical example of bad OO design, so I don't think you
should be using it to demonstrate your point. ;)
--
#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:
> > But why forbid multiple inheritance?
> Because it's difficult to get right. See my other post.
We have used multiple inheritance in our project without the
slightest problems. I don't see what's so wrong with it.
(In fact, we use it in places where the base classes from which you
are multiple-inheriting from act more or less like interfaces. The good
thing is, however, that these "interfaces" can and do have default
implementations for certain things and internally they form their own
inheritance hierarchy, which makes maintaining them easier.)
--
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 <40394cee@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Christopher James Huff <cja### [at] earthlinknet> wrote:
> > > Int foo = container.size(); // <- gets a *reference*
>
> > No, that initializes an Int named foo to the object returned by
> > container.size. Not a problem.
>
> And what if you *do* want a reference to the member variable?
> You can't?
No...then you declare a reference to it. For example, Sapphire has two
forms of the syntax for declaring variables:
def foo: bar; //declares foo as a reference to bar
def foo = bar; //declares foo as a reference to a copy of bar
> > You could also introduce const references...not sure if its worth the
> > trouble.
>
> I think they are useful, as I mentioned above.
> Don't know what would be a practical syntax, though.
And it does complicate the language. Remember that this is a scene
description language...
--
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:
> > And what if you *do* want a reference to the member variable?
> > You can't?
> No...then you declare a reference to it. For example, Sapphire has two
> forms of the syntax for declaring variables:
What if you want to make your class secure so that the user can't
break it?
This may happen by accident (ie. the user doesn't realize what he
is doing), not necessarily by a malign coder.
> And it does complicate the language. Remember that this is a scene
> description language...
That doesn't mean it shouldn't be made secure.
--
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 <403a8d68@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> > No...then you declare a reference to it. For example, Sapphire has two
> > forms of the syntax for declaring variables:
>
> What if you want to make your class secure so that the user can't
> break it?
> This may happen by accident (ie. the user doesn't realize what he
> is doing), not necessarily by a malign coder.
Then don't return a direct reference. You could return a proxy that
doesn't implement modification operations, but otherwise behaves like
the object referred to. You get the benefits of returning a member
without a long copy operation, and that member is still protected from
modification. Of course, this is basically doing what language-level
constant references would do, and isn't much simpler...
> > And it does complicate the language. Remember that this is a scene
> > description language...
>
> That doesn't mean it shouldn't be made secure.
It does mean it should be made as simple as feasible. Lack of constants
hasn't done much harm in POV-Ray.
--
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 <4039dada@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> > I never said anything about two class types...I have no idea how you're
> > reading what I'm trying to say.
>
> I can't see interfaces as anything else than very limited classes.
Because you're stuck in thinking about things in terms of C++...I think
it'd help you to learn a few more object-oriented languages.
> For example, in Java I see two types of classes: The regular ones
> and the extremely limited ones which they call "interfaces".
> What I wonder is why have two types of classes like this when just
> one type suffices? IMO interfaces cause more problems than they avoid.
Like? And don't say anything about the lack of default implementations,
that's Java-specific. I'm talking about the concept of interfaces in
general. I see it as being much like structured programming...rather
than one construct that can do anything with complex enough code, you
have restricted constructs that do specific jobs. It makes the intent of
the code clearer, and makes the language easier to learn and understand,
IMO at least. I also think languages should make more use of delegation
and composition...
> Can you present a good example?
At the moment, no. Nothing other than diamond inheritance, anyway. I'll
try to get a good example...
--
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 <403a9f16$1@news.povray.org> , Darren New <dne### [at] sanrrcom>
wrote:
> If you're asking "Why do X?" when you really mean to say "I
> don't think X should be necessary", you should phrase it differently.
You should learn when to interpret as question as a rhetorical question.
usually a good hint to interpret a question this way is when the person
continues to give an answer to it.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > So because the makers of the compiler are lazy they force the
> > user of the language to make bad code?
> Correctamundo! Welcome to commercial programming!
If I'm not completely mistaken this thread was about what would be
useful features and what would be unnecessary features for a theoretical
future OO scripting language for POV-Ray.
Last time I checked POV-Ray was not commercial and the developers didn't
have really tight deadlines.
> > C++ does multiple inheritance quite efficiently, and even if it didn't,
> > why should it matter? You just need to know how heavy multiple inheritance
> > is and then decide whether to use it or not in your application.
> Spoken like someone who writes all his own code without using someone
> else's libraries. Very good. :-)
I do use someone else's libraries a lot. For instance, I use the STL
libraries in almost every single C++ program I make. I do know most of
the advantages and disadvantages (including bottlenecks) in them.
> > One could argue that virtual functions are inefficient because they
> > produce internally an indirect function call (subroutine call to an
> > address got from behind a pointer got from behind a pointer), which
> > potentially make them slightly slower than regular function calls.
> 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. 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.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> > I can't see interfaces as anything else than very limited classes.
> Because you're stuck in thinking about things in terms of C++...I think
> it'd help you to learn a few more object-oriented languages.
Actually I was thinking in terms of Java. My comment was in no way
related to C++.
--
#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:
> You asked why one would forbid multiple inheritance. The ones doing the
> forbidding are the compiler writers. Hence, the answer is from a
> compiler-writer's point of view. Compiler-writers don't *use* multiple
> inheritance. They *implement* it.
That's exactly my point.
The fact that implementing multiple inheritance in a compiler is
laborious shouldn't be a good-enough reason for depriving the user of
the compiler from the possibility of using multiple-inheritance for
something useful.
It's a bit like "sorry, I don't know how to implement function calls
in my compiler, so you'll just have to make your code without function
calls". Not acceptable. :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> Of course, this is basically doing what language-level
> constant references would do, and isn't much simpler...
Exactly my point. :)
> > That doesn't mean it shouldn't be made secure.
> It does mean it should be made as simple as feasible. Lack of constants
> hasn't done much harm in POV-Ray.
This is because you can pass things by value and because there isn't
really any modules with a state (which you could break by accident).
But as soon as you introduce modules (which work like libraries) you
need some security features to avoid the user breaking their functionality
by accident.
--
#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:
> Warp wrote:
> > If I'm not completely mistaken this thread was about what would be
> > useful features and what would be unnecessary features for a theoretical
> > future OO scripting language for POV-Ray.
> Yet, just 2 posts up, you said
> > For example, in Java I see two types of classes: The regular ones
> > and the extremely limited ones which they call "interfaces".
> > What I wonder is why have two types of classes like this when just
> > one type suffices? IMO interfaces cause more problems than they avoid.
> You need to learn to stay on topic. ;-)
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
any interfaces á la Java.
--
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 <4032b303$1@news.povray.org>,
Tom Melly <pov### [at] tomandlucouk> wrote:
> IMHO this comes down to 'pov ain't oo' - I don't think anyone denies
> that oo capabilities in pov wouldn't be at the very least interesting,
> but that's not the issue....
Now, what was that you were saying anyway? I never figured out if you
thought OO capabilities were interesting or not...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...
--
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 <403b2846@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Actually I was thinking in terms of Java. My comment was in no way
> related to C++.
I meant that you're looking at Java in terms of C++, by considering
interfaces to be multiply-inherited, limited classes.
--
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 Sun, 22 Feb 2004 01:11:47 -0800, Tek wrote:
(Just a hint: start a new thread "Cast operators are evil" and I'll
agree at once)
>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 don't know what you want to state above. I think everybody will
agree that adding two matrices will take more time than adding two
integers. An operator adding two matrices takes the same time as your
MyMatrixAddFunction() function.
>plus you can search for it to see where it's executed in the code,
Ok, this might by an advantage.
>plus you can
>stick a nice big comment on the prototype of it saying "//avoid calling this
>unless really necessary, it's very slow" so that anyone who doesn't know how to
>add these two things has to look up the function prototype and read the comment
>and reconsider the code they're writing.
If someone is new to the project (as he doesn't know how to add 'these
two things') you have to train him anyway.
Using appropriate operators is IMHO more intuitive (and as fast as
your My...Function() above).
>I'm not trying to suggest the source looks nicer with more function calls, it
>certainly doesn't. I'd even say I like operator overloading a lot, it's
>extremely useful in high-level programming applications. I'm merely saying that,
>in practice, it makes it easier to write code that is much more complex to
>execute than it is to read or write. This is both it's strongest and weakest
>point.
I don't get the point. All that I know if I see 'My...Function(a, b)'
in the code is "Either a or b, or both of them are not simple types",
it doesn't give me any hint/warning about it's complexity.
>> 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.
>As I said, I support using + for vectors since that's what it will compile to.
>Although I don't really see your point about visual noise, function calls
Think of the core steps of an algorithm as signal, the code you
write/read as noise.
>certainly make it harder to write clearly readable code but since it's harder
>all it takes is more effort.
Yes. Harder to write it once, *and*
- harder to read always,
- harder to find bugs,
- easier to hide bugs,...
>Programming isn't about making things easier for
>the programmer, it's about making the end result better. In application software
>or high level programming these two ideas are very compatible, but in time
>critical stuff like game engines people like me have to give ourselves headaches
>trying to optimize out one cycle in a render loop in order to improve the
>performance of the game. Operator overloading hinders us in this quest.
>Damn that made me sound so cool...
:-)
--
Andreas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 22 Feb 2004 12:33:36 -0500, Christopher James Huff wrote:
>In article <n8ag309hemfhpmj8jnt5j5s3k8gr66rm62@4ax.com>,
> Andreas Kaiser <aka### [at] nurfuerspamde> wrote:
>
>> This might be a 'learning' problem if you aren't aware of the
>> operators 'hidden' complexity.
>
>Only if the code is poorly designed. You shouldn't have to care about
>the hidden complexity. It doesn't matter one bit how the = operator
>copies a string, only that it does so.
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)'.
>> >So do functions.
>>
>> Yes, same problem here. There's no correlation between length of
>> function name and complexity.
Oh, I see, I forgot the smiley.
Please read it as "... 'problem' ...".
>It's not a problem. It's a feature. Code written without functions is
>called spaghetti code, it ain't pretty and it is very inefficient and
>unmaintainable. Or should functions that do more have longer names?
This is what I wanted to point out.
> How long should POV-Ray's main() function be?
As short as possible.
--
Andreas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] 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
> any interfaces á la Java.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <403d0e51$1@news.povray.org>,
"Hughes, B." <omn### [at] charternet> wrote:
> 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.
You could create a language in such a way, but it would be quite
strange...actually, JavaScript is a little similar. But none of the
syntaxes I've seen suggested for POV would do it this 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.
I think you might be referring to my "#declare MyObj = object {MyObj
translate...}" example. I would actually prefer some kind of wrapper,
though maybe not of that exact form. Something like:
scene {
MyObj;
AnotherObj;
AndAnotherOne;
SomeProcedureThatReturnsAnObject();
ObjectMaker.MakeAnObject();
}
Basically, any statement that results in an object puts an object into
the scene when used within a scene {} block. Outside a scene block, the
object just gets ignored. Otherwise you'll run into annoyances when you
call something that returns an object that is only desired some of the
time. Say you have a procedure that does something to an object and
returns that object for convenience, but you sometimes need to call it
but don't need the returned object. Without the scene{} block
restriction, you'd have to do something like declare a dummy variable
just to hold the object you don't want...annoying.
I also think it makes things a bit clearer to have some kind of wrapper
for the object name.
> > 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.
Well, it won't make the internals of a lens flare system any easier for
non-coders to understand, but it will make it easier for them to use it.
Objects are typically seen as "black boxes", they can be very complex
inside but nobody has to care about that, they only use the stuff on the
outside.
> Regardless, I think all this will come down to a widened dividing
> line between casual artists and data-crunchers.
I don't think so. It will mean more is possible entirely within POV
script, so the "data crunchers" won't have to go to external tools, and
the casual users have a much shorter distance to go before they can
understand and create similar things. POV-artists and POV-coders, rather
than POV-artists and C++/Java/Python-coders-who-export-POV-code.
--
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-6C16F7.17001225022004@news.povray.org...
> In article <403d0e51$1@news.povray.org>,
> "Hughes, B." <omn### [at] charternet> wrote:
>
> > I like not having to use object {ThisSphere}
>
> I think you might be referring to my "#declare MyObj = object {MyObj
> translate...}" example. I would actually prefer some kind of wrapper,
> though maybe not of that exact form. Something like:
>
> scene {
> MyObj;
> AnotherObj;
> AndAnotherOne;
> SomeProcedureThatReturnsAnObject();
> ObjectMaker.MakeAnObject();
> }
>
> Basically, any statement that results in an object puts an object into
> the scene when used within a scene {} block. Outside a scene block, the
> object just gets ignored. Otherwise you'll run into annoyances when you
> call something that returns an object that is only desired some of the
> time.
---snip---
> I also think it makes things a bit clearer to have some kind of wrapper
> for the object name.
Yes, I can see the reasoning here. This whole discussion, of what I didn't
skip anyway, was causing my mind to wander and think about it being possible
to write a piece of the SDL likened to the way a #macro() is now but with
far more interaction. And so, in that way, I thought of it as allowing for
subsets of a new kind of SDL which are callable at any time; same as the
program code itself. Maybe the term would be soft-code rather than
hard-code. From that idea I could see it as not needing every designation
such as would be if a material{} had to always be written out in full for a
simple color.
Anyway, I think I'm understanding it better now that I spoke up. It surely
is of the realm of programming before the final usage could come into play.
But I feel I've backtracked here by rehashing what's probably already been
said.
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <cjameshuff-DF3DAB.08451225022004@news.povray.org>,
Christopher James Huff <cja### [at] earthlinknet> wrote:
> > 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.
I forgot to mention it, but you might want to look up "fragile base
classes".
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:403c6c39@news.povray.org...
> 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).
What I mean is that "+" should always take the same length of time, and should
not be confused with something that will take a different length of time.
Though I'm tired of repeating myself. If you disagree with me that's fine, but
you still seem to misunderstand what I'm saying, and I've got tired of
explaining.
Honestly I was just trying to point out we don't do this in the games industry,
not start a debate based on confusion...
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> And that's where you keep going off topic. We're not talking about Java
> interfaces, we're talking about interfaces.
So what's the difference between Java interfaces, your interfaces and
abstract classes?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> > > 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.
> I forgot to mention it, but you might want to look up "fragile base
> classes".
But I was not talking about changing base classes. I was talking about
changing derived classes. There's a big difference.
--
#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:
> I mean, Java interfaces are specific to Java, generic interfaces aren't,
> and abstract classes can actually have code and stuff in them and Java
> doesn't support that. Why do you ask?
That doesn't really tell what these "generic interfaces" are, and how
they are different from either abstract classes or Java interfaces.
I know the latter two, but I have no idea what these "generic interfaces"
could be.
--
#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:
> They're interfaces that can't have code and aren't specific to Java.
That's like saying that a "generic int" is a variable which can have
an integer value and is not related to C.
That statement doesn't make any sense.
--
#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:
> For example, one could ask "Should a generic int be limited in size in a
> new programming language? If so, should a generic int throw an error on
> overflow or just silently wrap around?" You're not asking specifically
> in the context of C, for which the decision has already been made.
> You're asking in the context of a new language which hasn't been
> invented yet.
The difference is that basically you are saying that these "generic
interfaces" are identical to Java interfaces, but have nothing to do
with Java interfaces...
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
