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