Changes between Version 2 and Version 3 of GSoC2011/LispObject-as-java-interface


Ignore:
Timestamp:
02/18/11 20:32:58 (4 years ago)
Author:
mevenson
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GSoC2011/LispObject-as-java-interface

    v2 v3  
    44Make LispObject a Java interface, as God and Gosling intended.  Over the history of ABCL, it has been often mooted whether LispObject should be defined by the Java interface abstraction, allowing different implementations, or if was better just to throw everything into a root object  ('LispObject') that everything has to inherit from.  For the JVMs available at the turn of the 21st century, having large static, kitchen-sink objects in Java code was commonly received as wisdom.  Whether this is true a decade later can be verified in a summer of the Bear. 
    55 
    6 LispObject should be a union of superinterfaces (like HasPrintableRepresentation, HasNumericTower) for which the current code is abstracted into common implementations.  Patches exist for some of from previous version.  This project would first study that code, decide whether to bring those changes forward to abcl trunk or start from scratch, provide the implementation as a pluggable alternative to  the current one, benchmark the differences, and write up the result in a short paper.   
     6LispObject should be a union of superinterfaces (like HasPrintableRepresentation, HasNumericTower, etc.) for which the current code is abstracted into common implementations.  Patches exist for some of this from [http://code.google.com/p/uabcl/source/browse/trunk/src/org/armedbear/lisp/LispObject.java an earlier version of ABCL].  This project would first study that code, decide whether to bring those changes forward to abcl trunk or start from scratch, provide the implementation as a pluggable alternative to  the current one, benchmark the differences, and write up the result in a short paper.   
    77 
    88Just doing the above makes a nice summer project, but there is much more that could be done regarding portability , such as providing an implementation of LispObject that will work on .NET 9via IKBM) or Dalvik.  Or Java7 with InvokeDynamic. Or ...? 
     
    1313 
    1414{{{ 
    15  easye:  I don't think that a 
    16               unitary LispObject interface is a good idea:  I'd 
    17               rathe see LispObject be union of interfaces 
    18               (HasPrintableForm, HasNumericTower, etc.)  And 
    19               provide a polished set of AbstractLispObjects 
    20               (AbstractJavaLispObject, etc.) to work with. 
     15easye:  I don't think that a 
     16         unitary LispObject interface is a good idea:  I'd 
     17         rather see LispObject be union of interfaces 
     18         (HasPrintableForm, HasNumericTower, etc.)  And 
     19         provide a polished set of AbstractLispObjects 
     20         (AbstractJavaLispObject, etc.) to work with. 
    2121}}}