Repository navigation
Move core ObjC classes into their own library #430
Description
For example NSObject and NSString. This makes sense from a modularisation perspective, and also solves the problem where 2 different code genned ObjC libraries are incompatible.
Reacted by Ivan Dlugos
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
dcharkes commentedon Sep 4, 2023
We'll likely need to convert this repo to a monorepo (similar to JNIgen), that's a better approach than a new repo.
JNIgen also has a helper library
package:jniwith common types.We should try to do that conversion at a point where not a ton of PRs are outstanding.
vaind commentedon Sep 12, 2023
This would also solve the pain point I've had when creating this issue: #432 - although the issues are not the same, anything to get rid of those MiB of generated code would be nice.
vaind commentedon Oct 31, 2023
Now seems to be the right time then :D
dcharkes commentedon Oct 31, 2023
cc @devoncarew any concerns about converting this repo to a monorepo?
The helper package with code that the FFIgen generated could would import should be called:
package:objective_c(most obvious name, but does not indicate it belongs to FFIgen generated code)package:objc(because it's shorter than the first)package:ffigen_objc(so it's clear it belongs to FFIgen)package:ffigen_objective_c(so it's clear it belongs to FFIgen)cc @mit-mit for package name inspiration.
devoncarew commentedon Oct 31, 2023
None, but consider also moving this into dart-lang/native.
And, +1 to the package names qualifed w/ ffi prefixes (
package:ffigen_objc,package:ffigen_objective_c, ...).dcharkes commentedon Oct 31, 2023
My reservation with moving FFIgen (and then probably also package:ffi, JNIgen and package:jni) all to dart-lang/native is that all issues will be in one big issue tracker. cc @HosseinYousefi @mannprerak2 @liamappelbe @brianquinlan as most impacted workflow-wise.
HosseinYousefi commentedon Oct 31, 2023
I like the idea of having all the native stuff in
dart-lang/native.This can be solved using a tag for each package.
devoncarew commentedon Oct 31, 2023
That's a drawback for sure, but I think the cost of doing business; we do get real economies of scale from monorepos.
Here's an example of issues for a mono-repo; we just make sure that each package has an issue template, so all filed issues up up w/ a label to help categorize them: https://github.com/dart-lang/tools/issues.
liamappelbe commentedon Nov 1, 2023
I'm also in favour of a
dart-lang/nativemonorepo. We need to start deduping logic between ffigen and jnigen.dcharkes commentedon Nov 1, 2023
Okay!
The process of merging a (non-mono) repo into dart-lang/native can be found here: dart-lang/tools#100. @liamappelbe could you follow these steps for the FFIgen repo and make a PR in the same style?
2 remaining items
lrhn commentedon Mar 19, 2024
How will the package be imported? Will the user have to import it, or will
ffi_geninject an import?(In the latter case, the user still needs a non-dev dependency on the package.)
Could it be a separate libraries of
package:ffi, aspackage:ffi/objective_c.dart. If nothing else, the user presumably has a dependency onpackage:ffialready. (The title says "its own library", not "its own package", so ....?)dcharkes commentedon Mar 19, 2024
The latter. (It is similar to
package:jni, the generated code will import it.)It could. However, I am slightly worried about breaking changes. Objective C support is still experimental.
package:ffiis used all over the place, and users are already using dependency overrides because they have dependencies using v1.x.x and v2.x.x. I'd like to avoid having to bumppackage:ffi's major version because we updatepackage:ffi/objective_c.dartin a breaking way. @liamappelbe Do you expect us to do breaking changes topackage:ffi_objective_cwhile iterating on it?Edit: Especially a package which is used in conjunction with a code generator, it is quite common to change the pattern of the generated code.
package:jnialso had multiple breaking changes already.lrhn commentedon Mar 19, 2024
Which means that the code using
ffi_genneeds to have a non-dep dependency on the package.In that case, I think it's better to put the files inside
package:ffiand only have one package dependency.The breaking change for experimental code is an issue, but that should end eventually. Could you just mark the library as
@experimental, and break it with abandon?If we expect breaking changes post experiment stage, then linking things that evolve independently is an issue, since it can introduce too many major-version increments. Then separate packages is probably the right thing.
In that case, I'd go with
package:ffi_objective_cif the package cannot be used directly, only throughffi_gen.If it can be used directly as well, then
package:objective_cis fine.(Can
package:jnibe used by itself, or should it be calledpackage:ffi_jni?)dcharkes commentedon Mar 19, 2024
JNI is already "Java native interface", so it is inherently FFI related. If it was
package:javawe should have named itpackage:ffi_java.I believe tools such as https://pub.dev/packages/dart_apitool have poor support for marking some libraries in a package as experimental and ignoring breaking changes. So this would constantly turn our CI red.
Maybe we should go for
package:ffi_objective_cfor now, and when Objective-C interop stabilizes and gets out of experimental we can evaluate whether we'd want to merge it intopackage:ffiaspackage:ffi/objective_c.dart.HosseinYousefi commentedon Mar 19, 2024
Having
genin the name might suggest that it is a code generator.I would personally expect that based on my experience.
It can be used by itself. We have a
package:jni/internal_helpers_for_jnigen.dartas well (I know, long name, but I kept it the way it was!) that exposes certain functionalities that onlypackage:jnigenneeds.The thing about
package:jniis that we might decide to decouple it from some futurepackage:java_coreandpackage:kotlin_something. Wherepackage:jnionly has the very basic classes likeJReferenceandJObjectand all the other classes exist in a different package. But again it's a good default forjnigenandffigento use the classes insidepackage:java_coreandpackage:objc_foundation(?) by default.Am I the only one who doesn't really mind not directly implying the fact that these packages are
ffirelated in the name? (Afterall, how else are we working with Objective-C or Java, or any other language from Dart standalone!)liamappelbe commentedon Mar 19, 2024
Definitely. My experience has been that generated code changes more often and more drastically than normal code.
Based on everyone's feedback, I'm leaning towards
package:ffi_objc.dcharkes commentedon Mar 21, 2024
👍
I'd prefer
package:ffi_objective_c, because I believe it would be better to avoid abbreviations. (Although, we do have ffigen where generator is abbreviated to gen. So maybe this isn't the strongest argument. 😆) Happy with either of the two.HosseinYousefi commentedon Mar 21, 2024
I like
package:objective_c.As @lrhn said:
And I think it can be used directly.
liamappelbe commentedon Mar 22, 2024
Fair enough. @dcharkes any objections to
package:objective_c? I would preferpackage:objc, but I don't think I'm going to win that argument 😛dcharkes commentedon Mar 22, 2024
sgtm!