Could anybody explain the practical side of this project? Where it can be helpful?

On 2013-06-24 19:36, Walter Bright wrote:

> Yes, but since I don't know much about O-C programming, the feature
> should be labeled "experimental" until we're sure it's the right design.

Absolutely. But there's not that much to design. It's the same with extern (C) nothing to design there, just get the ABI correct. Compared to extern (C) there are a few additional things that need to be designed.

I suggest you try and read the design document by Michel, then comment and ask as much questions as possible.

-- 
/Jacob Carlborg

On Mon, 24 Jun 2013 16:36:50 -0400, Suliman <evermind@live.ru> wrote:

> Could anybody explain the practical side of this project? Where it can be helpful?

First, you should quote the bit of the post that you are responding to.  Since you responded to my post, I will answer.

Objective C is the main development language used on apple systems (iOS, MacOS X, etc).  Currently, D supports MacOS X.  So accessing Apple's OS framework (including GUI and other OS frameworks)from D requires either building a bridge between the two sides (basically, writing a C "glue layer" since both natively support C), or binding directly to Objective C.

Given that Objective C is a superset of C, and D supports C natively, just like Objective C, the benefit is huge.  Instead of calling some glue code, I can call Objective C objects directly.  Unlike most languages, there would not need to be ANY significant glue code here, just a mapping of what to call when you are on an Objective C object.  There should be almost no performance hit.

-Steve

On 6/24/2013 1:37 PM, Jacob Carlborg wrote:
> On 2013-06-24 19:36, Walter Bright wrote:
>
>> Yes, but since I don't know much about O-C programming, the feature
>> should be labeled "experimental" until we're sure it's the right design.
>
> Absolutely. But there's not that much to design. It's the same with extern (C)
> nothing to design there, just get the ABI correct. Compared to extern (C) there
> are a few additional things that need to be designed.

The difference is I know C intimately.


> I suggest you try and read the design document by Michel, then comment and ask
> as much questions as possible.

I did read it.

On 2013-06-24 22:49, Walter Bright wrote:

> The difference is I know C intimately.

Fair enough. Please ask any questions and we will try and answer.

> I did read it.

Great.

-- 
/Jacob Carlborg

Walter Bright:

> Yes, but since I don't know much about O-C programming, the feature should be labeled "experimental" until we're sure it's the right design.

This change opens a new target of D development (well, it was already open for the people willing to use a not standard dmd compiler), but it also introduce some extra complexity in the language, that every D programmer will have to pay forever, even all the ones that will not use those features. So such changes need to be introduced with care and after extensive discussions in the main newsgroup. Probably each one new thing introduced needs a separate discussion.

Bye,
bearophile

On 6/24/2013 1:45 PM, Steven Schveighoffer wrote:
> On Mon, 24 Jun 2013 16:36:50 -0400, Suliman <evermind@live.ru> wrote:
>
>> Could anybody explain the practical side of this project? Where it can be
>> helpful?
>
> First, you should quote the bit of the post that you are responding to.  Since
> you responded to my post, I will answer.
>
> Objective C is the main development language used on apple systems (iOS, MacOS
> X, etc).  Currently, D supports MacOS X.  So accessing Apple's OS framework
> (including GUI and other OS frameworks)from D requires either building a bridge
> between the two sides (basically, writing a C "glue layer" since both natively
> support C), or binding directly to Objective C.
>
> Given that Objective C is a superset of C, and D supports C natively, just like
> Objective C, the benefit is huge.  Instead of calling some glue code, I can call
> Objective C objects directly.  Unlike most languages, there would not need to be
> ANY significant glue code here, just a mapping of what to call when you are on
> an Objective C object.  There should be almost no performance hit.

Yup. A big win for Mac developers.

On 2013-06-24 23:26, bearophile wrote:

> This change opens a new target of D development (well, it was already
> open for the people willing to use a not standard dmd compiler), but it
> also introduce some extra complexity in the language, that every D
> programmer will have to pay forever, even all the ones that will not use
> those features. So such changes need to be introduced with care and
> after extensive discussions in the main newsgroup. Probably each one new
> thing introduced needs a separate discussion.

I don't think it adds much complexity. If you don't use extern (Objective-C) you don't need to learn it.

-- 
/Jacob Carlborg

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.

Bye,
bearophile

On Mon, 24 Jun 2013 18:10:19 -0400, bearophile <bearophileHUGS@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