"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
>
>