On 12/11/06, Robert Osfield <[EMAIL PROTECTED]> wrote:
Hi Bertrand, On 12/11/06, bertrand greslier <[EMAIL PROTECTED]> wrote: > Of what advanced use of C++ do you talk about excatly ? Templates is the biggy.
Templates exist in java since version 1.5 ...
The parsing could be a fork and a first start for the java implementation. You have to look to the practicalities of parsing C++ and converting to Java and the maintainence thereafter. Personally I think this avenue will just be a nightmare and the branched project would soon collapse.
I have study the tools and it is possible to parse easily with javaCC..., now I am able to do it. But you are right the fork is not a good solution because of there is two versions to maintain. And the parse is generally not a good solution, often a nightmare and collapse if you lost implementation information. But my first idea is than all princip of C++ are in bijection with java C++ class <-> java class C++ template <-> java template C++ attribute <-> java attribute C++ method <-> java method Except these real difficulties : C++ OpenGL <-> api jogl jsr-231 or other. (ok for me) multi-inheritance <-> equivalent mecanism in java. (ok for me) STDlib <-> java implementation of stdlib or java equivalent. (to think about) another ?? IMHO, one has to think of light weight and maintainable solutions.
Rather the above perhaps writing in an intermediate implementation language and tool to generate multiple language implementations from this would be easier than forking the code. I don't of any such solution though.
And today only C++ implementation of osg exist. Thus for me only C++ can be the intermediate language to port osg in java (todo a 100%java implementation) because nobody want rewrite all the api for pleasure.
I think data component is not sufficient, the api is as much important the > data and should be specified and standardized. The API basically creates/read/writes/destroys and does operations on data. If you formalise the data then much of the API for interacting with it follows automatically. If you want to exchange data then formalising this aspect will be key.
I don't want make exchange data. If I want do this, if have just to implement or use read/write plugin on a choose format like osg, 3ds, collada... I am speak about implementation and devel language with a scene graph.
But yes only the data can be serialized. If these is a new objects witch > doesn't exist in the local language, > the user must implement the same or his own implementation for this chunk of > data. Well if there isn't an implementation locally then you'd just have to carry the data around of discard it. With scripting languages data and implementation can actually be very closely coupled so this needn't be so much of any issue, but this is a bit of orthogonal problem. > > This is obviously a major departure from how develop the OSG right > > now. I touched on this topic in my Siggraph 2006 talk presented by > > Mike Weiblen in our Bird of Feather sessions. Have a look on the OSG > > website documentation page for links to this and other presentations. > > I have just read presentations but it seem me be very poor in informations > and how it could be done. It was only a short presentation, speculating on what future routes might be possible. Its not meant as concrete proposal. My own focus for the next six months will be more the immediate goals of improving the C++ core and interoperability with other languages via osgInterspection.
osgIntropection is a very good tool for C++, with the osgIntrospection osg become a sort of JVM than exec scripts and it is great. Also this mecanism can be ported to java without difficulties because introspection natively exist in java since the beginning of java in the java.lang.refect package. I have to say that this project is just an idea, a proposition, I have send the mail to have good advices. If everybody think it is a bad solution, I won't do this and collapse. If you have a better solution to generate a 100% java implementation of OSG, I take it now. Because I don't want adopt another java scene graph, I think osg api is best, and I want the best solution. -- Bertrand Greslier http://www.cooki3d.org
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
