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

[Sebastian Wilzbach via dmd-internals]

FWIW the stubbing also creates pain on the tooling end as these files 
need to be manually excluded on all depending pipelines.
One example is the new documentation build of DDMD which for the time 
being is kinda empty:

DDoc: https://dlang.org/phobos-prerelease/ddmd_objc_stubs.html
DDox: https://dlang.org/library-prerelease/ddmd/objc.html

(though of course this could be solved by "ddocing" the stubs)

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

+1

On 2017-02-27 15:09, Daniel Murphy via dmd-internals wrote:
> 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
> 
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals