www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is there any plans to make working signals in D?

reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
For "working signals" I suppose will be enough fixing of both Issue 9606 
[1] and Issue 9603 [2].

IMO, for the first issue we need weak references [3].
IMO, for the second issue we need to make regular D objects on closures 
[4] and fix Issue 9602 [5].

Any thoughts about my proposal to make signals working in D? Other 
proposals? Any (approximate) period for [proposal parts] to be implemented?

Also, does anybody think currently D has working signals and I'm just 
slander in the title?

P.S.
Also there is a proposal for new signals implementation without compiler 
changes [6].


[1] http://d.puremagic.com/issues/show_bug.cgi?id=9606
[2] http://d.puremagic.com/issues/show_bug.cgi?id=9603
[3] http://d.puremagic.com/issues/show_bug.cgi?id=4151
[4] http://d.puremagic.com/issues/show_bug.cgi?id=9601
[5] http://d.puremagic.com/issues/show_bug.cgi?id=9602
[6] http://d.puremagic.com/issues/show_bug.cgi?id=9347

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 14 2013
next sibling parent reply Robert <jfanatiker gmx.at> writes:
There is: http://wiki.dlang.org/Review_Queue

It is currently blocked by:
http://d.puremagic.com/issues/show_bug.cgi?id=8441

There is already a pull request for 8441, but it was not merged yet.

As soon as 8441 gets fixed, I am going to finish up the implementation
to make it ready for review.

For an overview of fixes and improvements over the current
implementation, simply search the forums for std.signals2.

Best regards,
Robert

On Sun, 2013-04-14 at 11:06 +0400, Denis Shelomovskij wrote:

 For "working signals" I suppose will be enough fixing of both Issue 9606 
 [1] and Issue 9603 [2].
 
 IMO, for the first issue we need weak references [3].
 IMO, for the second issue we need to make regular D objects on closures 
 [4] and fix Issue 9602 [5].
 
 Any thoughts about my proposal to make signals working in D? Other 
 proposals? Any (approximate) period for [proposal parts] to be implemented?
 
 Also, does anybody think currently D has working signals and I'm just 
 slander in the title?
 
 P.S.
 Also there is a proposal for new signals implementation without compiler 
 changes [6].
 
 
 [1] http://d.puremagic.com/issues/show_bug.cgi?id=9606
 [2] http://d.puremagic.com/issues/show_bug.cgi?id=9603
 [3] http://d.puremagic.com/issues/show_bug.cgi?id=4151
 [4] http://d.puremagic.com/issues/show_bug.cgi?id=9601
 [5] http://d.puremagic.com/issues/show_bug.cgi?id=9602
 [6] http://d.puremagic.com/issues/show_bug.cgi?id=9347
Apr 14 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
14.04.2013 15:22, Robert пишет:

 There is: http://wiki.dlang.org/Review_Queue

 It is currently blocked by:
 http://d.puremagic.com/issues/show_bug.cgi?id=8441

 There is already a pull request for 8441, but it was not merged yet.

 As soon as 8441 gets fixed, I am going to finish up the implementation
 to make it ready for review.

 For an overview of fixes and improvements over the current
 implementation, simply search the forums for std.signals2.


Does it mean you disagree with proposed compiler changes and with the 
idea we have to create weak reference functionality instead of 
recreating it every time it is needed (beside of theoretical danger such 
approach already showed it as a bad thing with `std.stdio.File` as I wrote)?

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 14 2013
parent reply Robert <jfanatiker gmx.at> writes:
 Does it mean you disagree with proposed compiler changes and with the 
 idea we have to create weak reference functionality instead of 
 recreating it every time it is needed (beside of theoretical danger such 
 approach already showed it as a bad thing with `std.stdio.File` as I wrote)?
 



A weak reference could actually be implemented in the library relatively
easy. ( I basically did it for std.signals2 ) But for std.signals a weak
ref is not really enough, because ideally the slot gets removed if the
target gets destroyed, not only set to null. Updating a collection on
destruction of an object is not that easy as you pointed out (thank you
for that), but I don't see how weak references would help there.

But you just made me think: If it is ok that a signal does not release
the memory for the slot immediately when the object gets destroyed but
only on the next call to emit(), then the implementation would be much
simpler ...

