On 6/24/2013 3:04 AM, Jacob Carlborg wrote:
> On 2013-06-23 23:02, bearophile wrote:
>
>> Instead of:
>> extern (Objective-C)
>>
>> Is it better to use a naming more D-idiomatic?
>>
>> extern (Objective_C)
>
> As Simen said, we already have extern (C++). But I can absolutely change this if
> people wants to.

Objective-C is just perfect.

On 6/24/2013 6:27 AM, Michel Fortin wrote:
> Finally, there is a couple of features that were added to Objective-C since then
> that should be added to the todo list to keep feature parity. Some of those, if
> implemented right, could benefit the rest of D too. For instance: ARC (automatic
> reference counting) which is becoming a must in Objective-C.

Arc has very serious problems - I don't see how it can be done and be memory safe without adding extensive pointer annotations. The general problem is someone taking the address of a member of the reference counted object. The rc goes to zero, the objects gets deleted, and there's that dangling pointer to it.

On Monday, 24 June 2013 at 17:53:36 UTC, Walter Bright wrote:
> Arc has very serious problems - I don't see how it can be done and be memory safe without adding extensive pointer annotations. The general problem is someone taking the address of a member of the reference counted object. The rc goes to zero, the objects gets deleted, and there's that dangling pointer to it.

Just thinking out loud, but what if we were able to @disable the & operator? Then if you needed its address, we could do it with some other member function that returns a special type that does the refcount. That'd be a fairly minor language change and would seal the gap that the library could then fill back in.

On Mon, 24 Jun 2013 13:53:40 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 6/24/2013 6:27 AM, Michel Fortin wrote:
>> Finally, there is a couple of features that were added to Objective-C since then
>> that should be added to the todo list to keep feature parity. Some of those, if
>> implemented right, could benefit the rest of D too. For instance: ARC (automatic
>> reference counting) which is becoming a must in Objective-C.
>
> Arc has very serious problems - I don't see how it can be done and be memory safe without adding extensive pointer annotations. The general problem is someone taking the address of a member of the reference counted object. The rc goes to zero, the objects gets deleted, and there's that dangling pointer to it.

All data members in Objective-C are private.  So the object can control when it gives out this data, and take appropriate actions.  AFAIK, ARC does not worry about internal pointers.

-Steve

On Monday, 24 June 2013 at 17:51:08 UTC, Walter Bright wrote:
> On 6/24/2013 3:04 AM, Jacob Carlborg wrote:
>> On 2013-06-23 23:02, bearophile wrote:
>>
>>> Instead of:
>>> extern (Objective-C)
>>>
>>> Is it better to use a naming more D-idiomatic?
>>>
>>> extern (Objective_C)
>>
>> As Simen said, we already have extern (C++). But I can absolutely change this if
>> people wants to.
>
> Objective-C is just perfect.

linkageAttribute:
      'extern' '(' Identifier ')'
    | 'extern' '(' Identifier '++' ')'
    | 'extern' '(' Identifier '-' Identifier ')'
    ;

On 6/24/2013 11:03 AM, Steven Schveighoffer wrote:
> All data members in Objective-C are private.  So the object can control when it
> gives out this data, and take appropriate actions.  AFAIK, ARC does not worry
> about internal pointers.

Hmm, that's a good thought. (But recall that modules allow access to private members.)

On Mon, 24 Jun 2013 14:25:40 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 6/24/2013 11:03 AM, Steven Schveighoffer wrote:
>> All data members in Objective-C are private.  So the object can control when it
>> gives out this data, and take appropriate actions.  AFAIK, ARC does not worry
>> about internal pointers.
>
> Hmm, that's a good thought. (But recall that modules allow access to private members.)
>

hehe, no I mean in Objective-C, instance variables are ALWAYS private.  Unless you leak that address out to the world, nobody will be getting it.

Typically, you don't give out addresses to anything but Objective-C object members, which are themselves reference counted.  All member variables that are 'public' are accessed via properties.

