oh no…no…
“Eleanor McHugh” [email protected] schrieb im Newsbeitrag
news:[email protected]…
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.