This repository has been archived by the owner on Oct 1, 2024. It is now read-only.
Add generation of abstract GInterface base class #131
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hey Antonius! The work you have done here is great. I will raise some concerns, but don't get put off by them please, as I love that we're having these conversations! So here they are:
|
You raised another concern, I didn't think about before: In this PR I'm removing some methods (actually I'm not removing them but changing the signature). However, I just changed the API without marking anything as |
added 2 commits
May 10, 2016 11:58
This fixes inconsistent method generation in GIntrface interfaces, adapters and implementor
interfaces. For example, in Atk.IText the method GetRangeExtents existed with two different
signatures. In Atk.IText and Atk.TextAdapter we had:
(1) Atk.TextRectangle GetRangeExtents(int start_offset, int end_offset, Atk.CoordType coord_type);
whereas the signature in Atk.ITextImplementor was:
(2) void GetRangeExtents (int start_offset, int end_offset, Atk.CoordType coord_type,
out Atk.TextRectangle rect);
This fix ensures that all interface methods have the form as shown in (1). This has been
implemented by applying the same rules for "Accessor"-methods in InterfaceVM as are already in
place in class Method. Essentially these rules state that all methods with one out-parameter are
Accessor-methods.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
UPDATE: This PR depends on PR #133. The first two commits (20450a8 and 414e7b1) belong to PR #133 and should be discussed and eventually merged there.
This PR aims to solve the issue that GInterface usage in gtk-sharp is cumbersome. This issue has been discussed thoroughly in PR #113. The solution presented in this PR is in accordance with comment #113 (comment) in PR #113.
In this PR a new additional class is generated for each GInterface. Up until now there were the 3 types
IFoo,FooAdapterandIFooImplementor. In addition an abstract classFoois generated that subclassesGLib.Objectand implementsIFooandIFooImplementor. Thus, it is now possible to simply create a custom implementation ofIFooby writingTo accomplish this, several other changes were necessary (or convenient):
The ToolsVersion in csproj files was updated from 3.5 to 4.0.To facilitate a consistent interface ofIFooandFooAdapteron one side andIFooImplementor(and subsequentially)Fooon the other side, accessor methods are now handled differently. For details see the commit message of b9f1d58. This change also affected the overrides implementation in GObjectVM (a808599).All changes in the generated code can be viewed here:
https://github.com/antoniusriha/gtk-generated-files-compare/commit/b591d47e88b1286913b9d8b61295aad946ae9812https://github.com/antoniusriha/gtk-generated-files-compare/commit/4d215f947b21bd3181e35e467d1d0f833e2f963a.All changes to the API can be viewed here: https://gist.github.com/antoniusriha/532dda0ca6fa9bb1332d. This information has been generated using the tools
mono-api-info.exeandmono-api-html.exefrom the mono repository. (I've noticed that the member description is not always correct:abstractmembers are displayed asvirtual.)