Paulb: New page: I'm not sure what we should do with the retain/release/autorelease situation in Objective-C. An nice option, but a lot or work, would be generate Objective-C classes for Eiffel classes and...

2009-10-27T18:07:53Z

New page: I'm not sure what we should do with the retain/release/autorelease situation in Objective-C. An nice option, but a lot or work, would be generate Objective-C classes for Eiffel classes and...

New page

I'm not sure what we should do with the retain/release/autorelease situation in Objective-C. An nice option, but a lot or work, would be generate Objective-C classes for Eiffel classes and let the Objective-C GC handle memory management, we do this for .NET We would be limited to targeting 10.5+ but I don't think that is a big drawback because Mac users tend to update more often than say Windows/Linux users do.

However, changing the code generation is a lot of work, but it would benefit more than just allowing Eiffel code to use the Objective-C GC. A simpler solution might be to implement runtime hooks, which notifies a callback when an object is attached to a variable or it becomes detached from one. This would also benefit EiffelCOM which uses a similar memory management model. For this we utilize the Eiffel GC and DISPOSABLE, but it does cause problems because the objects aren't released until a GC cycle, and in some cases you need the COM object to actually be released immediately.

--[[User:Paulb|paulb]] 18:07, 27 October 2009 (UTC)

Talk:EiffelVision Cocoa - Revision history

Paulb: New page: I'm not sure what we should do with the retain/release/autorelease situation in Objective-C. An nice option, but a lot or work, would be generate Objective-C classes for Eiffel classes and...