Closed madsmtm closed 1 month ago
One downside would be that all superclasses would have to manually create initializer methods inherited on superclasses instead of e.g. doing Id::cast::<MySubclass>(MySuperclass::init(MySubclass::alloc().into_super()))
.
Though that should arguably be discouraged anyhow, and since we already generate the initializer methods from superclasses on subclasses in header-translator
, this is more of a problem for downstream users.
I'm not going to go down this route, as I think what the user declares in declare_class!
should match what's in extern_methods!
, and making declared initializers not take this: Allocated<Self>
is going to feel inconsistent and weird.
Things will get better here anyhow after https://github.com/rust-lang/rfcs/pull/3519, which will allow us to write self: Allocated<Self>
, and call with NSView::alloc_on_main(mtm).initWithFrame(frame)
/ NSString::alloc().initWithString(string)
.
Swift decided to combine allocation and initialization, such that you can simply call
NSView.init()
instead of Objective-C's cumbersome[[NSView alloc] init]
. Actually,NSView.alloc()
is entirely impossible!For us, this means:
NSView::initWithFrame(mtm, frame)
(or(frame, mtm)
, depending on what we decide in https://github.com/madsmtm/objc2/issues/265) instead ofNSView::initWithFrame(mtm.alloc(), frame)
.NSString::initWithString(string)
instead ofNSString::initWithString(NSString::alloc(), string)
.Should we do this? What would be the downsides? And how should this tie into our naming scheme in #284, since Rust prefers the name
new
?Relates a bit to https://github.com/madsmtm/objc2/issues/438, since we would like the syntax for declaring initializers to resemble the syntax actually used when calling them.