[Openmcl-devel] RLET etc.

[Gary Byers]

One other approach (short of making a full-blown standard CLOS object
for every NSRect/NSPoint/NSRange etc is to map them to lisp
structures (e.g., DEFSTRUCTs) and hide the ugly foreign structure
stuff a bit further.  Randall Beer and I were playing around with
this a few years ago, and I think that his code for doing some of
the coercions is still there (and hopefully still mostly working)
in one of the Cocoa example sources.

I don't know that you'd necessarily always want the convenience
of having something that (for instance) returned an NSRange cons
up a full-blown Lisp object to represent a pair of integers.  I
know that Randall and I thought about this some and discussed
the possibility of having things that returned foreign structures
do so by returning their fields as multiple values, at least in
some cases.  (Note that when a structure contains embedded structs
and unions, it's not always clear what "the" fields of that structure
are; for something like an NSRange, that's pretty clear and dealing
with a small number of return values is usually easy.)


On Sun, 9 Jul 2006, Phil wrote:

> I've been finding the inability to persist and manipulate NSRect etc.
> outside of an RLET etc. frustrating so I decided to do something
> about it.  Having now gone through the exercise with NSRect, I
> started thinking about what could be an even better approach and
> wanted to get some feedback: why not just create lisp classes for
> NSRect's etc. which would store the needed structure, define methods
> which would allow for more straight-forward manipulation of the
> structure's contents, and add some cases (i.e. ns-rect) to sletify
> which would allow things to work without any further changes.  It
> almost seems too easy... am I the only one with issues re: the
> current approach or otherwise missing something?
>
> Thanks,
> Phil
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>