i. and ii. in general may not work but will work in most common cases and
when the ambiguity can't be resolved by the environment it can be raised as
an error/ warning by the interpretter. Jython, I think, had to solve similar
issues.
for iii. i was thinking along the lines of
http://www.jython.org/docs/properties.html
Also, for Jython pack/unpck (struct) module for binary packing and unpacking
there is no SISC equivalent. Binary/IO (srfi-56) fills the gap but is
currently not supported by SISC.
Just mentioning things, that as a user, stop me from making the switch from
Jython to SISC even though I prefer Scheme, and SISC is much better
supported.
On 14 Jun 2005 11:57:15 -0400, Rajeev Narang <RNARANG2@xxxxxxxxxxxxx> wrote:
>
>
>
> ---------- Forwarded message ----------
> From: "Scott G. Miller" <sgmiller@xxxxxxxxx>
> To: rnarang2@xxxxxxxxxxxxx
> Date: Tue, 14 Jun 2005 11:55:16 -0400
> Subject: Re: [SISC-devel] Java Interface
> On Tue, Jun 14, 2005 at 10:57:09AM -0400, Rajeev Narang wrote:
> > I like SISC a lot but still find myself using Jython sometimes for the
> > lack of following features.
> >
> > i) the type conversion between java types and scheme types should be
> > automatic for the basic types like bool, int, string, .... For other
> > types the conversion should be defined/ declared once like in bigloo
> > module declaration.
> >
> > ii) importing a class should automatically import its methods as
> > generic procedures.
> >
> > iii) java beans should be usable like CLOS objects with constructor
> > initialization of slots, and getter and setter methods invoked on
> > using and setting of slot values.
>
> This comes up often, we should really have a FAQ. :)
>
> i and ii aren't possible for reasons which are outlined in the SISC
> manual. Its quite alright to have a library which allows definition of
> wrapper functions which do these conversions, but in general the
> mappings between Scheme and Java types aren't a 1:1 correspondence so
> blindly converting will cause type mismatches or ambiguities in method
> dispatch.
>
> iii might be a reasonable goal. Can you elaborate more on what you'd
> prefer interaction with a bean look like?
>
> > I think the above requires changes to the core of SISC but it will go
> > a long way in making SISC usable not just a portable R5RS scheme
> > environment but also one of the best for interacting with Java
> > libraries.
>
> Fortunately, none of this is 'core' SISC, so modifications are possible.
>
> Scott
>
>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
|
