How do I subclass Obj-C classes in MacRuby?
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
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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
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@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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
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@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@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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (4)
-
Matt Aimonetti
-
Terry
-
Terry Moore
-
Thibault Martin-Lagardette