[cffi-devel] Messing with foreign types some more

[Luís Oliveira]

Hello,

I just had another go at simplifying the type system. Here's an
overview of what changed:

1 - (DEFCTYPE new-type base-type) becomes just a simple way of
defining an alias. The user cannot define translations for new-type
and there will be no translation overhead unless base-type already has
translations. This removes the need for the :TRANSLATE-P optimization
option.

2 - The new macro (DEFINE-FOREIGN-TYPE new-type supers slots &rest
options) becomes the canonical way of defining complex types with
translations. This is a thin wrapper around DEFCLASS.

2a - The new macro (DEFINE-PARSE-METHOD type-name lambda-list &body
body) will be used to parse the type specifications (e.g. '(:string
:encoding :utf-8)) and should return an instance of a subclass of
FOREIGN-TYPE.

2b - Translator/expander methods should now specialize on type instead
of using EQL specializers. So now the type specifications can easily
take options through the above parse-method, save them in some slot
(defined through DEFINE-FOREIGN-TYPE) and -- here's the big advantage
-- the translators can have a look at those options and take
appropriate action.

2c - For the simple case where the user wants to define a translation
but doesn't need to parse options, DEFINE-FOREIGN-TYPE takes a
(:SIMPLE-PARSER name) option that will automatically generate:

  (define-parse-method name () (make-instance 'some-type))

3 - The translator generic functions no longer have that ad-hoc method
combination. If the user wants to chain the translations of her type's
superclasses then she should invoke CALL-NEXT-METHOD explicitly. I
believe this method combination of ours was crippling inheritance.
Compare the new :string+ptr type definition with the previous one for
an example of what I mean.

A side-effect of these changes is that we no longer need two separate
mechanisms for dealing with real types (instances of FOREIGN-TYPE) and
user types (plain symbols). That translates into ~100 less lines of
code.

Here's the patch:
<http://common-lisp.net/~loliveira/patches/more-foreign-types.diff>
This is heavily backwards incompatible wrt the type system interface
so I'll wait and see if there any objections before I commit it.

Comments and suggestions are welcome, as usual.

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/