On 2014-10-29 22:51, Christian Schneider wrote:

> Btw, fixed the example, thanks for giving me the right clues. Of course,
> it was just the manual memory management à la Objective-C that was
> missing! I am really lucky that I spent already days, maybe weeks
> debugging retain / release / autorelease on many projects, so for me
> this will be peanuts! I just had a little flashback. I love ARC and am
> looking forward for D to feature it as well, but for now, manual memory
> management is really not the thing that will put me off.

I had a look at your fix. I see that you added a call to "release" in the destructor. Just for the record, there's no guarantee that the destructor of a GC allocated object gets run, at all.

Or, if this class get instantiated by some Objective-C framework then it will know nothing about the destructor in D. I guess the right solution is to override "dealloc".

Hmm, I'm wondering if it's a good idea to lower a destructor to "dealloc", just like a constructor is lowered to "init".

> I have all the tools ready now! I can't believe how this all rocks ;)

Awesome :)

-- 
/Jacob Carlborg

On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote:
> A DIP is available here [1] and the latest implementation is available here [2].
>
> [1] http://wiki.dlang.org/DIP43

Instead of adding the selector syntaxsyntax you could reuse pragma mangle.

extern (Objective-C)
class NSComboBox : NSTextField
{
    private void* _dataSource;

    pragma(mangle, objcMangle!(NSComboBox, "insertItemWithObjectValue", "atIndex")
    void insertItem(ObjcObject object, NSInteger value);
}

Alternatively a compiler recognized UDA would work too.

    @objcSel!("insertItemWithObjectValue", "atIndex")
    void insertItem(ObjcObject object, NSInteger value);

Changing the lexer and parser would affect all D language tools (editors, formatters, linters, other compilers). So now that we do have UDAs I don't see a justification for changing the syntax and grammar of D.

On Thursday, 30 October 2014 at 07:13:09 UTC, Jacob Carlborg wrote:
> On 2014-10-29 22:51, Christian Schneider wrote:
>
>> Btw, fixed the example, thanks for giving me the right clues. Of course,
>> it was just the manual memory management à la Objective-C that was
>> missing! I am really lucky that I spent already days, maybe weeks
>> debugging retain / release / autorelease on many projects, so for me
>> this will be peanuts! I just had a little flashback. I love ARC and am
>> looking forward for D to feature it as well, but for now, manual memory
>> management is really not the thing that will put me off.
>
> I had a look at your fix. I see that you added a call to "release" in the destructor. Just for the record, there's no guarantee that the destructor of a GC allocated object gets run, at all.

Slightly derailing the conversation, but I see this all the time...

Isn't the situation actually this:

GC allocated objects are not guaranteed to be de-allocated before program termination.
If a GC allocated object is deallocated, its destructor *is* guaranteed to be called.
Except:
Destructors are not called for arrays of objects, whether they are structs or emplaced classes, even when they are de-allocated.

> I had a look at your fix. I see that you added a call to "release" in the destructor. Just for the record, there's no guarantee that the destructor of a GC allocated object gets run, at all.

Omg, how embarrassing ;) of course I need to put it in dealloc so that it will work with NSMutableArray et al.  if I am going Objective-C memory management, then I should do it the intended way indeed!

> Or, if this class get instantiated by some Objective-C framework then it will know nothing about the destructor in D. I guess the right solution is to override "dealloc".

So far, I was not even considering a D library that would be used through Objective-C code, but yeah, that's a good point as well.

> Hmm, I'm wondering if it's a good idea to lower a destructor to "dealloc", just like a constructor is lowered to "init".

We will have to find out, but dealloc definitely is the destructor in Objc.

On 2014-10-30 10:23, John Colvin wrote:

> Slightly derailing the conversation, but I see this all the time...
>
> Isn't the situation actually this:
>
> GC allocated objects are not guaranteed to be de-allocated before
> program termination.
> If a GC allocated object is deallocated, its destructor *is* guaranteed
> to be called.
> Except:
> Destructors are not called for arrays of objects, whether they are
> structs or emplaced classes, even when they are de-allocated.

Yes, that's the longer explanation :)

-- 
/Jacob Carlborg

On 2014-10-30 16:28, Christian Schneider wrote:

> So far, I was not even considering a D library that would be used
> through Objective-C code, but yeah, that's a good point as well.

