[Openmcl-devel] RLET etc.

[Phil]

Gary/Randall,

Thanks for the info and I'll look at what already exists as a  
starting point as I have no desire to reinvent the wheel.  Point  
taken re: a class being overkill for this as a struct would do the  
job from a data standpoint.... I always seem to skip over structures  
(likely bad C memories ;-) and go straight for class-based solutions  
but I'll look at a structure-based solution as well.

As an aside, I don't anticipate using this approach as a replacement  
for the current rlet functionality as much of the time, that does the  
job nicely.  Rather, I envision it as a complement when I need to  
create Cocoa objects programatically where sizes are calculated  
values and I've needed to do the (let (slet (let))) dance, be able to  
pass these structures to methods/functions, and/or need to persist  
them beyond the rlet.  In the more static cases, this approach is  
overkill.

Phil

On Jul 10, 2006, at 2:47 PM, Gary Byers wrote:

> 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
>>
>>