Best regards,
Robert
Apr 14 2013
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 14 Apr 2013 19:07:58 +0200
schrieb Robert <jfanatiker gmx.at>:


 Does it mean you disagree with proposed compiler changes and with
 the idea we have to create weak reference functionality instead of 
 recreating it every time it is needed (beside of theoretical danger
 such approach already showed it as a bad thing with
 `std.stdio.File` as I wrote)?
 


 
 
 A weak reference could actually be implemented in the library
 relatively easy. ( I basically did it for std.signals2 ) But for
 std.signals a weak ref is not really enough, because ideally the slot
 gets removed if the target gets destroyed, not only set to null.
 Updating a collection on destruction of an object is not that easy as
 you pointed out (thank you for that), but I don't see how weak
 references would help there.
 
 But you just made me think: If it is ok that a signal does not release
 the memory for the slot immediately when the object gets destroyed but
 only on the next call to emit(), then the implementation would be much
 simpler ...
 
 Best regards,
 Robert
 


IMHO if a object still is connected to a active signal it should not be
collected. So the place where the signal stores the handler should be
scanned by the GC as usual. Then just document clearly that you have to
remove a handler to make sure that garbage collection can really kick
in.
Apr 14 2013
next sibling parent reply Robert <jfanatiker gmx.at> writes:
 IMHO if a object still is connected to a active signal it should not be
 collected. So the place where the signal stores the handler should be
 scanned by the GC as usual. Then just document clearly that you have to
 remove a handler to make sure that garbage collection can really kick
 in.


If you really want this behaviour, all you need is an array of
delegates. But in my experience you don't usually want that, because
you would have to take care of dropping any connections by hand, which
is even more cumbersome than manual memory management in some regards.

Best regards,
Robert
Apr 14 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 14 Apr 2013 21:29:07 +0200
schrieb Robert <jfanatiker gmx.at>:


 

 IMHO if a object still is connected to a active signal it should
 not be collected. So the place where the signal stores the handler
 should be scanned by the GC as usual. Then just document clearly
 that you have to remove a handler to make sure that garbage
 collection can really kick in.


 
 If you really want this behaviour, all you need is an array of
 delegates. But in my experience you don't usually want that, because
 you would have to take care of dropping any connections by hand, which
 is even more cumbersome than manual memory management in some regards.
 
 Best regards,
 Robert
 


But what if my only reference to the handler is in the signal and I
don't want it to get disconnected / cleaned up?

struct FileLogger
{
    File f;
    void onSomething()
    {
        f.writeln("Something happened");
    }
}

a.onSomething ~= &(new FileLogger()).onSomething;
(The FileLogger should only get destroyed if a is destroyed)


dangerous as it could cause memory leaks if used wrong. But I think we
should at least have the option of doing things like these. (Allowong
both strong & weak references as suggested by Kapps seems to be a good
solution)
Apr 16 2013
parent "Robert" <jfanatiker gmx.at> writes:
 (Allowong
 both strong & weak references as suggested by Kapps seems to be 
 a good
 solution)


std.signals2 supports both, just use strongConnect().

Best regards,
Robert
Apr 16 2013
prev sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Sunday, 14 April 2013 at 17:35:00 UTC, Johannes Pfau wrote:

 IMHO if a object still is connected to a active signal it 
 should not be
 collected. So the place where the signal stores the handler 
 should be
 scanned by the GC as usual. Then just document clearly that you 
 have to
 remove a handler to make sure that garbage collection can 
 really kick
 in.


The caller should have the option to connect a strong reference 

handlers is the most common source of memory leaks. Let's not 
bring that to D.
Apr 14 2013
prev sibling next sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
14.04.2013 21:07, Robert пишет:

 Does it mean you disagree with proposed compiler changes and with the
 idea we have to create weak reference functionality instead of
 recreating it every time it is needed (beside of theoretical danger such
 approach already showed it as a bad thing with `std.stdio.File` as I wrote)?



 A weak reference could actually be implemented in the library relatively
 easy. ( I basically did it for std.signals2 ) But for std.signals a weak
 ref is not really enough, because ideally the slot gets removed if the
 target gets destroyed, not only set to null. Updating a collection on
 destruction of an object is not that easy as you pointed out (thank you
 for that), but I don't see how weak references would help there.


