On 20 Jul 2000 05:58:42 -0400, Warp wrote:
>John VanSickle <van### [at] erolscom> wrote:
>: Will it parse faster?
>
>: If not, forget it.
>
>  Oh, so then we should remove #while-loops, #macros and even #defines. They
>only slow parsing, don't they?

We did forget #defines. :) 

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: We did forget #defines. :) 

  Oops... I meant #declares, of course... :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

>   Oops... I meant #declares, of course... :)

:-D    I find myself typing in #define too.

What about the #locals?
Brendan

>
>

Post a reply to this message

"Oh, so then we should remove #while-loops, #macros and even #defines. They
only slow parsing, don't they?"

Well said, Warp.

However, I disagree with you statment
"it would be of little use to the average user who knows little or nothing
about programming (who are still fighting on understanding how #while-loops
and #macros work...)."

If OOP was done *right* in POV, it would be at the very core of the
language. Writing "sphere{...}" would create a an *object of the class
"sphere"* Everything would be object oriented. To the one learning the
language, object oriented structure would be as fundamental as placing
lights and cameras.

    Now, when a heard that POV 4.0 would be object oriented, my reaction was
"What, the current POV isn't OOP?!?". My aw of the POV Team grew as a
learned that they create such a raystacer WITHOUT oop! But for OOP to really
work, it must be *fully* oop.

I'm all for an object oriented POV-Ray language, as long as it is fully
object oriented.

Post a reply to this message

In article <B59F94A4.17F9%dav### [at] maccom> , David <dav### [at] maccom>
wrote:

>     Now, when a heard that POV 4.0 would be object oriented, my reaction was
> "What, the current POV isn't OOP?!?". My aw of the POV Team grew as a
> learned that they create such a raystacer WITHOUT oop! But for OOP to really
> work, it must be *fully* oop.

While today this may sound unbelievable, ten years ago when POV-Ray was
created it was absolutely state of the art to write programs in good-old C.
Even today there is nothing 'wrong' with a C program, despite the biz around
object orientation.


     Thorsten

Post a reply to this message

David <dav### [at] maccom> wrote:
: If OOP was done *right* in POV, it would be at the very core of the
: language. Writing "sphere{...}" would create a an *object of the class
: "sphere"* Everything would be object oriented. To the one learning the
: language, object oriented structure would be as fundamental as placing
: lights and cameras.

  But povray already does this.

  When you write this:

#declare MySphere = sphere { 0,1 pigment { rgb 1 } }

what you are actually doing is defining a new object (or class if you like
that name) named 'MySphere'. Now 'MySphere' can be considered a new type,
extactly like a class can be considered in C++/Java.
  Now, when you write this:

object { MySphere }

you are actually creating an instance of that object (class). You can even
modify the attributes of the object (in a quite limited way, but still you
can do it). For example:

object { MySphere translate <1,2,3> }

  And by the way, this is not yet object-oriented programming. This is
modular programming. The first modular programming languages (like Modula2)
already had classes (called "modules") with member attributes, member
functions, public and private parts, etc.
  You get an object-oriented language when you add inheritance and dynamic
binding to this. Adding these to povray would be a quite laborious job and
would probably benefit little to regular non-programmers.

:     Now, when a heard that POV 4.0 would be object oriented

  No-one has said that pov4 would be object-oriented. Yes, its _source code_
will be object-oriented (that's the point of making it in C++ after all), but
no-one has said that the povray scripting language will change that much.
  And by the way, the source code of povray IS already object-oriented.

, my reaction was
: "What, the current POV isn't OOP?!?". My aw of the POV Team grew as a
: learned that they create such a raystacer WITHOUT oop! But for OOP to really
: work, it must be *fully* oop.

  Now I'm not sure if you are talking about the source code or the povray
scripting language. As I said, the source code is OO (although made in C).
The scripting language has some OO (or more precisely modular programming)
characteristics.

: I'm all for an object oriented POV-Ray language, as long as it is fully
: object oriented.

  Well, perhaps inheritance and dynamic binding could have some uses in the
povray scripting language, but do you really think it's worth the efforts?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

> No-one has said that pov4 would be object-oriented. Yes, its _source code_
> will be object-oriented (that's the point of making it in C++ after all), but
> no-one has said that the povray scripting language will change that much.
> And by the way, the source code of povray IS already object-oriented.
    Yes, what a mean is the SOURCE CODE would be object-oriented.
    Now, how can you get OOP is C?
> 
> , my reaction was
> : "What, the current POV isn't OOP?!?". My aw of the POV Team grew as a
> : learned that they create such a raystacer WITHOUT oop! But for OOP to really
> : work, it must be *fully* oop.
> 
> Now I'm not sure if you are talking about the source code or the povray
> scripting language. As I said, the source code is OO (although made in C).
> The scripting language has some OO (or more precisely modular programming)
> characteristics.
    I mean the source code.
> 
> : I'm all for an object oriented POV-Ray language, as long as it is fully
> : object oriented.
> 
> Well, perhaps inheritance and dynamic binding could have some uses in the
> povray scripting language, but do you really think it's worth the efforts?
    Yes, I think it would be, if only for the sake of TRUE OOP.
    And by fully OOP, I mean in APPLICATION, more then concept.

Post a reply to this message

In article <B5A0E746.17FD%dav### [at] maccom>, David 
<dav### [at] maccom> wrote:

>     Yes, what a mean is the SOURCE CODE would be object-oriented.
>     Now, how can you get OOP is C?

Uh, ever hear of structs?
One example is the way POV handles objects, the struct for each shape 
has a bunch of function pointers for shape-specific tasks, so it usually 
doesn't have to care about what kind of object it is.
BTW, C++ originally was translated to plain C...C is capable of 
everything C++ is, you just have to do more work to get it done.


> > Well, perhaps inheritance and dynamic binding could have some uses 
> > in the povray scripting language, but do you really think it's 
> > worth the efforts?
>     Yes, I think it would be, if only for the sake of TRUE OOP.

Well, to do something just for the sake of doing it isn't usually the 
best way to go about designing things...


>     And by fully OOP, I mean in APPLICATION, more then concept.

Well, inheritance would be like this: each copy of the object gets 
copies of the originals members, unless it is overridden. I doubt 
multiple inheritance would be that useful, but you could add a keyword 
to do so. Private, protected, and public members wouldn't be necessary 
for this, everything would be public. You would just be adding unneeded 
complexity otherwise.
And I don't think different types of binding even make sense in the POV 
language...

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

In article <3975DC6C.3C023FF2@itam.cas.cz>, Disnel <dis### [at] itamcascz> 
wrote:

> 2) No one talked about virtual methods, although its big advantage, I
> think.

I don't think they would apply to POV-Script...their main use is when 
referring to objects by pointers, and POV-Script doesn't have pointers. 
I think that *all* methods would behave "virtual", separate bindings 
would be useless in POV-Script.


> This is true when you don't allow changing objects after they have been 
> parsed, but I think, that can be one great advantage, mainly in
> persistent animations.

I don't see what you mean...why would changing the object be a problem? 
If you mean adding members to an existing variable, then don't do that! 
It would be like trying to add variables and methods to a C++ class. 
Just make a new object from that one, which has the additional members 
you need.
If you mean modifying an object which has been placed in the scene, and 
isn't a variable, then (again) don't do that! Modify the object, and 
*then* put it in the scene. This will work with persistent variables 
just fine...

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

> Uh, ever hear of structs?
    Can a struct have functions as well is vars? Can a struct have protected
members? Can a struct have inheritance? Are structs encapsulated? Ect.

> Well, to do something just for the sake of doing it isn't usually the
> best way to go about designing things...

That's not what I mean. Look one level deeper. I don't want it just for the
sake of OOP. I want it for the sake of OOP for the sake of the *application*
of OOP.

Post a reply to this message