Isn't that what's usually happens when using something like an app delegate. It will be instantiated by the framework when loading a nib.

-- 
/Jacob Carlborg

On 2014-10-30 10:16, Martin Nowak wrote:

> Instead of adding the selector syntaxsyntax you could reuse pragma mangle.
>
> extern (Objective-C)
> class NSComboBox : NSTextField
> {
>      private void* _dataSource;
>
>      pragma(mangle, objcMangle!(NSComboBox, "insertItemWithObjectValue",
> "atIndex")
>      void insertItem(ObjcObject object, NSInteger value);
> }
>
> Alternatively a compiler recognized UDA would work too.
>
>      @objcSel!("insertItemWithObjectValue", "atIndex")
>      void insertItem(ObjcObject object, NSInteger value);
>
> Changing the lexer and parser would affect all D language tools
> (editors, formatters, linters, other compilers). So now that we do have
> UDAs I don't see a justification for changing the syntax and grammar of D.

Seems like a fair point, I guess I could change that. I prefer using a UDA for this.

-- 
/Jacob Carlborg

On 2014-10-30 07:13:08 +0000, Jacob Carlborg <doob@me.com> said:

> I had a look at your fix. I see that you added a call to "release" in the destructor. Just for the record, there's no guarantee that the destructor of a GC allocated object gets run, at all.

D/Objective-C never allocates Objective-C objects on the GC heap. If an object derives from NSObject it is allocated using the usual Objective-C alloc class method when you use the "new" keyword.


> Or, if this class get instantiated by some Objective-C framework then it will know nothing about the destructor in D. I guess the right solution is to override "dealloc".

Whoever instantiated the object has no bearing on who will deallocate and call its destructor. When you call release() and the counter falls to zero, "dealloc" is called and the memory is then released. Whether that call to release() was made from D or Objective-C code is irrelevant.


> Hmm, I'm wondering if it's a good idea to lower a destructor to "dealloc", just like a constructor is lowered to "init".

I can't remember if this is an oversight or just something that I hadn't got to yet. In my mind this was already done.

Anyway, the answer is *yes*: the destructor should be mapped to the "dealloc" selector. It should also implicitly call the destructor for any struct within the object and call it's superclass's destructor (if present), the usual D semantics for a destructor (that part might already work actually).

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

On 2014-10-30 09:16:34 +0000, "Martin Nowak" <code@dawg.eu> said:

> On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote:
>> A DIP is available here [1] and the latest implementation is available here [2].
>> 
>> [1] http://wiki.dlang.org/DIP43
> 
> Instead of adding the selector syntaxsyntax you could reuse pragma mangle.

Nooo! Mangling is something different from the selector name. Mangling is the linker symbol for the function. The selector is the name used to find the function pointer for a given a dynamic object (with similar purpose to a vtable offset). The function has both a mangled name and a selector name, and they're always two different names.


> Alternatively a compiler recognized UDA would work too.
> 
>      @objcSel!("insertItemWithObjectValue", "atIndex")
>      void insertItem(ObjcObject object, NSInteger value);

Ah, that's better. Except you really should use a single string with colons, otherwise you'll have a problem distinguishing no-parameter selectors from single-parameter selectors.


> Changing the lexer and parser would affect all D language tools (editors, formatters, linters, other compilers). So now that we do have UDAs I don't see a justification for changing the syntax and grammar of D.

Very true. I agree. Now that UDAs exist, it'd be preferable to use them.

That said, there are other parts of D/Objective-C that could pose difficulties to existing languages tools, some syntactic (__selector, or "this.class" to get the metaclass), some semantic (overridable static methods having a "this" pointing to the metaclass). I had to bend the rules in some places to make all that work. But it's true that nothing will be more confusing to those tools than the selector declaration currently following a function name.


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

On 2014-11-01 01:54, Michel Fortin wrote:

> I can't remember if this is an oversight or just something that I hadn't
> got to yet. In my mind this was already done.

I did a grep for "dealloc" and couldn't find anything related.

> Anyway, the answer is *yes*: the destructor should be mapped to the
> "dealloc" selector. It should also implicitly call the destructor for
> any struct within the object and call it's superclass's destructor (if
> present), the usual D semantics for a destructor (that part might
> already work actually).

-- 
/Jacob Carlborg