Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type Safety #31

Open
DaGeRe opened this issue Jun 27, 2023 · 8 comments
Open

Type Safety #31

DaGeRe opened this issue Jun 27, 2023 · 8 comments

Comments

@DaGeRe
Copy link
Contributor

DaGeRe commented Jun 27, 2023

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?


As far as I see it, T or ? extends T should also work.

@rju
Copy link
Collaborator

rju commented Jun 27, 2023

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
Copy link
Collaborator

rju commented Jun 27, 2023

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
Copy link
Collaborator

rju commented Jun 27, 2023

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

@DaGeRe
Copy link
Contributor Author

DaGeRe commented Jun 28, 2023

Thanks for the try, one solution seems to be to use null as empty element: #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
Copy link
Collaborator

rju commented Jun 29, 2023

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

@DaGeRe
Copy link
Contributor Author

DaGeRe commented Jun 29, 2023

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
Copy link
Collaborator

rju commented Jun 29, 2023

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

@rju
Copy link
Collaborator

rju commented Jun 29, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

2 participants