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....@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@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macruby-devel