If you do give out addresses to member variables, you have to be wary of this problem.

-Steve

On 2013-06-24 17:53:40 +0000, Walter Bright <newshound2@digitalmars.com> said:

> On 6/24/2013 6:27 AM, Michel Fortin wrote:
>> Finally, there is a couple of features that were added to Objective-C since then
>> that should be added to the todo list to keep feature parity. Some of those, if
>> implemented right, could benefit the rest of D too. For instance: ARC (automatic
>> reference counting) which is becoming a must in Objective-C.
> 
> Arc has very serious problems - I don't see how it can be done and be memory safe without adding extensive pointer annotations. The general problem is someone taking the address of a member of the reference counted object. The rc goes to zero, the objects gets deleted, and there's that dangling pointer to it.

That's not a so big problem: just disallow taking pointers to member variables inside of reference-counted memory blocks. At least in SafeD. This is a quite rare thing to do in Objective-C anyway, I'd be surprised if it bothered anyone.

And I don't think it is very common in D either. Either way, if D was to implement ARC for its own memory allocator instead of the current GC (which would be great) there's noting to prevent implementing it so that reference counts could be incremented from the middle address of a memory block, it'd be quite easy in fact, and quite necessary too because of the way arrays work.

Usually, the most annoying part of ARC is retain cycles, especially implicit ones created by blocks (Objective-C's delegate literals).

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

On 2013-06-24 15:27, Michel Fortin wrote:

> Not necessarily. There's a couple of Objective-C classes that get
> special treatment by the compiler (identified by a pragma). One could do
> the same for an UDA so the compiler would know where to get that value.
> I'd surely have implemented it as an UDA if such a thing existed at the
> time.

The thing is that pragmas are tied to the compiler. It knows the difference between pragma(foo) and pragma(bar). But for UDA's they are all treated the same, there's no difference between @(3), @("asd") and @foo from the compiler's point of view (as far as I understand). You could implement it as a new attribute (that is, not an UDA), but to implement it as an UDA would be a totally new thing.

> I'm particularly proud of those string literals. They're way cleaner
> than their Objective-C counterparts.  :-)

I agree.

> Those too are better than their Objective-C counterpart too as they
> carry the argument and return type, making them less error-prone.

Same thing here.

> Blocks are reference-counted and don't share the two-pointer layout of a
> delegate. I'm not sure it'd be wise to call them delegates. But this
> needs some more thinking.

Right, they seem kind of complicated in regards of the struct layout it's implemented as. Seems to vary quite much depending on how the block is used and how outer variables are referenced.

> Finally, there is a couple of features that were added to Objective-C
> since then that should be added to the todo list to keep feature parity.
> Some of those, if implemented right, could benefit the rest of D too.
> For instance: ARC (automatic reference counting) which is becoming a
> must in Objective-C.

Yes. There are a couple of new features that D can take advantage of without adding new language support. I'm thinking of the simplified operator overloading that was added, last year I think. We already have operator overloading and can add that to the bindings, no need for language support.

If we want to add support for the new literals (numbers, arrays and associative arrays) we could do the same thing as we already done for strings.

And last, modules that was added this year, D has had that for years :)

-- 
/Jacob Carlborg

On 6/24/2013 1:18 PM, Michel Fortin wrote:
> That's not a so big problem: just disallow taking pointers to member variables
> inside of reference-counted memory blocks. At least in SafeD. This is a quite
> rare thing to do in Objective-C anyway, I'd be surprised if it bothered anyone.
>
> And I don't think it is very common in D either. Either way, if D was to
> implement ARC for its own memory allocator instead of the current GC (which
> would be great) there's noting to prevent implementing it so that reference
> counts could be incremented from the middle address of a memory block, it'd be
> quite easy in fact, and quite necessary too because of the way arrays work.
>
> Usually, the most annoying part of ARC is retain cycles, especially implicit
> ones created by blocks (Objective-C's delegate literals).

If the ref-counted blocks are allocated in the GC space, a GC run will get rid of them!