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 <[email protected]> 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 > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-internals _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
