D/Objective-C, extern (Objective-C)
Steven Schveighoffer
schveiguy at yahoo.com
Mon Jun 24 15:39:13 PDT 2013
On Mon, 24 Jun 2013 18:10:19 -0400, bearophile <bearophileHUGS at lycos.com>
wrote:
> Jacob Carlborg:
>
>> I don't think it adds much complexity. If you don't use extern
>> (Objective-C) you don't need to learn it.
>
> D books must be bigger, D programmers must read those parts of the
> books, the error messages become more complex (because you can hit by
> mistake the unwanted syntax, or because the compiler recovering of
> errors must consider more possibilities), the compiler gets a little
> larger. Thinking that some new syntax has no costs is very wrong.
I think this is largely false. In order for the new syntax to be valid,
you must use extern(Objective-C). That would be quite an accident.
Consider that I have never dealt with the COM compatibility (or frankly,
even the extern(C++) compatibility) part of D whatsoever. Because I've
never implemented IUnknown, or used extern(C++).
These features that are enabled by specific syntax are not extra
complexity for D.
Note that TDPL makes no mention of IUnknown or COM compatibility, yet I
have never seen a post on D.learn asking questions about this feature set
unless they were actually looking to write COM code. In other words, no
accidental enabling (I have seen questions as to why interfaces are not
Objects, and I grudgingly have to point to the incorrect belief that COM
objects cannot be discerned from normal D objects at compile time).
On the other hand, something like shared and const are pervasive, because
they are core language features, AND because they are used throughout
libraries.
I think it is important to consider the applicability to normal code when
introducing such binding features. The way this is to be introduced is
the correct level of access -- only enabled with a specific directive.
-Steve
More information about the Digitalmars-d-announce
mailing list