 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've decided to have a go at creating a fairly complex scene file based on lots
of autonomous entities with simple ai and physics. So, I've been figuring out
tricks for writing pov scene code in an object-oriented manner.
i.e. there basically needs to be some way of defining classes (I won't do
inheritance), with member variables and functions. And some system of creating
and destroying these on the fly. Oh, and persistent variables.
Now, I think I've actually figured out a pretty decent way to do all this, just
using the SDL. I'm happy to give details but I don't want to clog up this
message with all that info.
But anyway, the reason I'm posting: I was just wondering has anyone done this
before? Either within the SDL, or as a modification to pov to support simple
data structures and function callbacks?
Oh, and do you think it should be oriented or orientated? ;)
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4025787d@news.povray.org>, "Tek" <tek### [at] evilsuperbrain com>
wrote:
> But anyway, the reason I'm posting: I was just wondering has anyone done this
> before? Either within the SDL, or as a modification to pov to support simple
> data structures and function callbacks?
Never actually done it, but I've considered doing something based on
arrays...it'd be hellishly complex and inefficient. And it was limited
to passive data structures, not really anything like objects.
> Oh, and do you think it should be oriented or orientated? ;)
Oriented. "Orientated" is a synonym, but sounds odd and I've never seen
a "professional" source use that spelling in relation to object
orientation. "Oriention" isn't a word though, so orientated is probably
the original spelling.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Never actually done it, but I've considered doing something based on
> arrays...it'd be hellishly complex and inefficient. And it was limited
> to passive data structures, not really anything like objects.
Well that's kinda similar to what I'm thinking.
my theory is I interface to everything via macros. So if I want to get the
"position" member of an object that I have "pointer" to, this would actually
work by using indeces, not pointers, and having an array of positions. But I can
write the code via macros so it looks sorta like it's using structures!
The problem with this is that I need one set of arrays for each different class
of object/structure. And those arrays would need to be long enough to hold every
instance I would be likely to create. Still, that's not a big problem.
The other, much more cunning, trick is to be able to have functions (actually
macros) invoked differently for different objects. e.g. lets imagine I have lots
of classes that have the same basic structure, but different functions (e.g.
good guys and bad guys with different AI routines). The thing is I want to be
able to invoke different functions according to what class of object I'm
accessing *without needing a big switch statement handling all classes*.
My cunning trick is to store, as a parameter in the "structure", the name of the
macro I want to invoke for this object. e.g. "GoodGuyUpdate". Then I can save
this string out to a scratch file with a string of parameters (which will be the
same since this is just an implementation of a virtual function, if you want to
look at it like that). So we get a scratch file saying
"GoodGuyUpdate(myObject,deltaTime)" or something. Then just include that scratch
file to invoke it!
It's somewhat cumbersome, but it would certainly work.
In fact, I think I'm gonna start building this framework now :)
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
For anyone who's interested, I've just put the first building block of my
technique in p.b.s-f.
--
Tek
www.evilsuperbrain.com
"Tek" <tek### [at] evilsuperbraincom> wrote in message news:4025787d@news.povray.org...
> I've decided to have a go at creating a fairly complex scene file based on
lots
> of autonomous entities with simple ai and physics. So, I've been figuring out
> tricks for writing pov scene code in an object-oriented manner.
>
> i.e. there basically needs to be some way of defining classes (I won't do
> inheritance), with member variables and functions. And some system of creating
> and destroying these on the fly. Oh, and persistent variables.
>
> Now, I think I've actually figured out a pretty decent way to do all this,
just
> using the SDL. I'm happy to give details but I don't want to clog up this
> message with all that info.
>
> But anyway, the reason I'm posting: I was just wondering has anyone done this
> before? Either within the SDL, or as a modification to pov to support simple
> data structures and function callbacks?
>
> Oh, and do you think it should be oriented or orientated? ;)
>
> --
> Tek
> www.evilsuperbrain.com
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 7 Feb 2004 15:45:04 -0800, "Tek" <tek### [at] evilsuperbraincom> wrote:
> modification to pov to support simple
> data structures and function callbacks?
http://news.povray.org/povray.advanced-users/19907/
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ooh that's a nice technique! You mind if I borrow it? :)
--
Tek
www.evilsuperbrain.com
"ABX" <abx### [at] abxartpl> wrote in message
news:vcge20l4jv2o4ikggniv4cf1hgmm5rrvbh@4ax.com...
> On Sat, 7 Feb 2004 15:45:04 -0800, "Tek" <tek### [at] evilsuperbraincom> wrote:
> > modification to pov to support simple
> > data structures and function callbacks?
>
> http://news.povray.org/povray.advanced-users/19907/
>
> ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I had a try at doing some code for data aggregation, not dealing with
functions. I wanted to do something general to construct, manipulate,
save, load print and destroy any aggregation of data, but I stopped when
I realized that I was not able to query the type of my data (hence no
print or save).
Just in case it would give you any idea, I post my files on p-t-scene-files.
JC
Tek wrote:
> I've decided to have a go at creating a fairly complex scene file based on lots
> of autonomous entities with simple ai and physics. So, I've been figuring out
> tricks for writing pov scene code in an object-oriented manner.
>
> i.e. there basically needs to be some way of defining classes (I won't do
> inheritance), with member variables and functions. And some system of creating
> and destroying these on the fly. Oh, and persistent variables.
>
> Now, I think I've actually figured out a pretty decent way to do all this, just
> using the SDL. I'm happy to give details but I don't want to clog up this
> message with all that info.
>
> But anyway, the reason I'm posting: I was just wondering has anyone done this
> before? Either within the SDL, or as a modification to pov to support simple
> data structures and function callbacks?
>
> Oh, and do you think it should be oriented or orientated? ;)
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmm... the array of arrays idea is interesting. In my system I never need to
query the type of data (it will only be accessed by code that knows what to
expect). It certainly has some potential.
Thanks!
--
Tek
www.evilsuperbrain.com
"JC (Exether)" <no### [at] spamfr> wrote in message news:4028143b$1@news.povray.org...
> I had a try at doing some code for data aggregation, not dealing with
> functions. I wanted to do something general to construct, manipulate,
> save, load print and destroy any aggregation of data, but I stopped when
> I realized that I was not able to query the type of my data (hence no
> print or save).
>
> Just in case it would give you any idea, I post my files on p-t-scene-files.
>
> JC
>
> Tek wrote:
>
> > I've decided to have a go at creating a fairly complex scene file based on
lots
> > of autonomous entities with simple ai and physics. So, I've been figuring
out
> > tricks for writing pov scene code in an object-oriented manner.
> >
> > i.e. there basically needs to be some way of defining classes (I won't do
> > inheritance), with member variables and functions. And some system of
creating
> > and destroying these on the fly. Oh, and persistent variables.
> >
> > Now, I think I've actually figured out a pretty decent way to do all this,
just
> > using the SDL. I'm happy to give details but I don't want to clog up this
> > message with all that info.
> >
> > But anyway, the reason I'm posting: I was just wondering has anyone done
this
> > before? Either within the SDL, or as a modification to pov to support simple
> > data structures and function callbacks?
> >
> > Oh, and do you think it should be oriented or orientated? ;)
> >
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tek" <tek### [at] evilsuperbraincom> wrote in message
news:4025787d@news.povray.org...
> I've decided to have a go at creating a fairly complex scene file based on
lots
> of autonomous entities with simple ai and physics. So, I've been figuring
out
> tricks for writing pov scene code in an object-oriented manner.
>
> i.e. there basically needs to be some way of defining classes (I won't do
> inheritance), with member variables and functions. And some system of
creating
> and destroying these on the fly. Oh, and persistent variables.
>
> Now, I think I've actually figured out a pretty decent way to do all this,
just
> using the SDL. I'm happy to give details but I don't want to clog up this
> message with all that info.
>
> But anyway, the reason I'm posting: I was just wondering has anyone done
this
> before? Either within the SDL, or as a modification to pov to support
simple
> data structures and function callbacks?
>
> Oh, and do you think it should be oriented or orientated? ;)
>
> --
> Tek
> www.evilsuperbrain.com
>
>
My principal "object" is the #include file. Each object definition,
including macros, variables, etc. can be placed in this file.
If you want a macro to use the object, just use the filename as a string
parameter:
#macro ObUser(iFile, oFile)
#include iFile
#open oFile
...
#write oFile, Data
...
#close oFile
#end
I use this tactic frequently. Macros that would otherwise use a large
number of parameters are greatly simplified by this method. Macros,
functions, and primitives that might not otherwise be available as macro
parameters can be provided for this way.
#include files also carry one extra benefit: you can add descriptive
comments and variable names that make code reading easier
Try it some time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Maybe I'm misunderstanding you, but how does having each object as an include
file help? Or do you mean have each class as an include file?
BTW, did you see the technique I posted in p.b.s-f? That sounds pretty similar
to what you're suggesting. It solves the problem of indirect function
invocation, but but I still haven't found a nice way of defining
structures/classes. Can your system do this?
Basically I want to be able to do things like this:
myMoveableObject = new Monkey; //Monkey is a class
...
myMoveableObject.move(deltaTime);
...
if ( myMoveableObject.position == invalid ) delete myMoveableObject;
--
Tek
www.evilsuperbrain.com
"David Wallace" <dar### [at] earthlinknet> wrote in message
news:402907a4@news.povray.org...
>
> "Tek" <tek### [at] evilsuperbraincom> wrote in message
> news:4025787d@news.povray.org...
> > I've decided to have a go at creating a fairly complex scene file based on
> lots
> > of autonomous entities with simple ai and physics. So, I've been figuring
> out
> > tricks for writing pov scene code in an object-oriented manner.
> >
> > i.e. there basically needs to be some way of defining classes (I won't do
> > inheritance), with member variables and functions. And some system of
> creating
> > and destroying these on the fly. Oh, and persistent variables.
> >
> > Now, I think I've actually figured out a pretty decent way to do all this,
> just
> > using the SDL. I'm happy to give details but I don't want to clog up this
> > message with all that info.
> >
> > But anyway, the reason I'm posting: I was just wondering has anyone done
> this
> > before? Either within the SDL, or as a modification to pov to support
> simple
> > data structures and function callbacks?
> >
> > Oh, and do you think it should be oriented or orientated? ;)
> >
> > --
> > Tek
> > www.evilsuperbrain.com
> >
> >
> My principal "object" is the #include file. Each object definition,
> including macros, variables, etc. can be placed in this file.
>
> If you want a macro to use the object, just use the filename as a string
> parameter:
>
> #macro ObUser(iFile, oFile)
> #include iFile
> #open oFile
> ...
> #write oFile, Data
> ...
> #close oFile
> #end
>
> I use this tactic frequently. Macros that would otherwise use a large
> number of parameters are greatly simplified by this method. Macros,
> functions, and primitives that might not otherwise be available as macro
> parameters can be provided for this way.
>
> #include files also carry one extra benefit: you can add descriptive
> comments and variable names that make code reading easier
>
> Try it some time.
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm afraid my "objects" don't work quite that way. I use them like this:
--- code ---
// Parametric variable form
//#version unofficial MegaPov 0.7;
#declare uMin = 0; // Minimum u value
#declare uMax = radians(90); // Maximum u value
#declare uNum = 41; // Number of points in u direction
#declare uWrap = 0; // u wraps around if != 0
#declare uSeed = 8266; // Random number seed for u parameter
#declare vMin = 0; // Minimum v value
#declare vMax = radians(356); // Maximum v value
#declare vNum = 90; // Number of points in v direction
#declare vWrap = 1; // v wraps around if != 0
#declare vSeed = 1425; // Random number seed for v parameter
#declare IsRnd = false; // True if random number used
#declare IsUV = false; // True if object is to be UV-mapped
#declare Smooth = 0; // Smooth flag
#declare Detail = "Partial"
/* Detail values
Verbose = Line by line details
Partial = Operations only
Other = Filename only
*/
/* For all macro functions
i = Current value of u parameter
j = Current value of v parameter
p = Current value of u variance (0...1)
q = Current value of v variance (0...1)
vc= Current 3D point
*/
// Optional functions
// point function
#macro pnt(i, j, p, q)
#local r0 = 1.1;
#local r1 = exp(cos(j));
#local yp = r0*sin(i);
#local xp = cos(i)*cos(j)*r1-exp(yp-0.35);
#local zp = cos(i)*sin(j)*r1*.1;
<xp, yp, zp>
#end
--- end code ---
To alter a property I simply use #declare or MegaPov's #set. I use the
contained macros in the traditional POV-Ray fashion. Like I mentionned
earlier, this trick is used to simplify macro calls and make variable macros
and functions available to them. It's not classic C++ classes by a long
shot and it wasn't intended to be.
"Tek" <tek### [at] evilsuperbraincom> wrote in message
news:4029c7e1$1@news.povray.org...
> Maybe I'm misunderstanding you, but how does having each object as an
include
> file help? Or do you mean have each class as an include file?
>
> BTW, did you see the technique I posted in p.b.s-f? That sounds pretty
similar
> to what you're suggesting. It solves the problem of indirect function
> invocation, but but I still haven't found a nice way of defining
> structures/classes. Can your system do this?
>
> Basically I want to be able to do things like this:
>
> myMoveableObject = new Monkey; //Monkey is a class
> ...
> myMoveableObject.move(deltaTime);
> ...
> if ( myMoveableObject.position == invalid ) delete myMoveableObject;
>
> --
> Tek
> www.evilsuperbrain.com
>
>
> "David Wallace" <dar### [at] earthlinknet> wrote in message
> news:402907a4@news.povray.org...
> >
> > "Tek" <tek### [at] evilsuperbraincom> wrote in message
> > news:4025787d@news.povray.org...
> > > I've decided to have a go at creating a fairly complex scene file
based on
> > lots
> > > of autonomous entities with simple ai and physics. So, I've been
figuring
> > out
> > > tricks for writing pov scene code in an object-oriented manner.
> > >
> > > i.e. there basically needs to be some way of defining classes (I won't
do
> > > inheritance), with member variables and functions. And some system of
> > creating
> > > and destroying these on the fly. Oh, and persistent variables.
> > >
> > > Now, I think I've actually figured out a pretty decent way to do all
this,
> > just
> > > using the SDL. I'm happy to give details but I don't want to clog up
this
> > > message with all that info.
> > >
> > > But anyway, the reason I'm posting: I was just wondering has anyone
done
> > this
> > > before? Either within the SDL, or as a modification to pov to support
> > simple
> > > data structures and function callbacks?
> > >
> > > Oh, and do you think it should be oriented or orientated? ;)
> > >
> > > --
> > > Tek
> > > www.evilsuperbrain.com
> > >
> > >
> > My principal "object" is the #include file. Each object definition,
> > including macros, variables, etc. can be placed in this file.
> >
> > If you want a macro to use the object, just use the filename as a string
> > parameter:
> >
> > #macro ObUser(iFile, oFile)
> > #include iFile
> > #open oFile
> > ...
> > #write oFile, Data
> > ...
> > #close oFile
> > #end
> >
> > I use this tactic frequently. Macros that would otherwise use a large
> > number of parameters are greatly simplified by this method. Macros,
> > functions, and primitives that might not otherwise be available as macro
> > parameters can be provided for this way.
> >
> > #include files also carry one extra benefit: you can add descriptive
> > comments and variable names that make code reading easier
> >
> > Try it some time.
> >
> >
> >
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh, I think I see what you mean. Yeah, that's a nice solution to a different
problem. I don't think it can quite handle the ludicrous complexity I'm trying
to achieve :)
--
Tek
www.evilsuperbrain.com
"David Wallace" <dar### [at] earthlinknet> wrote in message
news:402bc112@news.povray.org...
> I'm afraid my "objects" don't work quite that way. I use them like this:
> --- code ---
> // Parametric variable form
> //#version unofficial MegaPov 0.7;
>
> #declare uMin = 0; // Minimum u value
> #declare uMax = radians(90); // Maximum u value
> #declare uNum = 41; // Number of points in u direction
> #declare uWrap = 0; // u wraps around if != 0
> #declare uSeed = 8266; // Random number seed for u parameter
>
> #declare vMin = 0; // Minimum v value
> #declare vMax = radians(356); // Maximum v value
> #declare vNum = 90; // Number of points in v direction
> #declare vWrap = 1; // v wraps around if != 0
> #declare vSeed = 1425; // Random number seed for v parameter
>
> #declare IsRnd = false; // True if random number used
> #declare IsUV = false; // True if object is to be UV-mapped
>
> #declare Smooth = 0; // Smooth flag
>
> #declare Detail = "Partial"
> /* Detail values
> Verbose = Line by line details
> Partial = Operations only
> Other = Filename only
> */
>
> /* For all macro functions
> i = Current value of u parameter
> j = Current value of v parameter
> p = Current value of u variance (0...1)
> q = Current value of v variance (0...1)
> vc= Current 3D point
> */
>
> // Optional functions
>
> // point function
> #macro pnt(i, j, p, q)
> #local r0 = 1.1;
> #local r1 = exp(cos(j));
>
> #local yp = r0*sin(i);
> #local xp = cos(i)*cos(j)*r1-exp(yp-0.35);
> #local zp = cos(i)*sin(j)*r1*.1;
>
> <xp, yp, zp>
> #end
> --- end code ---
> To alter a property I simply use #declare or MegaPov's #set. I use the
> contained macros in the traditional POV-Ray fashion. Like I mentionned
> earlier, this trick is used to simplify macro calls and make variable macros
> and functions available to them. It's not classic C++ classes by a long
> shot and it wasn't intended to be.
>
> "Tek" <tek### [at] evilsuperbraincom> wrote in message
> news:4029c7e1$1@news.povray.org...
> > Maybe I'm misunderstanding you, but how does having each object as an
> include
> > file help? Or do you mean have each class as an include file?
> >
> > BTW, did you see the technique I posted in p.b.s-f? That sounds pretty
> similar
> > to what you're suggesting. It solves the problem of indirect function
> > invocation, but but I still haven't found a nice way of defining
> > structures/classes. Can your system do this?
> >
> > Basically I want to be able to do things like this:
> >
> > myMoveableObject = new Monkey; //Monkey is a class
> > ...
> > myMoveableObject.move(deltaTime);
> > ...
> > if ( myMoveableObject.position == invalid ) delete myMoveableObject;
> >
> > --
> > Tek
> > www.evilsuperbrain.com
> >
> >
> > "David Wallace" <dar### [at] earthlinknet> wrote in message
> > news:402907a4@news.povray.org...
> > >
> > > "Tek" <tek### [at] evilsuperbraincom> wrote in message
> > > news:4025787d@news.povray.org...
> > > > I've decided to have a go at creating a fairly complex scene file
> based on
> > > lots
> > > > of autonomous entities with simple ai and physics. So, I've been
> figuring
> > > out
> > > > tricks for writing pov scene code in an object-oriented manner.
> > > >
> > > > i.e. there basically needs to be some way of defining classes (I won't
> do
> > > > inheritance), with member variables and functions. And some system of
> > > creating
> > > > and destroying these on the fly. Oh, and persistent variables.
> > > >
> > > > Now, I think I've actually figured out a pretty decent way to do all
> this,
> > > just
> > > > using the SDL. I'm happy to give details but I don't want to clog up
> this
> > > > message with all that info.
> > > >
> > > > But anyway, the reason I'm posting: I was just wondering has anyone
> done
> > > this
> > > > before? Either within the SDL, or as a modification to pov to support
> > > simple
> > > > data structures and function callbacks?
> > > >
> > > > Oh, and do you think it should be oriented or orientated? ;)
> > > >
> > > > --
> > > > Tek
> > > > www.evilsuperbrain.com
> > > >
> > > >
> > > My principal "object" is the #include file. Each object definition,
> > > including macros, variables, etc. can be placed in this file.
> > >
> > > If you want a macro to use the object, just use the filename as a string
> > > parameter:
> > >
> > > #macro ObUser(iFile, oFile)
> > > #include iFile
> > > #open oFile
> > > ...
> > > #write oFile, Data
> > > ...
> > > #close oFile
> > > #end
> > >
> > > I use this tactic frequently. Macros that would otherwise use a large
> > > number of parameters are greatly simplified by this method. Macros,
> > > functions, and primitives that might not otherwise be available as macro
> > > parameters can be provided for this way.
> > >
> > > #include files also carry one extra benefit: you can add descriptive
> > > comments and variable names that make code reading easier
> > >
> > > Try it some time.
> > >
> > >
> > >
> >
> >
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek wrote:
> Oh, I think I see what you mean. Yeah, that's a nice solution to a different
> problem. I don't think it can quite handle the ludicrous complexity I'm trying
> to achieve :)
>
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....
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....
Wha...? You're saying you don't think OO capabilities would be useful,
or even interesting? And that you don't think anyone thinks it would be
interesting? It's sure spawned a lot of discussion for something so
utterly uninteresting...
--
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-60ACCD.21030117022004@news.povray.org...
> 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....
>
> Wha...? You're saying you don't think OO capabilities would be useful,
> or even interesting? And that you don't think anyone thinks it would be
> interesting? It's sure spawned a lot of discussion for something so
> utterly uninteresting...
After you parse the double-negative, he's actually saying the opposite --
that everybody would find it, at very least, interesting.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan P wrote:
> After you parse the double-negative, he's actually saying the opposite --
> that everybody would find it, at very least, interesting.
Not me. It would add another layer of complexity that I don't want to have
to bother to learn. OO is for programming not a scene description language.
If I wanted to learn programming I would do that rather than using POV-Ray.
--
Mr. Flameproof
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ken" <tyl### [at] pacbellnet> wrote in message
news:4032CB5A.9277B9BA@pacbell.net...
>
> Dan P wrote:
>
> > After you parse the double-negative, he's actually saying the
opposite --
> > that everybody would find it, at very least, interesting.
>
> Not me. It would add another layer of complexity that I don't want to have
> to bother to learn. OO is for programming not a scene description
language.
> If I wanted to learn programming I would do that rather than using
POV-Ray.
I whole-heartedly disagree. OO would enable POV-Ray to evolve beyond a scene
description language. Also, OO would make POV-ray /easier/ to learn because
Object-Orientation is just that: a way to describe abstract "objects", which
is what makes /up/ a scene. The thing is, POV-Ray isn't for people who
aren't programming-minded. I'm not discounting other pieces of software like
3DSMax or anything, but for programming-minded individuals, the graphical
user-interface gets in the way of achieving our true intentions. There are
many alternatives to POV-Ray for non-programming types, but few (if any -- I
don't know of any others, anyway) alternatives to POV-Ray/MegaPov.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Twaddle!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 17 Feb 2004 18:18:02 -0800, Ken <tyl### [at] pacbellnet> wrote:
>
>
>Dan P wrote:
>
>> After you parse the double-negative, he's actually saying the opposite --
>> that everybody would find it, at very least, interesting.
>
>Not me. It would add another layer of complexity that I don't want to have
>to bother to learn. OO is for programming not a scene description language.
>If I wanted to learn programming I would do that rather than using POV-Ray.
(Also at the risk that I'm again number one of your list)
If you use POV-Ray and write the scenes yourself (without a modeler)
there is no difference to 'programming'.
POV-Ray is just an interpreter to translate SDL to a binary image.
SDL is rather close to a subset of C, I always wonder whether the
deviations are unfortunate coincidences.
At least inheritance (of textures, objects, ...) is an OO feature of
POV-Ray's SDL.
--
Andreas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Now you're nit picking. Povray is as much like programming as it is, but OO
would make it more like programming. Stop pretending you didn't know what he
meant!
--
Tek
www.evilsuperbrain.com
"Andreas Kaiser" <aka### [at] nurfuerspamde> wrote in message
news:rhp5301kh5ji7gtjk9tvljodi9cpi80hge@4ax.com...
> On Tue, 17 Feb 2004 18:18:02 -0800, Ken <tyl### [at] pacbellnet> wrote:
>
> >
> >
> >Dan P wrote:
> >
> >> After you parse the double-negative, he's actually saying the opposite --
> >> that everybody would find it, at very least, interesting.
> >
> >Not me. It would add another layer of complexity that I don't want to have
> >to bother to learn. OO is for programming not a scene description language.
> >If I wanted to learn programming I would do that rather than using POV-Ray.
>
> (Also at the risk that I'm again number one of your list)
> If you use POV-Ray and write the scenes yourself (without a modeler)
> there is no difference to 'programming'.
> POV-Ray is just an interpreter to translate SDL to a binary image.
> SDL is rather close to a subset of C, I always wonder whether the
> deviations are unfortunate coincidences.
> At least inheritance (of textures, objects, ...) is an OO feature of
> POV-Ray's SDL.
>
> --
> Andreas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I agree with you!
Nobody should *need* to be able to understand OO in order to write pov scenes,
in it's most basic form it should remain just a "scene description language",
i.e. a list of objects and visual properties of them.
I'm just talking about extending the options available outside of that,
specifically I'm thinking of writing a group of macros in a .inc file to allow
some OO style programming. But even I'm not convinced something like that
/should/ be introduced into the main pov code, my original question was just to
find out if anyone had done it, not to try to suggest it's a good idea ;)
Though structures would be useful.
--
Tek
www.evilsuperbrain.com
"Ken" <tyl### [at] pacbellnet> wrote in message
news:4032CB5A.9277B9BA@pacbell.net...
>
>
> Dan P wrote:
>
> > After you parse the double-negative, he's actually saying the opposite --
> > that everybody would find it, at very least, interesting.
>
> Not me. It would add another layer of complexity that I don't want to have
> to bother to learn. OO is for programming not a scene description language.
> If I wanted to learn programming I would do that rather than using POV-Ray.
>
> --
> Mr. Flameproof
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 17 Feb 2004 22:26:39 -0800, "Tek" <tek### [at] evilsuperbraincom>
wrote:
>Now you're nit picking. Povray is as much like programming as it is, but OO
>would make it more like programming. Stop pretending you didn't know what he
^
... even more ... :-)
>meant!
--
Andreas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
> Not me. It would add another layer of complexity that I don't want to have
> to bother to learn. OO is for programming not a scene description language.
> If I wanted to learn programming I would do that rather than using POV-Ray.
No matter what you say, POV-Ray's SDL is a programming language.
Adding new features to the language does not mean you *must* learn them.
It just means that they are available to those who find them useful.
--
#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 news:403332b3@news.povray.org Warp wrote:
> Adding new features to the language does not mean you *must* learn
> them.
> It just means that they are available to those who find them useful.
If I want to read and understand those future OO-scenefiles, I'll have to
learn the new features. "Use" is more than just writing scenes.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-60ACCD.21030117022004@news.povray.org...
> 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....
>
> Wha...? You're saying you don't think OO capabilities would be useful,
> or even interesting? And that you don't think anyone thinks it would be
> interesting? It's sure spawned a lot of discussion for something so
> utterly uninteresting...
Heh - even I can't work out wot I rote...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ken" <tyl### [at] pacbellnet> wrote in message
news:4032CB5A.9277B9BA@pacbell.net...
>
As I implied ('capabilities'), and as Warp made explicit, the ideal would be an
expansion of the existing syntax rather than a replacement. However, ingo raises
a semi-valid point....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <ing### [at] tagpovrayorg> wrote in message
news:Xns94937169A2BACseed7@news.povray.org...
> in news:403332b3@news.povray.org Warp wrote:
>
> > Adding new features to the language does not mean you *must* learn
> > them.
> > It just means that they are available to those who find them useful.
>
> If I want to read and understand those future OO-scenefiles, I'll have to
> learn the new features. "Use" is more than just writing scenes.
>
Wouldn't this be a valid objection to introducing any new feature in pov?
Besides, OO sdl would - at least in my imagination - have few surprises in
comparison to the current sdl syntax....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly wrote:
> "Ken" <tyl### [at] pacbellnet> wrote in message
> news:4032CB5A.9277B9BA@pacbell.net...
>
>
> As I implied ('capabilities'), and as Warp made explicit, the ideal would be an
> expansion of the existing syntax rather than a replacement. However, ingo raises
> a semi-valid point....
Well, IMHO the whole idea of OO is to make the source more readable and thus
more maintainable. If Ingo's point is even a little bit valid I think OO
is better left out. At this point I cannot judge very well because I
still have no good perception of how an OOPOV would look, but perhaps
that is because I did not play anough with macros. FYI I do not program
in C++ or java, but I try to program as much in OO-style as I can in
Matlab. So in general I am in favor of OO.
Andrel
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4032CB5A.9277B9BA@pacbell.net>, Ken <tyl### [at] pacbellnet>
wrote:
> Not me. It would add another layer of complexity that I don't want to have
> to bother to learn. OO is for programming not a scene description language.
> If I wanted to learn programming I would do that rather than using POV-Ray.
You only say that because you don't know what it would add. It would not
add complexity, it would greatly simplify many things.
--
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 <Xns94937169A2BACseed7@news.povray.org>,
ingo <ing### [at] tagpovrayorg> wrote:
> If I want to read and understand those future OO-scenefiles, I'll have to
> learn the new features. "Use" is more than just writing scenes.
And reading and understanding the ugly, complex hacks used to work
around the lack of object oriented features would be easier?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> is better left out. At this point I cannot judge very well because I
> still have no good perception of how an OOPOV would look, but perhaps
There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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? ;) )
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom Melly" <pov### [at] tomandlucouk> wrote in message
news:4033cd07@news.povray.org...
> andrel wrote:
>
> > is better left out. At this point I cannot judge very well because I
> > still have no good perception of how an OOPOV would look, but perhaps
>
> There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?
I'm sorry; I know you didn't ask me. I have some ideas of how it could look:
object ColoredSphere (v, c) inherits Sphere
{
pigment
{
color = c
}
}
object red_sphere = new ColoredSphere (<1, -2, 3>, new Color(1, 0, 0))
object green_sphere = new ColoredSphere (<2, -2, 3>, new Color(0, 1, 0))
show red_sphere
show green_sphere
Off the top of my head, I could see this being useful. You could also do
this:
red_sphere.pigment.color = new Color.White
which you can't do right now.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <cjameshuff-9D70B1.13425418022004@news.povray.org>,
cja### [at] earthlinknet says...
> In article <4032CB5A.9277B9BA@pacbell.net>, Ken <tyl### [at] pacbellnet>
> wrote:
>
> > Not me. It would add another layer of complexity that I don't want to have
> > to bother to learn. OO is for programming not a scene description language.
> > If I wanted to learn programming I would do that rather than using POV-Ray.
>
> You only say that because you don't know what it would add. It would not
> add complexity, it would greatly simplify many things.
>
>
I am seriously confused about what it would simplify... SDL already does
most everything that OO stuff can. The one and only thing I can think of
is the ability to over-ride specific attributes, the way you can replace
an existing function in an object with a new one:
#define Motorcycle1 = object {Motorcycle}
object {
Motorcycle1 {
#replace Motorcycle1.Handlebars.texture{blah....}
}
}
So you could start with an entirely prebuilt object and change any single
item in it by directly replacing that item. However, for it to work, each
individual object would need a unique name or you would need to have some
way to index which of the objects in a CSG you are applying the changes
to or adding/removing.
Is the above sort of what you are talking about? Because otherwise I
don't get what OO feature you are talking about that the SDL doesn't
already support in some fashion...
--
void main () {
If Schrödingers_cat is alive
call functional_code()
else
call crash_windows();
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan P wrote:
> "Tom Melly" <pov### [at] tomandlucouk> wrote in message
> news:4033cd07@news.povray.org...
>
>>andrel wrote:
>>
>>
>>>is better left out. At this point I cannot judge very well because I
>>>still have no good perception of how an OOPOV would look, but perhaps
>>
>>There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?
>
>
> I'm sorry; I know you didn't ask me. I have some ideas of how it could look:
>
>
> object ColoredSphere (v, c) inherits Sphere
> {
> pigment
> {
> color = c
> }
> }
>
> object red_sphere = new ColoredSphere (<1, -2, 3>, new Color(1, 0, 0))
> object green_sphere = new ColoredSphere (<2, -2, 3>, new Color(0, 1, 0))
>
> show red_sphere
> show green_sphere
I do not see why the current syntax with macros does not suffice here.
>
> Off the top of my head, I could see this being useful. You could also do
> this:
>
> red_sphere.pigment.color = new Color.White
Well if it allows you to have an object that is called red_sphere but
is actually white then we are in deep trouble.
Just kidding, I understand what you mean. My first reaction would be
that pigments can be much more complicated than just a simple color.
That is what POV makes exciting. I do not immediately see how you can
handle that complexity in a understandable way. I will think about that
(later).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <cja### [at] earthlinknet> wrote
> In article <Xns94937169A2BACseed7@news.povray.org>,
> ingo <ing### [at] tagpovrayorg> wrote:
>
> > If I want to read and understand those future OO-scenefiles, I'll have to
> > learn the new features. "Use" is more than just writing scenes.
>
> And reading and understanding the ugly, complex hacks used to work
> around the lack of object oriented features would be easier?
Or understanding entries to the short code contest? ;)
But seriously, I've seen plenty of scene files where I don't have a clue what's
happening, like where they use some feature of pov that I've never seen before.
Sometimes I think it's worth reading the manual to find out what it does,
sometimes I decide I'd rather not know. I don't think OO would make this much
worse.
Though I do think OO would run the risk of getting too far away from the SDL
being a language to describe scenes (objects that are conceptual not visible!?).
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think there's a lot of confusion between OO objects and pov's object {}. I
never intended for the two to be the same thing.
What I need for my scene is the concept of a data structure which can hold a
series of "function" calls (actually macro calls) according to what type of
structure it is. It does not need to be associated with anything renderable.
This just extends the range of possibilities for how pov's macro language can be
used to perform calculations or procedural scene generation, etc.
I can see some uses for having OO objects associated with pov objects, but I
think it would REALLY defeat the point if you are forced to have that
association. For example, you could create a tree using an object that creeps
along the trunk, leaving a trail of spheres, then spawns another object for each
branch, etc... so there would be many more spheres than there are OO objects.
Anyway, just my 2 cents. I'm gonna get on and write my macros :)
--
Tek
www.evilsuperbrain.com
"Patrick Elliott" <sha### [at] hotmailcom> wrote in message
news:MPG.1a9d8de2d9dc8dc39899ad@news.povray.org...
> In article <cjameshuff-9D70B1.13425418022004@news.povray.org>,
> cja### [at] earthlinknet says...
> > In article <4032CB5A.9277B9BA@pacbell.net>, Ken <tyl### [at] pacbellnet>
> > wrote:
> >
> > > Not me. It would add another layer of complexity that I don't want to have
> > > to bother to learn. OO is for programming not a scene description
language.
> > > If I wanted to learn programming I would do that rather than using
POV-Ray.
> >
> > You only say that because you don't know what it would add. It would not
> > add complexity, it would greatly simplify many things.
> >
> >
>
> I am seriously confused about what it would simplify... SDL already does
> most everything that OO stuff can. The one and only thing I can think of
> is the ability to over-ride specific attributes, the way you can replace
> an existing function in an object with a new one:
>
> #define Motorcycle1 = object {Motorcycle}
>
> object {
> Motorcycle1 {
> #replace Motorcycle1.Handlebars.texture{blah....}
> }
> }
>
> So you could start with an entirely prebuilt object and change any single
> item in it by directly replacing that item. However, for it to work, each
> individual object would need a unique name or you would need to have some
> way to index which of the objects in a CSG you are applying the changes
> to or adding/removing.
>
> Is the above sort of what you are talking about? Because otherwise I
> don't get what OO feature you are talking about that the SDL doesn't
> already support in some fashion...
>
> --
> void main () {
> If Schrödingers_cat is alive
> call functional_code()
> else
> call crash_windows();
> }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"andrel" <a_l### [at] hotmailcom> wrote in message
news:403### [at] hotmailcom...
>
> > "Tom Melly" <pov### [at] tomandlucouk> wrote in message
> > news:4033cd07@news.povray.org...
<snip />
> > red_sphere.pigment.color = new Color.White
> Well if it allows you to have an object that is called red_sphere but
> is actually white then we are in deep trouble.
Heheh :-)
> Just kidding, I understand what you mean. My first reaction would be
> that pigments can be much more complicated than just a simple color.
> That is what POV makes exciting. I do not immediately see how you can
> handle that complexity in a understandable way. I will think about that
> (later).
Could do red_sphere.pigment.image_map.file and stuff too. Any level of
indirection. OO gives smarter people than I the ability to do things I'd
never dream of with it. The more flexible the code can be, the more people
will find ways to do new, interesting stuff.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan P <dan### [at] yahoocom> wrote:
> new ColoredSphere
> new ColoredSphere
> new Color.White
Aaargh! No, no and no.
The fact that you must fill your code with the 'new' keyword in Java does
not mean it's a good thing.
Why force the user to do that? In all those cases the 'new' keyword is
obsolete. It contributes nothing to the code.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott <sha### [at] hotmailcom> wrote:
> I am seriously confused about what it would simplify... SDL already does
> most everything that OO stuff can.
It certainly does not.
One of the basic features of an object-oriented language are modules.
A module (in OO languages usually called a class) has a state (defined by
its attributes, ie. member variables) which can be modified with the methods
(ie. member functions) of the module. In well-designed OOP the state of the
module is private and can only be modified through the public methods (the
principle of abstraction, an extremely important principle in good
programming).
You can create instances of modules, and modules can have other modules
or references to other modules (even of its own type) as attributes. (Among
tons of other things, it allows you to make eg. linked lists of module
instances.)
A second basic feature of an OO language is inheritance. You can create
a new module which implements everything some other module implements
plus more (this is usually called specialization).
Among other things, inheritance allows making more abstract, generic
functions to handle different types of modules (given that they have been
inherited from a common base class).
Some modules may even be defined as abstract, meaning that they can't be
instantiated directly (because it wouldn't make any sense) but must be used
through inheritance.
A third basic feature, related to inheritance, is dynamic binding. You
can declare virtual functions in a base class which the inherited classes
can implement. When a function having only a base class reference calls
this virtual function, the proper inherited function is called (even
though the caller doesn't have any knowledge about the inherited classes).
The POV-Ray SDL does not implement anything of this.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> (the principle of abstraction, an extremely important principle in good
> programming).
I rest my case.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:40348068@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > new ColoredSphere
> > new ColoredSphere
>
> > new Color.White
>
> Aaargh! No, no and no.
>
> The fact that you must fill your code with the 'new' keyword in Java
does
> not mean it's a good thing.
> Why force the user to do that? In all those cases the 'new' keyword is
> obsolete. It contributes nothing to the code.
I see what you're thinking of on this. I think it is there for clarity --
the compiler could always check to see what has been defined and decide to
either create a new class there or use the reference. I believe (and this
is just a personal thing) that the readability of the code is just as
important as the execution of the code because, even if you write a program
in a vacuum without anybody else seeing it, /you/ still have to look at your
code later. Thing is, I see people write really hard-to-read code often and
I figure it could be: a. they don't want you to understand their code, b.
they think it will go magically faster if it is all scrunched together and
the variable names are shorter, c. they want to put as much on the screen as
they can, d. their fingers really hurt and typing causes physical distress,
e. they are so amazingly smart that they can instantly conceptualize the
code no matter how obfuscated it is, or f. they just have bad habits and
don't care. I'm guessing f. :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan P <dan### [at] yahoocom> wrote:
> I see what you're thinking of on this. I think it is there for clarity --
> the compiler could always check to see what has been defined and decide to
> either create a new class there or use the reference.
The reference to what?
The thing after 'new' is a type. How can you make a reference to a type?
Where should the reference point to?
You can make your scripting language interpreter so that instances are
always created dynamically for simplicity (that way you don't have to
make the distinction between a local variable and a reference because
everything is a reference, like in Java). However, the 'new' keyword
does not contribute anything to this. It's obsolete and can be
completely left out without the expressive power of the language
being degraded.
Have you ever wondered why you are not forced to define all your
objects in POV-Ray inside object{} blocks, why you are not forced to
put all your material and texture statements into material{} and
texture{} blocks, etc?
Because forcing the user to write something unnecessary is only
a burden, not a help.
Even more, object{}, material{} and texture{} are sometimes necessary.
However, I can't imagine a situation where 'new' would be necessary
(assuming we are dealing with a language where all class instances
are created dynamically, as in Java).
--
#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:
> > One of the basic features of an object-oriented language are modules.
> FWIW, there are many modular languages that aren't OO.
So?
I didn't say modules are a sole feature of OO languages. I said that
modules are a minimum requirement for a language to be OO.
A good example of a modular language which is not OO is modula. It has
modules (created not very surprisingly with the keyword 'module') which
contains member variables, member functions, private and public parts, etc.
However, since it does not have (AFAIK) inheritance and dynamic binding
it's not an OO language, only a modular one.
> > A second basic feature of an OO language is inheritance.
> FWIW, there are many OO languages that don't support inheritance.
Then they are not object-oriented languages. Some kind of inheritance is
a basic feature of object-oriented languages.
The whole idea of object-orientedness is that you can have a hierarchy
of objects (from more abstract to more specific). If you can't build such
hierarchy, then it's not object oriented.
> Inheritance is something different, designed to
> allow you to share code between different parts of your program, to ease
> maintenance.
Nope, that's a way too narrow way of defining inheritance.
It's true that inheritance can (and should) be used to group common
code into a single module. However, that's not the only (and depending
on who you ask not even the most important) reason for inheritance.
There are other ways of grouping common code into single modules,
such as composition (ie. a class having another class as member variable).
You don't necessarily need inheritance for this.
> > A third basic feature, related to inheritance, is dynamic binding.
> Dynamic binding is not really necessarily related to inheritance, and
> vica versa. That's just an artifact of how popular OO languages handle it.
Lack of dynamic binding would make inheritance more or less obsolete.
If you are going to use inheritance without dynamic binding you could
as well use compositionality instead.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:40350372@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > I see what you're thinking of on this. I think it is there for
clarity --
> > the compiler could always check to see what has been defined and decide
to
> > either create a new class there or use the reference.
>
> The reference to what?
> The thing after 'new' is a type. How can you make a reference to a type?
> Where should the reference point to?
I made everything objects. I don't know what I was thinking there, though --
it should be new Color(Color.White), not new Color.White. I'm braindead
today.
> You can make your scripting language interpreter so that instances are
> always created dynamically for simplicity (that way you don't have to
> make the distinction between a local variable and a reference because
> everything is a reference, like in Java). However, the 'new' keyword
> does not contribute anything to this. It's obsolete and can be
> completely left out without the expressive power of the language
> being degraded.
To create the object dynamically without the new keyword, the interpreter
would need to look up whether what proceeds it is a Class or something that
the user already defined. That would not effect small scenes, but in scenes
with hundreds of thousands of objects, it would show in the parse time. By
using new, the interpreter /knows/ that what follows it is a class.
> Have you ever wondered why you are not forced to define all your
> objects in POV-Ray inside object{} blocks, why you are not forced to
> put all your material and texture statements into material{} and
> texture{} blocks, etc?
Nope. You're right -- object is implied.
> Because forcing the user to write something unnecessary is only
> a burden, not a help.
>
> Even more, object{}, material{} and texture{} are sometimes necessary.
> However, I can't imagine a situation where 'new' would be necessary
> (assuming we are dealing with a language where all class instances
> are created dynamically, as in Java).
I think it would be a really good idea to make everything an instance of a
class. I'm thinking more like Smalltalk where there are no primitives
(that's what I was thinking when I did the Color.White screw-up -- no
primitives). If the parser is written correctly, this should not affect
parse time. However, what I was thinking was more something that isn't like
a scripting language, but instead, enables structured OO programming for
complex logic and true abstraction.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Then they are not object-oriented languages. Some kind of inheritance is
> a basic feature of object-oriented languages.
I'm not entirely sure that's true. The concept of an object does not implicitly
require inheritance, since the principles of modularity with private states etc
can still apply, and as such a language can be oriented about objects without
needing inheritance. Though all the OO languages I know of do have inheritance.
I'm trying to thing back to the OO analysis and design course I did on my
degree, but I can't honestly remember whether it considered inheritance to be
fundamental to OO...
> > Inheritance is something different, designed to
> > allow you to share code between different parts of your program, to ease
> > maintenance.
>
> Nope, that's a way too narrow way of defining inheritance.
>
> It's true that inheritance can (and should) be used to group common
> code into a single module. However, that's not the only (and depending
> on who you ask not even the most important) reason for inheritance.
I agree. For example, the only reason I'm planning to implement inheritance is
so that I can have an interface class with virtual functions. No shared code
whatsoever.
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan P <dan### [at] yahoocom> wrote:
> To create the object dynamically without the new keyword, the interpreter
> would need to look up whether what proceeds it is a Class or something that
> the user already defined. That would not effect small scenes, but in scenes
> with hundreds of thousands of objects, it would show in the parse time. By
> using new, the interpreter /knows/ that what follows it is a class.
Believe it or not, there are faster ways of searching than linear search.
Even if you have 4000 millions of names, you can find a specific one
by doing at most 32 comparisons.
In the same way, adding a new name to the set of existing names requires
at most 32 comparisons and other operations.
Besides, what does it help to tell the interpreter that "what follows is
a type"? By that you can at best just cut the amount of items to search
to half (to 2000 millions in the example above).
> I think it would be a really good idea to make everything an instance of a
> class.
There's a reason why in Java everything is not an instance of a class.
--
#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:
> > Then they are not object-oriented languages. Some kind of inheritance is
> > a basic feature of object-oriented languages.
> I'm not entirely sure that's true. The concept of an object does not implicitly
> require inheritance, since the principles of modularity with private states etc
> can still apply, and as such a language can be oriented about objects without
> needing inheritance. Though all the OO languages I know of do have inheritance.
Don't confuse modules with object-orientedness.
As I explained previously, modules are a minimum but not sufficient
requirement for an OO language.
If you have modules with no inheritance and no dynamic binding what
you have is a modular language, not an OO one. Modula3 is an example of
this.
> I agree. For example, the only reason I'm planning to implement inheritance is
> so that I can have an interface class with virtual functions. No shared code
> whatsoever.
So basically you will have interfaces (such as in Java) but no inheritable
classes?
The problem with that is that it forces code repetition, which is not
good (IMHO this is a bad problem in Java interfaces). Besides forcing the
user of the interface to implement things which may be useless, it makes
it too easy to break the true "is-a" relation between base and derived
classes (in other words, when you make code which handles objects of
the type of a certain interface you just have to trust that the inherited
class implements all of its methods properly; you can't force a certain
method to work always in a certain way).
--
#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:
> > Then they are not object-oriented languages. Some kind of inheritance is
> > a basic feature of object-oriented languages.
> This isn't correct. There are, for example, delegation-based OO
> languages, wherein you say "Anything I don't handle, that other class
> over there handles", but it's not an inheritance heirarchy as such. It's
> merely delegation.
Who defines that object-orientedness may not have inheritance?
The "is-a" (and "has-a") relation between classes is a fundamental
property of object-orientedness.
> No, this is not correct. While it's true that most popular
> object-oriented languages support inheritance, you can have OO languages
> without inheritance.
In what basis can you call it an OO language?
Having modules is not sufficient.
> Imagine Java with no inheritance of functions, only "inheritance" of
> what java calls interfaces. Does it stop being "object oriented"? Most
> people working in the field of designing programming languages I think
> would say "no, it's still OO". It still has objects, dynamic dispatch,
> memory management, classes, instances, etc. Just not inheritance.
If you inherit class X from class Y you are saying "X is a Y" (that is,
it implements everything Y implements and behaves like Y).
Y may be completely abstract, meaning that it does not implement anything
itself. However, deriving a class from it still means that the derived
class "is a Y".
If you make a class which implements an interface you are doing inheritance.
Limited perhaps, but still inheritance.
(By the way, what does memory management have to do with OO?)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:4035e6de@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > To create the object dynamically without the new keyword, the
interpreter
> > would need to look up whether what proceeds it is a Class or something
that
> > the user already defined. That would not effect small scenes, but in
scenes
> > with hundreds of thousands of objects, it would show in the parse time.
By
> > using new, the interpreter /knows/ that what follows it is a class.
>
> Believe it or not, there are faster ways of searching than linear
search.
Yep, I know; I spent an entire summer building AVL trees and heaps. But it
is /still time/ and, in a loop, that time adds up.
> Even if you have 4000 millions of names, you can find a specific one
> by doing at most 32 comparisons.
> 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.
> Besides, what does it help to tell the interpreter that "what follows is
> a type"? By that you can at best just cut the amount of items to search
> to half (to 2000 millions in the example above).
In a loop, that makes a difference.
> > I think it would be a really good idea to make everything an instance of
a
> > class.
>
> There's a reason why in Java everything is not an instance of a class.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
