"Eleanor McHugh" <eleanor / games-with-brains.com> schrieb im Newsbeitrag news:EB9CAC98-287B-4BBC-8FFF-3C829F38C47E / games-with-brains.com... > On 6 Jun 2009, at 22:05, Michael Bruschkewitz wrote: >> This interface knowledge is not related to particular projects, but >> to languages. There is only the need for some common interface >> format. How interfaces are exported/imported could be completely >> transparent to the developer. Such an converter needs to be created >> only once per language. > > This is a naive assumption as it ignores the fact that many languages > either have loose standards or no standard at all, therefore the > amount of work required to implement such converters could be many > orders of magnitude greater than that required to learn an FFI > extension such as ruby/dl or ruby-ffi. I would not expect the converters to be complete at all. They could just issue a error message when user tries to use features which are currently not supported (by converter or by peer language). Converters would need to be implemented only once per language and platform. By one small team which needs strong knowledge about interface issues for this particular language and platform only. The ruby/dl or ruby-ffi is a different approach, accessing existing libraries. My thoughts were more RAD-like, hiding existence or representation details of libraries from the developers. Maybe I couldn't explain my idea completely, try again: My assumption was to first create some sort of meta-interface, let's call it X. (Similiar to COM or CORBA but probably more general - don't know if COM or CORBA currently support some sort of closures, for example.) So you would need to convert (1) from Ruby to X and (2) from X to F77 to access F77 function from Ruby. Given other project convert (1) from Ruby to X and (3) from X to COBOL to access COBOL function from Ruby. It would be even possible to convert (2) from F77 to X and (1) from X to Ruby to implement Ruby-Scripting into F77. No need to know how to create DLL's or Shared Objects in F77 or COBOL. (Have you ever read the Solaris-Docu for creating shared objects - thousands of possibilities for errors and flaws.) The ruby/dl or ruby-ffi approach still needs interface knowledge in every inter-language team. Although it reduces complexity of creating C-extensions in Ruby enormeously. It is also limited to the use of dynamic libraries, maybe additionally depending on OS-platform and possibly memory models. (Plz correct me if I'm mistaken.) Hope I could explain my idea now. Michael B. > > Ellie > > Eleanor McHugh > Games With Brains > http://slides.games-with-brains.net > ---- > raise ArgumentError unless @reality.responds_to? :reason > >