updating a signal ('a') which has a dependent subscriptable signal ('b')

[jkbhagatio]

causes an error when 'a' gets updated in a way which 'b' does not expect. e.g.

net = sig.Net;
a = net.origin('a');
sub = a.subscriptable;
b = sub.aField;
a.post(1);

causes:

Dot indexing is not supported for variables of this type.

Error in sig.transfer.subsref (line 39) val = what.(subs);

Error in sig.node.OriginSignal/post (line 15) affectedIdxs = submit(this.Node.NetId, this.Node.Id, v);

Error in sig.node.Signal/subsref (line 393) [varargout{1:nargout}] = builtin('subsref', a, s(ii:end));

I think the appropriate behavior should be to not try and update 'b' when 'a' gets posted a value that is incompatible with 'b'

[k1o0]

I'm concerned that hiding the user's mistakes will make writing experiments more difficult and could make things difficult to debug. I think the user should also be free to change data types if they wish, but it will be up to them to implement things correctly.

[jkbhagatio]

How about a case in which an origin signal sometimes posts a struct that makes the dependent signal update, and sometimes posts something else? I don't think there is currently any way to handle this behavior.

And what exactly do you mean by

the user should also be free to change data types

[k1o0]

How about a case in which an origin signal sometimes posts a struct that makes the dependent signal update, and sometimes posts something else? I don't think there is currently any way to handle this behavior.

I agree there is no simple way to handle this, but it doesn't seem clear to me when or why this use case would occur. If a user did find themselves in this situation the simplest (and clearest) solution would be to simply assign the two values to different Signals, then use cond to process the two Signals independently before assigning their outputs to one Signal further down the line.

And what exactly do you mean by

the user should also be free to change data types

In the past you have suggested we simply throw an error if the data type of a Signal changes (it would be a solution of sorts to this issue). I'm against this because as with the rest of MATLAB variables are free to change type. In general it's a bad idea to have variable constantly change data type, especially in functional programming, however sometimes it's quite tidy, like converting a continuous variable to a binary one by making it a logical. In any case, these decisions can be largely left up to the user because the framework is pretty open. This error won't happen often because parameters can't change type and can't be structs. The error thrown is a MATLAB one which is quite clear, so the user would able to work around the problem quickly.

[jkbhagatio]

In the past you have suggested we simply throw an error if the data type of a Signal changes (it would be a solution of sorts to this issue).

In some scenarios, yes, but not generally. When we had our last meeting with Chris, he seemed to be in favor of stronger typing in Signals.

I'm against this because as with the rest of MATLAB...

You use this argument a lot, but I don't think that when one is creating a framework they should necessarily adhere to all the customs of the programming language in which the framework is being created, especially when the framework is trying to implement things in specific ways, and the programming language tries to implement things in general ways.

The error thrown is a MATLAB one which is quite clear, so the user would able to work around the problem quickly.

I disagree with this. The error doesn't really tell you which part of the code caused the error, and I think it would be even more confusing in an actual exp def than in my code snippet.

If a user did find themselves in this situation the simplest (and clearest) solution would be to simply assign the two values to different Signals...

In some scenarios, maybe, but I can think of cases in which your proposal wouldn't be the simplest or clearest.

I'll make this low priority, but I'll work on what I think is a good solution and we can discuss it then.

[k1o0]

I'm against this because as with the rest of MATLAB...

You use this argument a lot, but I don't think that when one is creating a framework they should necessarily adhere to all the customs of the programming language in which the framework is being created, especially when the framework is trying to implement things in specific ways, and the programming language tries to implement things in general ways.

I agree that we don't have to adhere to MATLAB's customs but there should be good reason not to. This is because users will generally expect things to work like they would in a normal MATLAB script. The more we depart from the way MATLAB normally works, the steeper the learning curve for the user (in general).

The error thrown is a MATLAB one which is quite clear, so the user would able to work around the problem quickly.

I disagree with this. The error doesn't really tell you which part of the code caused the error, and I think it would be even more confusing in an actual exp def than in my code snippet.

You're right that the error could be clearer. By Signals standards though it's pretty clear. I think devoting time to improving the error handling in Signals (especially reporting at which node the problem occurred) would be far more valuable than spending time on a feature that will be rarely used.

If a user did find themselves in this situation the simplest (and clearest) solution would be to simply assign the two values to different Signals...

In some scenarios, maybe, but I can think of cases in which your proposal wouldn't be the simplest or clearest.

Mind elaborating on this?