4 ms·

Hm why is there only a single syntax -> for a connector? If different connectors have different semantics, as local and remote communication fundamentally do,

by chubot 2y ago

Hm why is there only a single syntax -> for a connector? If different connectors have different semantics, as local and remote communication fundamentally do, then it seems like you want different syntax too With a single syntax, it does feel like trying to be a "universal" connector

mpweiher 2y ago
Thanks for reading! And yes, the → can be unexpected. If you don't think about it, it just does what you expect it to do. And if you look at the details, it also makes sense. This is explained in section 3. It turns out that → is not the actual connector. In software architecture, the connector does not directly connect components. It goes via the ports on the component(s), which are "connected" (different kind of "connected") to the roles on the connector. Nominally, the → does this hooking up, so in theory it goes something like this: Component1.port1 → connector.rolaA .. connector.roleB → Component2.port2 So the → "really" hooks up components to connectors via their respective ports and roles, it's not the connector and does not represent the connector. So there are no different semantics, it's always "please hook up this port to this role". For the vast majority of cases, this much detail is way too cumbersome, which is probably one reason architecture description languages did not catch on. Fortunately it is also unnecessary in the vast majority of cases. Objective-S takes advantage of this by making → polymorphic. So you can leave out the ports, the roles and often even the specific connector, and → figures it out anyway, filling in the blanks. This has been working extremely well so far. If either it becomes necessary because there is ambiguity or you want to document what's going on, you can specify all these intermediate elements that → figures out for you. I have thought about a syntax to make connectors explicit and still look like connectors, something along the lines of filterA -pipe-> filterB So you put the name of the connector inside the arrow. But it seems a bit wonky and so far just hasn't been proved necessary.

by chubot 2y ago

mpweiher 2y ago

Thanks for reading! And yes, the → can be unexpected. If you don't think about it, it just does what you expect it to do. And if you look at the details, it also makes sense. This is explained in section 3. It turns out that → is not the actual connector. In software architecture, the connector does not directly connect components. It goes via the ports on the component(s), which are "connected" (different kind of "connected") to the roles on the connector. Nominally, the → does this hooking up, so in theory it goes something like this: Component1.port1 → connector.rolaA .. connector.roleB → Component2.port2 So the → "really" hooks up components to connectors via their respective ports and roles, it's not the connector and does not represent the connector. So there are no different semantics, it's always "please hook up this port to this role". For the vast majority of cases, this much detail is way too cumbersome, which is probably one reason architecture description languages did not catch on. Fortunately it is also unnecessary in the vast majority of cases. Objective-S takes advantage of this by making → polymorphic. So you can leave out the ports, the roles and often even the specific connector, and → figures it out anyway, filling in the blanks. This has been working extremely well so far. If either it becomes necessary because there is ambiguity or you want to document what's going on, you can specify all these intermediate elements that → figures out for you. I have thought about a syntax to make connectors explicit and still look like connectors, something along the lines of filterA -pipe-> filterB So you put the name of the connector inside the arrow. But it seems a bit wonky and so far just hasn't been proved necessary.