[MacRuby-devel] Problem with a window controller

david kramf dakr.012 at gmail.com
Sun Dec 9 02:51:02 PST 2012

Hi Bob
"What I don't like is the way MacRuby supports…" - I hope that MacRuby will improve on that point. I have not encountered that problem yet.

> "myClass = MyClass.alloc.initWithArgument( argument )"… - I believe this will work fine but this is not Ruby. In Ruby( to the best of my knowledge) you never allocate . You call NEW and Ruby takes care of allocating, initialization, calling your Initialize method and finally  ( I hope!!) destroying and releasing the space. The programmer should never worry about that. I would expect that this behavior to be followed also when an Object is instantiated from NIB , but I can understand how implementation issues  make it hard to implement. 
Thanks, David

On Dec 8, 2012, at 9:52 AM, Robert Carl Rice wrote:

> Hi David,
> IB will use the default Obj C initialization and, yes, the default Obj C initialization is a little different from Ruby initialization so I have to make minor changes when I change a class from MacRuby instantiation to IB instantiation. 
> The default Obj C initialization calls init with no arguments immediately after instantiation. This is the equivalent of: myClass = MyClass.alloc.init or myClass = MyClass.new. You can initialize ruby class variables in you own init method, but the init method generally should include a call to super and must return self.
> You could pass argument(s) to a new Obj C with the first call using something like

> , but it's usually easier to send a second message with arguments.
> Someone else here could better provide details on how MacRuby initialization maps to Obj C initialization.
> IB will later call awakeFromNib for all instantiated objects after it has completed initializing all instantiated objects so all of your IBOutlets will be connected. This behavior can be very convenient.
> You can examine an XIB file with any XML file editor for curiosity, but I haven't found any need to decode it so long as the NIB file expansion does what IB says it will do.
> What I don't like is the way MacRuby supports IB outlets because it becomes much too slow for large applications. It begins processing all MacRuby project files when I open the IB connections view. But it only needs to refresh the MacRuby class object that I currently have selected in IB and its MacRuby superclasses. Since filenames don't have to match class names, it would still have to scan files to find my class definition (or definitions), but that should be very much faster than processing all of the files to find and update IB Outlets.
> Bob Rice
> On Dec 7, 2012, at 12:48 PM, david kramf <dakr.012 at gmail.com> wrote:
>> Hi Bob,
>> "As you become more familiar with IB, you will probably do more initialization of objects in IB and less in MacRuby. Nib file expansion instantiates objects and then makes calls to initialize the objects using the same methods that you are using to initialize objects in MacRuby. Actually, in a large application, it would difficult to hook up all of the outlets without using IB."
>> From my modest acquaintance with MacRuby that is not exactly the case since when the NIB instantiates  an NSWindowController object , it does not call "initialize" ,as defined in Ruby , but calls "awakeFromNib". Only when you instantiate your controller from the code itself , you get your "initialize"method called.  
>> I know I still have a lot of practicing on IB. What I find disturbing ,is that when I do something  with IB I cannot see the code created to accommodate my actions ( maybe because I only work in MacRuby and not Objective-C?).
>> Thanks, David  
>> On Dec 6, 2012, at 7:42 PM, Robert Carl Rice wrote:
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macruby-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20121209/d0fcfe0e/attachment.html>

More information about the MacRuby-devel mailing list