Owen Taylor wrote:
>
>....
>
> A) The success of such an interface is completely in how widely
> it is adopted. If it is widely adopted, people won't mind
> spending a few days implementing a binding onto their
> language, since they will save vastly more time in writing
> individual bindings.
True...but the more important audience is the group of extension
developers. When you're deciding to make a database interface you must
choose to go the extra mile not just to make a Perl interface but also a
common one.
> While simplicity is certainly one big factor in gaining
> adoption, if the solution is too slow or not sufficiently
> expressive, all the simplicity in the world doesn't do
> any good.
I agree. But I don't think that the strawman is too slow or
insufficiently expressive. :-)
>...
> - If you don't expose exceptions, then you can't use the
> language's native exception-handling facilities, and
> the programmer sees error codes.
There are exceptions in the strawman. Exceptions have a string name
dia_val.exception and a pointer to a structured object (hash, array,
whatever) with more information about it.
> - If you don't expose structures, then all structures
> must be represented as objects, which prevents efficient
> remoting.
I call structures "hashes" in the strawman. There is no universal
word....
> - If you don't have events/callbacks, then you can't
> uses closures / anonymous functions for callbacks
> if a language has them.
Functions are first-class objects in the strawman.
dia_function_interface
>...
>
> C) While dynamic typing is a wonderful thing at times, I don't
> think it is appropriate for an inter-language interface.
>
> - It excludes statically typed languages from participating.
No it does not. There are two levels at which they can participate:
a) through a dynamically typed API with a lot of casting (how does Java
use SOAP without WSDL? How does C++ call a Python COM object without
IDL?)
b) through an additional layer that builds statically typed wrappers
from *optional* type declarations. These type declarations could be in
Yet Another IDL variant or in a WSDL variant. Again, this is the
SOAP/WSDL model rather than the historic COM model where dynamic calls
were an afterthought.
> - Static type information is important for coercing between
> different type systems.
>
> In Perl, there is essentially no difference at all between "1" and 1
> as far as a programmer is concerned (**). But this is not the case in Python.
> So, if I make a call foo("1") in Perl, and foo() is a python function,
> the translation layer need information about whether foo() takes
> an integer or a string.
I'll grant that static type information is useful for this sort of
thing. But I will strongly resist the addition of a mandatory IDL to the
system. That puts it over the complexity barrier where it never gets
implemented. Another way to handle the same problem (and simplify code)
is by using format strings.
extapi_parse_args("%d", args, &myint)
This will figure out how to get an integer out of the passed-in type. If
the type is a string, it will try to atoi it. If it is a float, it will
truncate it. etc. The simplest thing is to let all languages get some
common set of conversions but a more advanced system could apply Perl
rules to Perl types and so forth.
I'll state again that I have no problems with IDL as an add-on. If we
could get this API widely accepted and then slowly increase the
complexity/power knob, that's okay with me if it is okay with the
language communities.
>...
> - Use something similar to the CORBA set of types
They will have more types than I think we should support. Plus, CORBA is
the past. XML Schema types have more currency today.
> - Package the interface for a library/component together with
> the library/component as a "typelib".
Package how? I wouldn't want to require magic dynamic linkers or
anything like that. Especially when you consider the number of platforms
these languages run on. I wouldn't want to presume any more
sophistication than that already built into the module loading
technologies in the languages.
> - Use either:
>
> a) platform native C++ ABI
C++ is too strongly resisted in the scripting world.
> or:
>
> b) an efficient in-memory marshaled form.
> for invoking methods
In my opinion this is a great idea for version 2.
--
Take a recipe. Leave a recipe.
Python Cookbook! http://www.ActiveState.com/pythoncookbook
