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