[Openmcl-devel] initforms in objc classes ?

Gary Byers gb at clozure.com
Thu Jan 31 03:13:31 PST 2008

For a STANDARD-OBJECT, all of the slots of a newly-allocated instance
have a special distinguished value that means that the slot is unbound.
When an instance is (re)initialized, a slot's :initform option can be
used to set the slot's value if (a) no initarg associated with the
slot is present and (b) the slot is currently unbound.

If we allocate an instance and don't (somehow) initialize at least
one of its slots, that slot is still not SLOT-BOUNDP and it's
an error to reference it (analogous to trying to refernce the value
of a special variable that't not BOUNDP.)

For a foreign slot in a foreign object, there isn't (necessarily) 
a good way to determine whether the slot is bound.  Its value might
be 0 (or "a zero of some type"), but it's not generally true that
0 is the same as "no value, an error to access",

I suppose that initializing a foreign slot via an initform could:

a) never happen, because foreign slots are always SLOT-BOUNDP.
b) always happen, for pretty much the same reason
c) happen (in the INITIALIZE-INSTANCE case, at last) only if
the current value if the slot is binary 0, unless the slot is
inherited from something known to be implemented in ObjC, in which
case the 0 value may not mean anything like "unbound/uninitialized."

(c) makes sense up to a point, but only up to a point.  (a) and (b)
are both somewhat arbitrary choices, but (a) seems a little closer
to the STANDARD-CLASS case (with the exception being that foreign
slots are always SLOT-BOUNDP.)

(a) is what's actually implemented, which means that the :initform
and :foreign-type slot options are conflicting.  It'd probably be
better to detect this and warn or error at class-definition time
rather than to leave people wondering why :initforms on foreign slots
are silently ignored.

(If we -do- have examples that use initforms on foreign slots, we
should fix the examples or change how this case is handled.)

On Thu, 31 Jan 2008, Didier Verna wrote:

>       Hello again,
> I can't figure out why my initforms don't seem to work in objc classes
> (I saw some examples in the ocoa-ide directory so I assume it should
> work). Suppose for instance that I have this class:
> (defclass base-node (ns:ns-object)
>  ((title :foreign-type :id
>    :accessor title
>      :initform #@"Untitled base node")
>   (icon :foreign-type :id
>    :accessor icon)
>   (url-string :foreign-type :id
>          :accessor url-string)
>   (children :foreign-type :id
>        :reader children ;; custom writer (see below)
>             :initform (#/array ns:ns-array))
>   (leafp :reader leafp ;; custom writer (see below)
>     :initarg :leafp
>       :initform nil))
>  (:metaclass ns:+ns-object))
> If I inspect an object created with (make-instance 'base-node) in Slime,
> I get this:
> #<BASE-NODE  #x30004211F95D>
> --------------------
> Nil = #0=#<BASE-NODE <BaseNode: 0x14abe800> (#x14ABE800)>
> Class:  = #<OBJC:OBJC-CLASS BASE-NODE (#x14AAF1D0)>
> Wrapper:  = #<CLASS-WRAPPER  #x3000420F6F2D>
> Instance Slots = NIL
> Leafp = NIL
> Title = #<A Null Foreign Pointer>
> Icon = #<A Null Foreign Pointer>
> Url-String = #<A Null Foreign Pointer>
> Children = #<A Null Foreign Pointer>
> Underlying UVECTOR
> in which you can see that the title and children slots are NULL. For the
> title slot, I also tried (#/initWithString #@"bla") or just
> (#/init ns:ns-string) in vain.
> Please forgive me if this is too trivial; I'm quite new both to Cocoa
> and the bridge... (and http://openmcl.clozure.com/Doc/index.html seems
> to be down right now ;-)
> Thank you !
> -- 
> Resistance is futile. You will be jazzimilated.
> Didier Verna, didier at lrde.epita.fr, http://www.lrde.epita.fr/~didier
> EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (0)1 44 08 01 85
> 94276 Le Kremlin-Bicêtre, France   Fax.+33 (0)1 53 14 59 22  didier at xemacs.org
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list