Array of weak references is what is needed.


 But you just made me think: If it is ok that a signal does not release
 the memory for the slot immediately when the object gets destroyed but
 only on the next call to emit(), then the implementation would be much
 simpler ...


Yes, this is how array of weak references will work because this is how 
weak references work. And this shows one mustn't implement general 
facilities in every case they are needed as he will do mistakes and will 
complicate thinks for himself.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 14 2013
parent Robert <jfanatiker gmx.at> writes:
 Yes, this is how array of weak references will work because this is how 
 weak references work. And this shows one mustn't implement general 
 facilities in every case they are needed as he will do mistakes and will 
 complicate thinks for himself.
 


If an array of weak references works this way, then it is also easily
implementable in the library. For thread safe weak references another
hook would be necessary though, as Soenke has pointed out.

My current approach is to use a /simplified/*) lock-free list.
Simplified because I make use of the way the GC works, so it is not
thread safe in general. The lazy approach would make this unnecessary.

Maybe I go for lazy, the more sophisticated solution can be implemented
later on if really deemed necessary. 


*) It is still brain-fuck though.
Apr 15 2013
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 14.04.2013 19:07, schrieb Robert:

 Does it mean you disagree with proposed compiler changes and with the 
 idea we have to create weak reference functionality instead of 
 recreating it every time it is needed (beside of theoretical danger such 
 approach already showed it as a bad thing with `std.stdio.File` as I wrote)?


 
 
 A weak reference could actually be implemented in the library relatively
 easy. ( I basically did it for std.signals2 )


My memories tell me that I was never able to make a _thread safe_ weak
reference, though. I don't remember exactly, but I think that it was
because the dispose event happens after all threads have already
restarted. This means that some thread could extract a strong reference
from the weak reference before the weak reference knows that the
underlying object has been destroyed, thus creating a dangling pointer.
Apr 15 2013
parent Robert <jfanatiker gmx.at> writes:
 My memories tell me that I was never able to make a _thread safe_ weak
 reference, though. I don't remember exactly, but I think that it was
 because the dispose event happens after all threads have already
 restarted. This means that some thread could extract a strong reference
 from the weak reference before the weak reference knows that the
 underlying object has been destroyed, thus creating a dangling pointer.
 


You are right, it is not thread safe. Some hook would be needed that
gets called before threads are resumed. It is not an issue for
std.signals2 because it is not meant to be thread safe.

Best regards,
Robert
Apr 15 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 14 April 2013 at 07:06:12 UTC, Denis Shelomovskij 
wrote:

 For "working signals" I suppose will be enough fixing of both 
 Issue 9606 [1] and Issue 9603 [2].

 IMO, for the first issue we need weak references [3].
 IMO, for the second issue we need to make regular D objects on 
 closures [4] and fix Issue 9602 [5].

 Any thoughts about my proposal to make signals working in D? 
 Other proposals? Any (approximate) period for [proposal parts] 
 to be implemented?

 Also, does anybody think currently D has working signals and 
 I'm just slander in the title?

 P.S.
 Also there is a proposal for new signals implementation without 
 compiler changes [6].


 [1] http://d.puremagic.com/issues/show_bug.cgi?id=9606
 [2] http://d.puremagic.com/issues/show_bug.cgi?id=9603
 [3] http://d.puremagic.com/issues/show_bug.cgi?id=4151
 [4] http://d.puremagic.com/issues/show_bug.cgi?id=9601
 [5] http://d.puremagic.com/issues/show_bug.cgi?id=9602
 [6] http://d.puremagic.com/issues/show_bug.cgi?id=9347


Can you expand yourself on the subject ? I did followed 
discussion on the topic, and so this thread is quite hard to 
follow.
Apr 14 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
15.04.2013 7:46, deadalnix пишет:

 On Sunday, 14 April 2013 at 07:06:12 UTC, Denis Shelomovskij wrote:

 For "working signals" I suppose will be enough fixing of both Issue
 9606 [1] and Issue 9603 [2].

 IMO, for the first issue we need weak references [3].
 IMO, for the second issue we need to make regular D objects on
 closures [4] and fix Issue 9602 [5].

 Any thoughts about my proposal to make signals working in D? Other
 proposals? Any (approximate) period for [proposal parts] to be
 implemented?

 Also, does anybody think currently D has working signals and I'm just
 slander in the title?

 P.S.
 Also there is a proposal for new signals implementation without
 compiler changes [6].


 [1] http://d.puremagic.com/issues/show_bug.cgi?id=9606
 [2] http://d.puremagic.com/issues/show_bug.cgi?id=9603
 [3] http://d.puremagic.com/issues/show_bug.cgi?id=4151
 [4] http://d.puremagic.com/issues/show_bug.cgi?id=9601
 [5] http://d.puremagic.com/issues/show_bug.cgi?id=9602
 [6] http://d.puremagic.com/issues/show_bug.cgi?id=9347


 Can you expand yourself on the subject ? I did followed discussion on
 the topic, and so this thread is quite hard to follow.


My points was:

1. Implement a weak reference (and, better, a weak references array) as 
a general utility [3] and don't implement it in every case we need it 
(this will make `std.signals` fixing [1] trivial, one will just 
supersede incorrect internal weak ref implementation with standard one).

2. Make regular D objects on closures [4] to be able to know when 
delegate's outer scope is destroyed (this will auto-fix both [5] and 
[2], see Comment 2 of [2] for code example)


I think both points are relatively easy to implement and will improve 
things a lot.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 14 2013
parent reply Robert <jfanatiker gmx.at> writes:
 2. Make regular D objects on closures [4] to be able to know when 
 delegate's outer scope is destroyed (this will auto-fix both [5] and 
 [2], see Comment 2 of [2] for code example)


I still don't understand what that buys us. Having a closure being an
object would make it possible to use a weak reference, but why would you
want that? The signal would be the only one to hold a reference to the
lamdas context, if this reference was a weak one, then the memory would
be claimed immediately. This is why std.signals2 holds a strong ref to
the delegate context of a wrapping closure and a weak ref to the target
object.
Apr 15 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
15.04.2013 13:07, Robert пишет:

 2. Make regular D objects on closures [4] to be able to know when
 delegate's outer scope is destroyed (this will auto-fix both [5] and
 [2], see Comment 2 of [2] for code example)


 I still don't understand what that buys us. Having a closure being an
 object would make it possible to use a weak reference, but why would you
 want that? The signal would be the only one to hold a reference to the
 lamdas context, if this reference was a weak one, then the memory would
 be claimed immediately. This is why std.signals2 holds a strong ref to
 the delegate context of a wrapping closure and a weak ref to the target
 object.


With your `std.signals2` one can't e.g. forward delegate connection like 
this:
---
/// Usage: don't pass struct pointer delegates as `del`.
void f(void delegate() del)
{
     obj.event.connect(del);
}
---
as you require explicit passing an object owning a delegate.

But it is completely unnecessary as delegate do know where it was born 
from and the fact this information isn't tracked when a closure is 
created is a language design issue. One of those fixing which is easy, 
will not break any code and will improve things a lot.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 15 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 15 April 2013 at 12:07:19 UTC, Denis Shelomovskij 
wrote:

 15.04.2013 13:07, Robert пишет:

 2. Make regular D objects on closures [4] to be able to know 
 when
 delegate's outer scope is destroyed (this will auto-fix both 
 [5] and
 [2], see Comment 2 of [2] for code example)


 I still don't understand what that buys us. Having a closure 
 being an
 object would make it possible to use a weak reference, but why 
 would you
 want that? The signal would be the only one to hold a 
 reference to the
 lamdas context, if this reference was a weak one, then the 
 memory would
 be claimed immediately. This is why std.signals2 holds a 
 strong ref to
 the delegate context of a wrapping closure and a weak ref to 
 the target
 object.


 With your `std.signals2` one can't e.g. forward delegate 
 connection like this:
 ---
 /// Usage: don't pass struct pointer delegates as `del`.
 void f(void delegate() del)
 {
     obj.event.connect(del);
 }
 ---
 as you require explicit passing an object owning a delegate.

 But it is completely unnecessary as delegate do know where it 
 was born from and the fact this information isn't tracked when 
 a closure is created is a language design issue. One of those 
 fixing which is easy, will not break any code and will improve 
 things a lot.


Even with that explanation, I still don't see the problem.
Apr 15 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
15.04.2013 20:15, deadalnix пишет:

 On Monday, 15 April 2013 at 12:07:19 UTC, Denis Shelomovskij wrote:

 15.04.2013 13:07, Robert пишет:

 2. Make regular D objects on closures [4] to be able to know when
 delegate's outer scope is destroyed (this will auto-fix both [5] and
 [2], see Comment 2 of [2] for code example)


 I still don't understand what that buys us. Having a closure being an
 object would make it possible to use a weak reference, but why would you
 want that? The signal would be the only one to hold a reference to the
 lamdas context, if this reference was a weak one, then the memory would
 be claimed immediately. This is why std.signals2 holds a strong ref to
 the delegate context of a wrapping closure and a weak ref to the target
 object.


 With your `std.signals2` one can't e.g. forward delegate connection
 like this:
 ---
 /// Usage: don't pass struct pointer delegates as `del`.
 void f(void delegate() del)
 {
     obj.event.connect(del);
 }
 ---
 as you require explicit passing an object owning a delegate.

 But it is completely unnecessary as delegate do know where it was born
 from and the fact this information isn't tracked when a closure is
 created is a language design issue. One of those fixing which is easy,
 will not break any code and will improve things a lot.


 Even with that explanation, I still don't see the problem.


Do you mean that tracking an object with a delegate whenever it goes to 
just know where it's outer scope is destroyed is not a problem?

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 15 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 16 April 2013 at 05:39:32 UTC, Denis Shelomovskij 
wrote:

 Do you mean that tracking an object with a delegate whenever it 
 goes to just know where it's outer scope is destroyed is not a 
 problem?


Delegate context is allocated on the heap, unless compiler can 
prove it can do it on stack. context is destroyed when no live 
pointer point to it.

You still didn't explain why an object is better than the actual 
delegate mecanism.
Apr 15 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
16.04.2013 10:10, deadalnix пишет:

 On Tuesday, 16 April 2013 at 05:39:32 UTC, Denis Shelomovskij wrote:

 Do you mean that tracking an object with a delegate whenever it goes
 to just know where it's outer scope is destroyed is not a problem?


 Delegate context is allocated on the heap, unless compiler can prove it
 can do it on stack. context is destroyed when no live pointer point to it.

 You still didn't explain why an object is better than the actual
 delegate mecanism.


Sorry, I really don't understand what you don't understand.

Let's consider example from Issue 9603 Comment 2 [1]. Do you think such 
code must not work?

Also you can look through Issue 9601 discussion.

[1] http://d.puremagic.com/issues/show_bug.cgi?id=9603#c2
[2] http://d.puremagic.com/issues/show_bug.cgi?id=9601

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 16 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 16 April 2013 at 07:55:51 UTC, Denis Shelomovskij 
wrote:

 Sorry, I really don't understand what you don't understand.

 Let's consider example from Issue 9603 Comment 2 [1]. Do you 
 think such code must not work?

 Also you can look through Issue 9601 discussion.

 [1] http://d.puremagic.com/issues/show_bug.cgi?id=9603#c2
 [2] http://d.puremagic.com/issues/show_bug.cgi?id=9601


The code in 9603 is completely broken. It should compile and run, 
but what it does is undefined as o is finalized when delegates 
have reference to it.

I don't see how changing delegate into object would change 
anything, as the code would be broken in the same way for the 
same reason.
Apr 16 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
16.04.2013 13:17, deadalnix пишет:

 On Tuesday, 16 April 2013 at 07:55:51 UTC, Denis Shelomovskij wrote:

 Sorry, I really don't understand what you don't understand.

 Let's consider example from Issue 9603 Comment 2 [1]. Do you think
 such code must not work?

 Also you can look through Issue 9601 discussion.

 [1] http://d.puremagic.com/issues/show_bug.cgi?id=9603#c2
 [2] http://d.puremagic.com/issues/show_bug.cgi?id=9601


 The code in 9603 is completely broken. It should compile and run, but
 what it does is undefined as o is finalized when delegates have
 reference to it.

 I don't see how changing delegate into object would change anything, as
 the code would be broken in the same way for the same reason.


Current behaviour when delegates stays alive when its outer scope is 
destroyed is just a bad language design.

Let's assume there is a "magic" way to make code in Issue 9603 work. Do 
you think this is usable?

So, the "magic": I propose to make an object on closure creation (i.e. 
just prepend allocated closure with few hidden fields) and add "finalize 
the closure" to outer scope dispose event. And I already described it in 
Issue 9601 and its comments. What is non-obvious here?

Note: This can work just the same way if there is no GC-allocated closure.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 16 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 17 April 2013 at 06:15:43 UTC, Denis Shelomovskij 
wrote:

 Current behaviour when delegates stays alive when its outer 
 scope is destroyed is just a bad language design.


No, destroying is unsafe by definition, and this is why GC solve 
a lot of problems.

Can you explain what is the problem ? What does creating an 
object change except adding 2 pointers into the frame pointer ?
Apr 16 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
17.04.2013 10:43, deadalnix пишет:

 On Wednesday, 17 April 2013 at 06:15:43 UTC, Denis Shelomovskij wrote:

 Current behaviour when delegates stays alive when its outer scope is
 destroyed is just a bad language design.


 No, destroying is unsafe by definition, and this is why GC solve a lot
 of problems.


I mead destroying by GC.


 Can you explain what is the problem ?


Code in Issue 9603 doesn't work.


 What does creating an object change except adding 2 pointers into the frame
pointer ?


It will make code in Issue 9603 work.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 17 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/17/2013 12:35 PM, Denis Shelomovskij wrote:

 ...

 It will make code in Issue 9603 work.


You have to argue why this is the correct way to fix it. Why would 
lifetime control necessarily be linked to implicit object field overhead?
Apr 17 2013
parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
17.04.2013 15:26, Timon Gehr пишет:

 On 04/17/2013 12:35 PM, Denis Shelomovskij wrote:

 ...

 It will make code in Issue 9603 work.


 You have to argue why this is the correct way to fix it. Why would
 lifetime control necessarily be linked to implicit object field overhead?


0. I do like this approach, it looks straight and consistent IMO.
1. I see no other ways to fix the issue.
2. I see no important overhead in my proposal as wasting a few bytes is 
nothing in contrast with GC allocation process/memory overhead.
3. I think added functionality is very usable and even already required.

Everyone is free to propose a better approach.

By the way, almost every technical idea we know is incorrect and will be 
likely superceeded in the future with a better one as history shows.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 18 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 17 April 2013 at 10:35:08 UTC, Denis Shelomovskij 
wrote:

 Can you explain what is the problem ?


 Code in Issue 9603 doesn't work.


That is not explaining what is the problem. This should contains 
at least :
  - Why it doesn't work.
  - What is the fundamental problem.
  - Why this fundamental problem is a language issue and not a lib 
one.
  - How does you proposition solve it.

Right now, the only element you have been able to provide are :
  - signal accept delegate from object.
  - So we must make all delegate object.

This is a very poor argumentation as the only reasonable answer 
to 1 without more input is go fix signal or raise a bug about 
signal.
Apr 17 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
17.04.2013 19:47, deadalnix пишет:

 On Wednesday, 17 April 2013 at 10:35:08 UTC, Denis Shelomovskij wrote:

 Can you explain what is the problem ?


 Code in Issue 9603 doesn't work.


 That is not explaining what is the problem. This should contains at least :
   - Why it doesn't work.


No ability to tell when a delegate will be destroyed (currently it isn't 
even destroyed when it should, see Issue 9602).
http://d.puremagic.com/issues/show_bug.cgi?id=9602


   - What is the fundamental problem.


When a delegate is created information about it's outer scope is lost 
instead of being stored in it's ptr.


   - Why this fundamental problem is a language issue and not a lib one.


Looks self-evident.


   - How does you proposition solve it.


It stores the information about delegate's outer scope wasting (oh God, 
how many, especially in contrast to GC allocation) a few bytes.


 Right now, the only element you have been able to provide are :
   - signal accept delegate from object.
   - So we must make all delegate object.

 This is a very poor argumentation as the only reasonable answer to 1
 without more input is go fix signal or raise a bug about signal.


As everything I have written above is known, I still don't understand 
why you are telling about signal fixing as a main problem as it is just 
an example of problems that occurs when we throw away outer scope 
information without any practical reason, IMO.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 18 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 18 April 2013 at 13:25:32 UTC, Denis Shelomovskij 
wrote:

  - What is the fundamental problem.


 When a delegate is created information about it's outer scope 
 is lost instead of being stored in it's ptr.


That doesn't mean anything. No information is stored into a ptr 
except an address in memory.


  - Why this fundamental problem is a language issue and not a 
 lib one.


 Looks self-evident.


It look self evident to me that the earth is flat when I look 
through the window.


  - How does you proposition solve it.


 It stores the information about delegate's outer scope wasting 
 (oh God, how many, especially in contrast to GC allocation) a 
 few bytes.


I don't care about the cost. You have made no point in 3 pages in 
favor of the change you propose. Not even an invalid point I can 
disagree on.


 As everything I have written above is known, I still don't 
 understand why you are telling about signal fixing as a main 
 problem as it is just an example of problems that occurs when 
 we throw away outer scope information without any practical 
 reason, IMO.


It is an example of a library interface issue (very real). To 
propose a language change, you must show that this limitation is 
in fact a symptom of a deeper cause, which it at language level 
(so that must be fixed at language level).
Apr 18 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
18.04.2013 18:21, deadalnix пишет:

 On Thursday, 18 April 2013 at 13:25:32 UTC, Denis Shelomovskij wrote:

  - What is the fundamental problem.


 When a delegate is created information about it's outer scope is lost
 instead of being stored in it's ptr.


 That doesn't mean anything. No information is stored into a ptr except
 an address in memory.


A joke? Of course I mean "stored into a memory ptr point to".


  - Why this fundamental problem is a language issue and not a lib one.




 ...
 I don't care about the cost. You have made no point in 3 pages in favor
 of the change you propose. Not even an invalid point I can disagree on.


 As everything I have written above is known, I still don't understand
 why you are telling about signal fixing as a main problem as it is
 just an example of problems that occurs when we throw away outer scope
 information without any practical reason, IMO.


 It is an example of a library interface issue (very real). To propose a
 language change, you must show that this limitation is in fact a symptom
 of a deeper cause, which it at language level (so that must be fixed at
 language level).


Another try to describe the problem:

When I get a delegate, I'd like to use it unless it become invalid.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 19 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij 
wrote:

 Another try to describe the problem:

 When I get a delegate, I'd like to use it unless it become 
 invalid.


How does using an object solve that ?
Apr 19 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
19.04.2013 11:45, deadalnix пишет:

 On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote:

 Another try to describe the problem:

 When I get a delegate, I'd like to use it unless it become invalid.


 How does using an object solve that ?


Unless this is a struct-member delegate (which is not often used anyway 
and can be marked as dangerous e.g.):
---
T delegate(A) del = ...;
rt_attachDisposeEvent(_d_toObject(del.ptr), &onDelegateDisposed);
---

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 24 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 24 April 2013 at 08:27:15 UTC, Denis Shelomovskij 
wrote:

 19.04.2013 11:45, deadalnix пишет:

 On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij 
 wrote:

 Another try to describe the problem:

 When I get a delegate, I'd like to use it unless it become 
 invalid.


 How does using an object solve that ?


 Unless this is a struct-member delegate (which is not often 
 used anyway and can be marked as dangerous e.g.):
 ---
 T delegate(A) del = ...;
 rt_attachDisposeEvent(_d_toObject(del.ptr), 
 &onDelegateDisposed);
 ---


I still see many possibilities without changing the language. For 
instance, allowing to attach dispose event to something else than 
an object.
Apr 24 2013
parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
24.04.2013 12:47, deadalnix пишет:

 On Wednesday, 24 April 2013 at 08:27:15 UTC, Denis Shelomovskij wrote:

 19.04.2013 11:45, deadalnix пишет:

 On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote:

 Another try to describe the problem:

 When I get a delegate, I'd like to use it unless it become invalid.


 How does using an object solve that ?


 Unless this is a struct-member delegate (which is not often used
 anyway and can be marked as dangerous e.g.):
 ---
 T delegate(A) del = ...;
 rt_attachDisposeEvent(_d_toObject(del.ptr), &onDelegateDisposed);
 ---


 I still see many possibilities without changing the language. For
 instance, allowing to attach dispose event to something else than an
 object.


Thus making that "something else" almost class but not class and I don't 
see why not just use class instead of creating a new entity.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 26 2013