[MacRuby-devel] How do I subclass Obj-C classes in MacRuby?

Terry Moore tvmoore at mac.com
Fri May 7 02:49:59 PDT 2010


True. To a point but there is an overlap... Object String Hash etc.  
Also designated initialisers are seldom used in ruby( preference for  
named params). InitWithX:y:z is perhaps ok but init over initilize  
seems odd.



Terry Moore

On 7/05/2010, at 9:25 PM, Matt Aimonetti <mattaimonetti at gmail.com>  
wrote:

> In general it's just better and simple to follow Cocoa's conventions  
> and never overwrite the default initializer but instead create your  
> own initializer.
> Thibault explained some of the reasons why you are running into some  
> issues but the point is that even though MacRuby is a Ruby  
> implementation, you are still dealing with Cocoa Objects and Cocoa  
> objects are designed a certain way and you have to respect that if  
> you want them to work properly.
>
> -= Matt
>
> On Fri, May 7, 2010 at 2:15 AM, Terry <tvmoore at mac.com> wrote:
> I agree on that point of course they are different calls .... but  
> from a ruby point of view WHY isn't init with no args the same as  
> initialize with no args....
>
> So I can live with it but my preference is with ruby initialize...  
> this is macRuby right?
>
> Terry
> On 7/05/2010, at 6:09 PM, Thibault Martin-Lagardette wrote:
>
>> Hi!
>>
>> I totally agree that it is a little confusing. But #new an #new 
>> (owner) are two different methods, especially in Obj-C.
>> Calling A.new(arg) cannot call -init, since -init doesn't take any  
>> argument, so it will call any initializer method that takes one  
>> argument :-).
>> This is why:
>>
>> class A; def initialize; end; end; # Will never be called with  
>> A.new, because -init will be called instead
>> class A; def initialize(str); end; end; # Will be called with A.new 
>> (str), because -init cannot be called
>>
>> It simply depends on how you define your initilizer method :-)
>>
>> -- 
>> Thibault Martin-Lagardette
>>
>>
>>
>> On May 6, 2010, at 21:54, Terry Moore wrote:
>>
>>> This is only true if you follow objc init I think... for example...
>>>
>>>
>>> I came across this problem with NSWindowController and it took me  
>>> a while to figure out.
>>>
>>> class PasswordController < NSWindowController
>>> def initialize
>>>     initWithWindowNibName("Password")  ##FAIL Never called! init  
>>> called instead
>>> end
>>>
>>> class PrefController < NSWindowController
>>> 		
>>>   def initialize(owner)
>>>     @owner = owner
>>>     initWithWindowNibName("Preferences")
>>>   end
>>> end
>>>
>>>
>>> The first example fails and so I finally got that I needed the  
>>> init method to make the window appear but I couldn't figure out  
>>> why the second option worked.
>>>
>>> Must have been a long day but clearly if designate an initialize  
>>> with a param init is bypased...
>>>
>>> so if I take the
>>> class A <String
>>>   def initialize(b)
>>>      super
>>>   end
>>> end
>>>   example and do A.new("hi there") gives
>>>
>>> initialize
>>> => "hi there"
>>>
>>> so what is going on? I think there might need to be some  
>>> clarity.....
>>>
>>> Terry
>>>
>>>
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> MacRuby-devel at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
>
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
>
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20100507/e0294ba8/attachment.html>


More information about the MacRuby-devel mailing list