Bug 3234 - Bindings projects generate non-subclassable types
Summary: Bindings projects generate non-subclassable types
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: iOS add-in ()
Version: Trunk
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Jeffrey Stedfast
URL:
Depends on:
Blocks:
 
Reported: 2012-02-06 07:23 UTC by Rolf Bjarne Kvinge [MSFT]
Modified: 2012-03-21 04:49 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Rolf Bjarne Kvinge [MSFT] 2012-02-06 07:23:43 UTC
Bindings projects generate non-subclassable types.

This is because the /e switch is passed to btouch, to generate subclassable types that switch must not be passed to btouch, but for bindings projects we pass it unconditionally.

See also: http://stackoverflow.com/questions/9143320/monotouch-derived-class-from-a-native-class
Comment 1 Jeffrey Stedfast 2012-02-06 12:36:07 UTC
Ah, yea, I just went with the pattern we had been using for monotouch-bindings module.

Fixed in git master of monotouch.
Comment 2 Marcus Wilhelm 2012-03-19 18:02:03 UTC
I run into the same problem but first saw the stackoverflow question and and the answer by Ralf AFTER I have posted my question. 

Since it it seems fixed in git master of monotouch should it be fixed in the latest stable version of monotouch? Bye the way, if I look into my build output I can't find the mentioned /e switch if I rebuild my binding project.

Please see my stackoverflow question: http://stackoverflow.com/questions/9778491/monotouch-binding-objc-library-problems-cant-derive-from-bound-objc-class

Thanks!
Comment 3 Marcus Wilhelm 2012-03-19 18:11:47 UTC
Sorry I have /e in the output. Is there a way to remove it from within MonoDevelop? Or must I use the console way to generate the bindings myself?
Comment 4 Miguel de Icaza [MSFT] 2012-03-20 14:16:20 UTC
Jeff, can you comment on the status of this for MonoDevelop?

Reopening the bug for now.

We should have an option for this.
Comment 5 Jeffrey Stedfast 2012-03-20 14:22:09 UTC
looks like I never backported my fix to the 5.2.x series.

I've just committed the backported patch to the 5.2 branch, so future releases will have this fix.
Comment 6 Miguel de Icaza [MSFT] 2012-03-20 14:27:12 UTC
Part of the problem right now is that "-e" means a couple of things to the
generator, and this is not exactly right.

Setting external to true causes the following to take place:

* Subclassing is not allowed:
   1. Constructors generate a direct call to the init method instead of
msgSend/msgSendSuper
   2. Methods have a direct call to the method instead of the
msgSend/msgSendSuper paths

* trivial optimization is disabled.
   * Calls Selector.GetHandle, instead of sel_registerName, but it is a
wrapper, we should just
     rename the method (sel_registerName to GetHandle) and that way everything
is optimized.

So we could eliminate the optimization pass and make "e" actually mean "do not
create code that can be subclassed".
Comment 7 Marcus Wilhelm 2012-03-20 15:10:10 UTC
Sounds good ;) Looking forward to the next release. Thanks!
Comment 8 Marcus Wilhelm 2012-03-21 04:49:29 UTC
BTW would it make sence to control subclassable with an attribute? Like

[Subclassable]
[BaseType(typeof(NSOBject)]
interface CCCamera {
    ...
}

Since not all bound classes must be subclassable this would allow much more control how btouch generates the bindings.