Dear POV-team,

I am about to write my Master of Arts thesis in computer science this
spring, and have a proposal that I want you to think about:

Even though I don't know anything about the current plans on development
of OO-POV-script, I recall a discussion of making the POV-script
language object-oriented. As I feel very strongly about POV (and feel
that I have the ideas and knowledge needed) I was thinking about
developing a BNF (and possibly also UML) for an OO-POVscript as a part
of my thesis that you, the POV-team, could use for further
development/implementation.

I have talked to my tutor who gave me permission to continue, provided
that I first talked to you (the POV-team).

Some ideas about the OO-POVscript:
- The OO-version should be fully backwards-compatible with current
syntax.
- The OO-features should be somewhat "simplified" - i.e, targeted at
users, not developers
- The main purpose of the OO is to provide advanced users (such as
writers of include files) with a set of powerful tools that you don't
have to use if you just want to describe a scene (backwards compability)

Please take your time to think it over. I would really enjoy to do this
for my Master of Arts thesis, but if this would be of no use to you,
I'll just have to think of something else!

Best regards,

- Mikael.

----------------------------------------------------
Mikael Carneholm
Dep. of Computer Science and Business Administration


Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse

Post a reply to this message

Mikael Carneholm wrote:
> 
> Dear POV-team,
> 
> I am about to write my Master of Arts thesis in computer science this
> spring, and have a proposal that I want you to think about:

Hi Mikael,

  I'll make sure that the POV-Team is made aware of your proposal and
that you recieve a proper response to it.

-- 
Ken Tyler - POV-Ray Technical Assistance Group Member.

Post a reply to this message

Mikael,

I think this would make a very good topic - there is a lot of
material buried on this newserver, and it would be great for
someone to have the opportunity to form a solid proposal.
Whether or not your proposal is adopted, it would make a very
good point of discussion and reference, especially if you're
studious about your reasoning, assumptions and the pros and
cons.

The only thing I would suggest is thinking carefully about
the backwards compatibility criteria.  I think the user
community could tolerate something resembling the current
syntax - assuming that there are reasonable benefits.
On the one hand, backwards compatibility helps narrow the
possible solutions, but on the other - limit the benefits.

One other thing - consider the "serialisability" in terms
of 3rd party applications reading, writing and manipulating
these data structures.  This is one weakness in the current
setup that could bear some serious thought.

And finally - extensibility.  The POV team are opposed to 
a binary plug-in architecture on the basis of portability.
The ability to create a module without having to edit any
code in the core of POV would be a very nice feature.
Can we think of POV as a platform proving services to 
independent modules, rather than relying on a central parser?
What are the implications for the scene description syntax?

Plenty of juicy ideas to tackle... Have fun!

Nigel

Disclaimer - I speak for myself, not the POV team.
 
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer, Tokyo Dweller
Ignorance + Internet = 1984

Post a reply to this message

In article <385FCAA2.2CF0A7CF@nigels.com>, nig### [at] eisanetau wrote:
>And finally - extensibility.  The POV team are opposed to 
>a binary plug-in architecture on the basis of portability.
>The ability to create a module without having to edit any
>code in the core of POV would be a very nice feature.
>Can we think of POV as a platform proving services to 
>independent modules, rather than relying on a central parser?
>What are the implications for the scene description syntax?


One of the things I thought would be interesting for macros, would be to 
make them look like normal POV syntax. That is, instead of calling 
"makeTree(5,3,1)", call:

makeTree {
   recursion 5
   rotation 3
   translation 1
}

It would make it easier, later on, to decide that the macro would be 
useful to incorporate as faster code within POV, and have syntax issues 
already worked out.

Jerry

Post a reply to this message

Mikael Carneholm wrote:
> 
> Dear POV-team,
> 
> I am about to write my Master of Arts thesis in computer science this
> spring, and have a proposal that I want you to think about:


Mikael,

 I passed on your proposal to the POV-Team and recieved the following
response. Although the reply is short it does appear that they would
be willing to take a close look at your work when you are finished.


Ken wrote:
>
> FYI,
>
>    This message was posted in the programming group today and I felt it
> was worthy of your attention. I responed to Mikael that I would mention
> it to you and that some form of reply would be forthcoming.

Chris Cason of the POV-Team replied:

I think this is a great idea. I'd look forward to seeing what he came up with.

-- Chris C

Post a reply to this message