[Openmcl-devel] wrapping foreign objects in lisp classes

[Cyrus Harmon]

Well, to at least partially answer my own question, digging a bit 
deeper on google points back to the openmcl-list where the relevant bit 
about validate-superclass is cited.

Which leads to another question: why is the validate-superclass in the 
objc-clos stuff as follows:

(defmethod validate-superclass ((c1 objc:objc-class) (c2 
objc:objc-class))
   t)

instead of:

(defmethod validate-superclass ((c1 objc:objc-class) (c2 
objc:objc-class-object))
   t)

which is its superclass, right?

Thanks again,

Cyrus

On Aug 17, 2004, at 12:52 AM, Cyrus Harmon wrote:

> Anyone have a simple example of a working instance of 
> slot-value-using-class? AMOP is on the way, but in the meantime, an 
> example would help. The Cocoa stuff is a bit hairy and my simple 
> example doesn't work. Not sure where I'm going wrong...
>
> As for Gary's other approach, this definitely works and is simpler. 
> I'm bound and determined to figure out why the slot-value-using-class 
> isn't working for me though...
>
> Thanks,
>
> Cyrus
>
> On Aug 16, 2004, at 4:29 PM, Gary Byers wrote:
>
>>
>>
>> On Mon, 16 Aug 2004, Dan Knapp wrote:
>>>
>>>    Using the metaobject protocol doesn't avoid having to write the
>>> custom readers and
>>> writers; you still need to do that.  However, you should be able to 
>>> do
>>> it in such a way
>>> that you only need to do it once instead of for every slot of every
>>> class.
>>>
>>
>> The methods that a custom metaclass would have to override are
>> SLOT-VALUE-USING-CLASS and (SETF SLOT-VALUE-USING-CLASS).  Reader and
>> writer methods do the equivalent of calls to these methods in general
>> (in a case where a user-defined [SETF ]SLOT-VALUE-USING-CLASS method
>> could be applicable, the user-defined method will be invoked.)
>>
>> The Cocoa bridge implements SLOT-VALUE-USING-CLASS (and SETF thereof)
>> by storing getter/setter functions (defined in terms of low-level
>> memory accessors) in specialized SLOT-DEFINITION objects.
>>
>> In the bridge's case, it seemed natural to treat ObjC instance 
>> variables
>> as CLOS slots.  It may be simpler (in some ways) to simply define 
>> methods
>> on the fields of an encapsulated foreign structure, without trying to
>> make those methods be accessor methods.  As a poor example:
>>
>> ;; This definition might be encoded in a .cdb file
>> (def-foreign-type nil (:struct :point  ; this is a hypothetical 
>> example
>>                          (:x :float)
>>                          (:y :float)))
>>
>> (defclass point ()
>>   ((real-point :initarg :real-point
>>                :accessor real-point
>>                :documentation "a pointer to a real point")))
>>
>> (defmethod point-x ((p point))
>>   (let* ((real-point (real-point p)))
>>     (pref real-point :point.x)))
>>
>>
>> (defmethod (setf point-x) (new (p point))
>>   (let* ((real-point (real-point p)))
>>     (setf (pref real-point :point.x) new)))
>>
>>
>> You might want these methods to do a little more type- and 
>> sanity-checking
>> than is shown here, but it seems like most/all of that is boilerplate:
>> given a foreign structure definition, it's probably not too hard to
>> generate an encapsulating class and methods to access that structure's
>> fields.
>>
>> (You wouldn't have the ability to use SLOT-VALUE or WITH-SLOTS on the
>> foreign field, but you'd be able to deal with a foreign structure and
>> its fields at a fairly high level.)
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel