Is there any plans to make working signals in D?
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
Re: Is there any plans to make working signals in D?
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 >
Re: Is there any plans to make working signals in D?
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
Re: Is there any plans to make working signals in D?
> 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
Re: Is there any plans to make working signals in D?
Am Sun, 14 Apr 2013 19:07:58 +0200 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 ) 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.
Re: Is there any plans to make working signals in D?
> 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
Re: Is there any plans to make working signals in D?
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 or a weak reference. In C#, people forgetting to disconnect event handlers is the most common source of memory leaks. Let's not bring that to D.
Re: Is there any plans to make working signals in D?
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.
Re: Is there any plans to make working signals in D?
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
Re: Is there any plans to make working signals in D?
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
Re: Is there any plans to make working signals in D?
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.
Re: Is there any plans to make working signals in D?
> 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
Re: Is there any plans to make working signals in D?
> 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.
Re: Is there any plans to make working signals in D?
> 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.
Re: Is there any plans to make working signals in D?
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
Re: Is there any plans to make working signals in D?
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.
Re: Is there any plans to make working signals in D?
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
Re: Is there any plans to make working signals in D?
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.
Re: Is there any plans to make working signals in D?
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
Re: Is there any plans to make working signals in D?
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.
Re: Is there any plans to make working signals in D?
Am Sun, 14 Apr 2013 21:29:07 +0200
schrieb 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.
>
> 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)
I have used that concept quite often in C#. Of course it's also
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)
Re: Is there any plans to make working signals in D?
(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
Re: Is there any plans to make working signals in D?
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
Re: Is there any plans to make working signals in D?
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 ?
Re: Is there any plans to make working signals in D?
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
Re: Is there any plans to make working signals in D?
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?
Re: Is there any plans to make working signals in D?
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.
Re: Is there any plans to make working signals in D?
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
Re: Is there any plans to make working signals in D?
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
Re: Is there any plans to make working signals in D?
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).
Re: Is there any plans to make working signals in D?
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
Re: Is there any plans to make working signals in D?
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 ?
Re: Is there any plans to make working signals in D?
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
Re: Is there any plans to make working signals in D?
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.
Re: Is there any plans to make working signals in D?
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
