New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial objective-c extern implementation #4350

Merged
merged 7 commits into from Jun 29, 2015

Conversation

Projects
None yet
4 participants
@waneck
Copy link
Member

waneck commented Jun 19, 2015

This is just a quick sketch of a feature discussed with @hughsando at WWX. Ultimately, this should allow to interoperate with Objective-C code directly from Haxe, by defining special extern classes (in this PR, by adding the @:objc meta).

At the moment, only function calls are implemented. This PR should bootstrap some of the changes that HaxeFoundation/hxcpp might need in order to support correct boxing/unboxing of Objective-C types.

@hughsando, please let me know if you agree with the approach, and if there's anything you think that needs to be changed.
I haven't implemented the plain C calls (also since I know there will be a linking problem there, since the included files aren't extern "C"), but I'm thinking about using this @:plain metadata.

I have the following roadmap in mind:

  • Initial implementation and function calling
  • NSObject boxing
  • test interfaces ("protocols" in objective-c)
  • basic types mapping (e.g. enums, NSNumber, NSArray, etc)
  • add/test C externs as well (test extern C @:include)
  • add framework referencing through metadata (+ check with DCE on)
  • automatically add some defines to select between implementations (e.g. compile objective-c code path only when compiling to mac/ios) - cross-compilation aware
  • Haxe functions -> Objc blocks
  • Reference couting and GC interop
  • try/catch
  • extend objective-c classes
  • implement objective-c protocols
  • minor details: haxe Class<T> and objective-c Class interop, and more testing
  • start to meddle with C++ extern support
  • add @:objcpp to indicate headers that should be included without extern C

I'm thinking about adding them by parts so we can discuss each implementation in a way that is graspable and readable, and not a all-in implementation

@waneck waneck added the platform-cpp label Jun 19, 2015

@waneck waneck force-pushed the waneck:objc branch from cfd9da7 to d33d146 Jun 19, 2015

@waneck waneck force-pushed the waneck:objc branch from a9f678a to 8292f5f Jun 19, 2015

waneck added a commit to waneck/hxcpp that referenced this pull request Jun 19, 2015

[objc] Create Dynamic wrapper around Objective-C types
Related to HaxeFoundation/haxe#4350 : this adds an implicit operator
to convert from Dynamic to NSObject * and the other way around. The
changes are all guarded through the `-D objc` Haxe define
@waneck

This comment has been minimized.

Copy link
Member

waneck commented Jun 19, 2015

I've just included another commit. Starting from this one (commit 8292f5f), all subsequent commits will fail until HaxeFoundation/hxcpp#245 is merged.

The following commit message describes the changes:

    Add initial boxing tests, and guard changes on `-D objc` define

    The tests contained herein will only pass once HaxeFoundation/hxcpp#245
    is accepted. It adds basic tests for the boxing and unboxing operations,
    and it adds some extra code to handle `null`, and a few operators
    correctly.

    Also, this makes sure that `@:objc` code is only run when `-D objc` is
    defined - which should make any changes safe against regressions. I've
    also made sure any added code is labeled `objc` properly.
[objc] Add initial boxing tests, and guard changes on `-D objc` define
The tests contained herein will only pass once HaxeFoundation/hxcpp#245
is accepted. It adds basic tests for the boxing and unboxing operations,
and it adds some extra code to handle `null`, and a few operators
correctly.

Also, this makes sure that `@:objc` code is only run when `-D objc` is
defined - which should make any changes safe against regressions. I've
also made sure any added code is labeled `objc` properly.

@waneck waneck force-pushed the waneck:objc branch from 789c812 to 1ea7f48 Jun 19, 2015

expression
in
let check_objc_box expression to_type =
if is_objc_type expression.etype && not (is_objc_type to_type) then

This comment has been minimized.

@waneck

waneck Jun 21, 2015

Member

This not (is_objc_type to_type) should probably be replaced by is_dynamic_in_cpp. I'll add more tests and make the change if needed

waneck added some commits Jun 23, 2015

[objc] Add casts to field accesses and calls when the resulting type …
…is objc

Since all objective-c types are boxed into Dynamic as the same type,
this cast is needed in order to make sure the type is restored.
This will only kick in if `is_objc_type` is true, which only happens on
`@:objc` types.
[objc] Add support for Objetive-C protocols (interfaces)
- Use the `id <SomeInterface>` syntax for when extern @:objc interfaces
are referenced
- This commit needs the changes made by 3815c00
- No solution was yet made to check if an optional method was
implemented by the interface; On Haxe they will have to be included with
@:noCompletion and @:deprecated to satisfy the typeload
@hughsando

This comment has been minimized.

Copy link
Member

hughsando commented Jun 29, 2015

I'm pinging this request to see what travis thinks now I've fixed hxcpp

@hughsando hughsando closed this Jun 29, 2015

@hughsando hughsando reopened this Jun 29, 2015

hughsando added a commit that referenced this pull request Jun 29, 2015

Merge pull request #4350 from waneck/objc
Initial objective-c extern implementation

@hughsando hughsando merged commit 18b8615 into HaxeFoundation:development Jun 29, 2015

2 checks passed

continuous-integration/appveyor AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@Simn

This comment has been minimized.

Copy link
Member

Simn commented Jun 29, 2015

Were you supposed to merge this already?

@hughsando

This comment has been minimized.

Copy link
Member

hughsando commented Jun 29, 2015

My understanding is that this code will not be reached unless the special
meta is used in the source, so it should not break anything. That being
the case, I would prefer to merge early to avoid conflicts and also I might
have some ideas on certain things.

However, this can be reverted if you think its best without any stress for
me.

On Mon, Jun 29, 2015 at 10:58 PM, Simon Krajewski notifications@github.com
wrote:

Were you supposed to merge this already?


Reply to this email directly or view it on GitHub
#4350 (comment).

@Simn

This comment has been minimized.

Copy link
Member

Simn commented Jun 29, 2015

This was more a question for @waneck I guess. I don't mind either way.

@waneck

This comment has been minimized.

Copy link
Member

waneck commented Jul 2, 2015

Sorry to take some time to answer
First of all, @hughsando, thanks for accepting this PR. I've had to work on a couple of things but I'm back working on objective-c support now.
There are indeed still things left to be done now - and I plan to keep working on them and keep sending PRs as I go :)

As for merging them now, I'm of course ok with that. The problem with long-standing PRs is that the chance of them becoming outdated and need manual merges get higher as the time passes. And all changes are very self-contained within specific flags (which is something I plan to do throughout this feature)

@waneck waneck deleted the waneck:objc branch Jul 2, 2015

@jeremyfa

This comment has been minimized.

Copy link

jeremyfa commented Jul 2, 2015

You guys are doing fantastic work! Can't wait to see how this feature will evolve 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment