"J. Grimbert" wrote:
 
> Ad hominem first:
>  I bet you just learned about C++ at school,
>     get some lessons on parsing and
>     some other on project management with experienced people,
>     but have yet no real first hand experience by yourself.

Now that was rather mean, J. Grimbert. :)

FYI:

 I am years past school;
 I have 12 years of practical programming experience;
 I have written some programs before using similar principles;
 My sphere of interests is designing with objects and design of
hierarchical polymorphic systems;
 I shun C++ because it tempts me to write kludgy code - so I stick with
Object Pascal to ensure clarity of design in my projects;
 I do not think that yacc and lexx are the best things for parsing too.
;)

Not quite the picture you painted.

(Hmm, loooks like I am spilling personal info after all...)

>     Moreover, you think too much by yourself before exposing your idea
>     to the community. 

True. Sometimes an outsider's view can shed a light than someone's whose
eye is too involved, not seeing the forest behind the trees.

>So you will fail to get adhesion to your ideas.

Adhesion to ideas I do not seek, I am not here to start a cult. If
something good grows from the ideas, I'll be happy. If not, there are
many things in the world.
 
> The only way I can see to implememnt your design is to have
>  the rendering engine as a C++ library which is missing one object
> with two method: create() and trace(). The object is of course the
> scene to render. and trace() is in fact inherited from the library,
> so only the create method need to be written by the artist.

That's the way you see, which may be different from mine. In fact, it is
different from mine, so there's obviously more than one way to implement
my design. 

For one, if we get technical, I'd have not only Create() and Trace(),
but also Timer(), and Parse() with its framework.

The artist would not, of course, need to write a line of C/C++ code. The
object creator ("patch writer") would mostly implement Trace() for each
object and configure Parse(). The artist will use script just as it is
done currently.

> Your SDL will in fact be C++ itself.

Wrong. It will be a set of self-parsing, self-organizing, self-tracing
objects.

> To parse will be to compile & link,
> to render will be to execute the program.

Wrong.

> <Irony on>
> You're just asking the artist to learn C++ instead of Pov SDL.
> But as YOU already know C++, it's obviously no-cost for everybody else.
> <Irony off>

Irony missed, sorry. This was neither meaning nor word nor intent.
 
> You have nevertheless some good points in pointing out some problems
> that do exists in pov 3. It is the only interest of your design.

I come to think that pointing out problems was not exactly the main
point of the document.

> But IMNSHO your solution stinks.

Does it? Well, what you have described is "your idea of my solution".
 
> you would know that a really unified object class really does nothing excepted
> prototyping, because each specific object class must rewrite all or part
> of the method and extend the data!

That is PWIM - Precisely What I Meant. :)


Thank you for your time and nerve!

Post a reply to this message