std.signals2 proposal

[Ellery Newcomer]

On 11/06/2012 04:10 AM, Robert Klotzner wrote:
>> Not sure I understand why such hatred is rational?

nvm

>
>> in emit:
>>
>> if(slot.indirect.ptr) {
>>    <stuff>
>> }else{
>>    <otherstuff>
>>    slot.indirect.ptr = <thing>
>>    slot.indirect(i);
>> }
>>
>> <stuff> will not be executed more than once?
> <stuff> is: 	"slot.indirect(cast(void*)(objs[index]), i);"
> and gets executed for every slot. I am not sure I understand your
> question.

// slot[i].indirect.ptr == null
thing.emit(params);
// slot[i].indirect.ptr != null
thing.emit(params);

>
> well yes, because every class derives from Object. But the requirement I
> need is that T2 is derived from Object, so it makes the intent more
> clear.

IsExpression rarely does what you want it to, especially with that 
colon. I have come across many such IsExpression usages.

Off the top of my head in your case:

is(shared(Object) : Object);
is(const(Object) : Object);
is(immutable(Object) : Object);
is(AnyInterface : Object);

std.traits.BaseTypeTuple might be the way to go if you want clarity.

Also, this brings us to the spectre of const correctness, which I will 
drop just as quickly (but keep it in mind - phobos already has too much 
code that isn't const correct)

> -> No I should not, at least in the current implementation this would be
> wrong. I did not yet made up my mind how I want to implement it in the
> end, so I left it for now.

Ah. Well, do something so I stop double-taking every time I see 
objs[slot_idx-1] or somesuch.


> That you can not pass some arbitrary slot like:
>

Ok, I'm starting to see what you're doing here.

> I knew this was coming. Well I haven't done anything with closures yet,
> the usage is an escaping of a reference so the compiler should allocate
> it on the heap, if not than you got a problem, but its not specific to
> signals -> So I still consider the signal API safe ;-)

Heh. Perhaps trusted is a more apt description.

>
>>
>>> Also I did not really get the point why a mixin was used in the first
>>> place, it does not really gain us anything? What was the reasoning about
>>> it?
>>
>> So you can do b.connect in the simplest case?
> Yes, that's the only reason that comes to mind. I personally think that
> a struct is a cleaner solution, that also avoids cluttering the
> containing objects namespace.

I think you're right.