teetime-framework / TeeTime

The Java reference implementation of the Pipe-and-Filter framework TeeTime
http://teetime-framework.github.io
Apache License 2.0
20 stars 4 forks source link

Type Safety #31

Open DaGeRe opened 1 year ago

DaGeRe commented 1 year ago

As far as I get it, a pipe always uses the same data type, and just transfers an instances. Why does it only return Object on removeLast? https://github.com/teetime-framework/TeeTime/blob/94c7703099be8e1ecd3693cf56d41bb2fa2373df/src/main/java/teetime/framework/pipe/IPipe.java#L74 As far as I see it, T or ? extends T should also work.

rju commented 1 year ago

It looks like that add(Object) and addNonBlocking(Object) also have no type constraint. We could create a branch and make these functions use T or ? extends T as type. Also getTargetPort uses , but getSourcePort uses <? extends T>

rju commented 1 year ago

Hab rausgefunden warum das nicht so einfach zu machen ist. In AbstractPort gibt es ein statisch definiertes Element TERMINATE_ELEMENT, welches vom Typ Object ist. Das wird dann in OutputPort genutzt in

    public void sendSignal(final ISignal signal) {
        if (signal instanceof TerminatingSignal) {
            pipe.add(TERMINATE_ELEMENT);
        }

        pipe.sendSignal(signal);
    }
rju commented 1 year ago

Have a look, I put the current changes in the branch 31-type-safety

DaGeRe commented 1 year ago

Thanks for the try, one solution seems to be to use null as empty element: https://github.com/teetime-framework/TeeTime/pull/32 Does this make sense to you? If not, maybe we should leave it as it is.

In this case, we'll just need to fix the setPipe problem (it seems to work when using T instead of ? extends T in the signature, but then, other errors occur.

rju commented 1 year ago

I think, we have to find out why a termination object is required.

DaGeRe commented 1 year ago

I would expect the termination object to be required as for consumers of a pipe are listening, until the termination object comes, and than they stop their activity. This would also work with null, as long as no other thing passed to a pipe is null, because this would stop the processing. But we can discuss this on Tuesday.

rju commented 1 year ago

Good idea. I'll ask Nelson about the issue. Maybe he has some insights.

rju commented 1 year ago

Nelson has no idea, but Christian provided some insights:

Ihr habt richtig herausgefunden, wieso Object auf Pipe Ebene notwendig ist, um auf höherer Ebene type safe zu sein. Das TerminateObject habe ich eingeführt, damit der User nicht wissen muss, inwiefern spezielle Werte wie null ok sind oder nicht. Das TerminateObject ist private und kann so niemals durch den User aus Versehen oder mit Absicht in die Pipe gelangen.

The object is relevant to be type safe on a higher level. The TerminateObject ensures that users can do not need to know whether "null" as entry is valid or not. The TerminateObject is private to ensure a user cannot accidentally use it.

We should either document this in the code or alternatively have another solution for it. In both cases we should add this to the documentation for maintainers and users.