[dmd-internals] Refactoring of the Objective-C integration

[Daniel Murphy via dmd-internals]

IMO it should just be inlined in the appropriate places in the regular
frontend code, like we do for C++ support.  Either it's a first class
feature, or it should be removed, I don't see much point in going
half-way like we have.

Not that I'd bet on Walter merging that...

Using inheritance for this feels clumsy, mostly because (IIRC) one of
the classes is going to be near-trivial.  Maybe it would be better to
just if/error on hasObjectiveC in each function?  Maybe not.

I am in favor of moving compile-time decisions to runtime, so
implementation specifics aside I support the goal.

On Mon, Feb 27, 2017 at 4:01 AM, Jacob Carlborg via dmd-internals
<dmd-internals at puremagic.com> wrote:
> Hi,
>
> I would like to refactor the code in DMD for the Objective-C integration. I’m mostly interested in replacing the way used to determine if the Objective-C integration should be enabled or not.
>
> This is currently done in the makefile by either adding a file containing the code for the Objective-C integration or a stub implementation for the targets that does not support the Objective-C integration. Since this is determined at build time (of the compiler) this does not work well with cross-compiling, LDC have all targets enabled by default.
>
> I would like to change this to determine if the Objective-C integration should be enabled or not at runtime (of the compiler). I was thinking I could do that by having an interface with two classes implementing the interface. One which is used when the Objective-C integration should be enabled and one when it should be disabled. Example:
>
> __gshared Objc objc;
>
> void initialize()
> {
>     objc = global.params.hasObjectiveC ? new Supported : new Unsupported;
> }
>
> interface Objc
> {
>     void setObjc(ClassDeclaration cd);
> }
>
> final class Unsupported : Objc
> {
>     void setObjc(ClassDeclaration cd)
>     {
>         cd.error("Objective-C classes not supported");
>     }
> }
>
> final class Supported : Objc
> {
>     void setObjc(ClassDeclaration cd)
>     {
>         cd.objc.objc = true;
>     }
> }
>
> Does this sound like an acceptable solution or are there better alternatives? I’m also open to suggestions for better names for the classes.
>
> —
> /Jacob Carlborg
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals