[Openmcl-devel] PDFKit crashes

[Gary Byers]

On Thu, 28 May 2009, R. Matthew Emerson wrote:

>
> On May 28, 2009, at 2:06 AM, Ron Garret wrote:
>
>> It turns out that I've been forgetting to #/init things all over the
>> place but things still mostly work for me.  Am I just getting lucky?
>> Should #/init always be called when #/alloc is called?
>
> Yes, either #/init or some more specific initializer, e.g. #/
> initWithFrame:, etc.
>
> There's also the #/new method, which combines #/alloc and #/init into
> one, but using it is apparently not considered stylish any more.

I personally consider MAKE-INSTANCE to be at least somewhat stylish.

(MAKE-INSTANCE class) == (#/new class) == (#/init (#/alloc class))

(MAKE-INSTANCE class {:with-pseudo-initarg-keyword value}+)

uses the provided set of keywords to construct an #/init... function
name (there's some caching involved ...) and does

(#/thatInitFunction: (#/alloc class) , at values)

It's not as high-level as it might look - a set of keywords that map
to an init function name have to all be present and present in the
canonical order for this to work - but things like:

(make-instance window-class
                :with-content-rect rect
                :style-mask style-mask
                :backing backing-type
                :defer nil)

may (or may not) look more readable than:

(#/initWithContentRect:styleMask:backing:defer: (#/alloc window-class)
                                                 rect
                                                 style-mask
                                                 backing-type
                                                 nil)


though (modulo typos) the two forms should have equivalent effect.

>
>
>>  If not, how do
>> you know when you need to call #/init?  (Feel free to treat those as
>> rhetorical questions.  I'm sure there's a Cocoa memory management
>> primer somewhere that I can go read.)
>
> <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/CocoaObjects.html#//apple_ref/doc/uid/TP40002974-CH4-SW17
> >
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>