Dirk Reiners wrote: > Hi All, > > Marcus Lindblom wrote: > >> This has me thinking that it should be possible to adapt fcdProcess to >> emit boost::python bindings for Fields, so that we get something really >> spiffy that handles a lot of stuff for free (with this framework not >> having to belong to a graphics system). >> >> > Separate topic. But yeah, we could do that. > For 2, will the base FC-code be in a separate dll from the graphics stuff? If so, we are very nearly there. > Allen Bierbaum wrote: > >> I hadn't really thought about using fcdProcess to do this. It may work, >> but what I was really hoping was that with OpenSG2 we could put a >> framework in place with the fc's (once they stabalize) to just use the >> reflective interface to automatically discover and create the python >> class definitions at run-time. >> >> > I like the run-time idea because it would automatically pick up whatever > extensions are loaded. Using an fcd-based preprocessor or a tool that > dumps stuff from the linked OpenSG lib would be a preprocess that needs > to be rerun whenever something changes. > Well, if you have one fcd-preprocessor you might as well have two. :)
Dumping from the compiled & linked libs is ok _if_ you could emit it for one lib at the time, so you could ship OSGMyplugin.dll and OSGMyPlygin(XML/Java/Python).dll and be done with it. But run-time introspection is of course nice as well. That would allow for ppl to develop run-time binding plugins in c++ only. Given that the target language only has dynamic type checking (python qualifies). To bind to statically checked languages (such as java or .net) you would still need to export stuff from the linked libraries. Well, for VM-languages you could make a byte-code generator. Nut I don't really see how you could make the java/.net - compiler happy since it can't verify that the opensg-package exists at all, unless, you just make a wrapper for opensg's dynamic-API. However, that would make as much sense as the reflective interface in c++ instead of making direct calls. Actually, it might make some sense in some instances (such as my xml-bind or in a dump-system), but for actual code that does real stuff it'd be a pain, methinks. >> Right now what I am doing is much more brute-force and uses py++ to >> generate bindings for everything using the "user API". (see: >> https://realityforge.vrsource.org/view/PyOpenSG/WebHome) >> >> In other words I don't interface to the fields at all. I think it would >> be possible but it doesn't seem to be the "real" interface for OpenSG >> and after talking with Dirk I realized that there are places in the code >> where using only the field container interface will not work because the >> code needs the side-effects that happen as a result of calling the >> user-api interface instead. >> >> > I consider those places bugs. The Field-Interface has to work > completely, or it's not useful, IMHO. > Is it possible to design something that works solely with data like that? It seems to be kind of difficult, but I'm no wizard. :) Most other designs I've seen tend to mask set/get-calls as simple data without side-effects, rather than the other way around. The set/get-pattern is seen in ActiveX/COM, JavaBeans, Python, etc. Making a reflective interface is good, but having it work on data and a changed() function seems, to me, a bit awkward and error-prone. Are there other succesful systems that have used that? As a sidenote, should the reflective system contain only to/from string or should there be a "Variant" data type for common types (int/float/char/vec/matrix) as an optimization when binding to other languages that supports this (i.e python/java/lua)? I suggest strings as a start (good baseline) and move on from there if need arises. Might be worth a thinking though. Cheers, /Marcus ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
