Description
Hello,
Very interesting project! I love how Cell utilizes least amount of concepts to let programmers build very capable application. Thanks for taking this cool idea and implementing it.
Having said that, I would like to share my concern about building large application with Cell.
I do understand that one of the design goal of the Cell is to be "decentralized". Cell allows each/any Cell to communicate(invoke other Cell's functions, read/manipulate data) freely with any other Cells via query selectors and using "context inheritance" (may be other methods that I am not aware).
With small number of Cells interacting each other, the program is not too difficult to reason about, or understand. However, as the number of Cells increase, and inter-cell dependency increases, I'm afraid that the program will quickly become too complex.
Any changes to existing data fields, function signatures, etc could have unknown/unforeseen side effects very easily with large number of "edges".
With careful design and planning programmers could delay the program becoming too complex, but as the program ages and more features are added/removed/modified, it's bound to cross the line(from simple to understand the program -> difficult to understand) at some point.
So I have a suggestion to address this issue.
How about adding well defined restrictions on how/who each Cell can communicate?
There are many different ways to implement it, but here is my suggestion.
Let each Cell define a specification on how other Cells can interact with self.
Say, $spec: "Only the Cell with $id = 'Hi' can call function _hello"
Or, $spec: "Allow any Cell with $id = 'Bye' to access all functions"
Or, $spec: "Only the function 'Xyz' can be invoked by any other Cells".
Such specifications can help reduce complexity, since we do not allow "any to any" dependencies(by default). Programmers will need to explicitly allow certain communications between Cells, so we could be certain that when we modify a single Cell's code, it will have well known side effects.
It's like a defensive wall agains other cells to prevent inter-cell dependencies becoming too complex to manage/reason about.
There are many different ways to implement this, which isn't the scope of this article. (One such example is private/public functions in OOP)
I'm not sure whether this belongs to core module, or it should exist as an extension.
Hope this suggestion was useful, again, thanks for implementing Cell!