Connections
Thinking about the way elements of a performance need to be connected up in order to work. Elements here are the independent "aspects" that need to communicate data to each other to run. For instance one aspect might be a cd player that can be controlled by a particular protocol, another might be a process that renders video from a file.
For interactivity there is another kind of data sharing going on between decision making elements. Information accessed is knowledge that is used to make decisions about how to act. This is a similar but different problem.
Perhaps there is a way to have the objects themselves connect up based on agent architecture types of connections.
Perhaps classes of objects produce data, others consume, some control, others do some other task. This is mainly a recognition that some types of communication and sharing between objects occurs implicitly. For instance, if a process needs to know the time, it doesn't care where it gets it. So data can be requested and answered through management by the scheduler/os.
Other kinds of data is explicitly chained/pipelined together in a flow network.
"Implied ordering" and "implied iteration" are useful concepts here. Implied ordering would allow people to implicitly know what tasks are used where and implied iteration takes away the need to create indexing loops into lists.
On the coding end of things its useful to separate operations on data from indexing through the data explicitly. If indexing is separated from operations, then a non-programmer can add behaviors without having to know details about the structure of the object with which they are working. An example of this is "eyes" where an image operator can be created to modify an image by just writing the code that happens at every pixel and not having to worry about how the image data is structured.
For interactivity there is another kind of data sharing going on between decision making elements. Information accessed is knowledge that is used to make decisions about how to act. This is a similar but different problem.
Perhaps there is a way to have the objects themselves connect up based on agent architecture types of connections.
Perhaps classes of objects produce data, others consume, some control, others do some other task. This is mainly a recognition that some types of communication and sharing between objects occurs implicitly. For instance, if a process needs to know the time, it doesn't care where it gets it. So data can be requested and answered through management by the scheduler/os.
Other kinds of data is explicitly chained/pipelined together in a flow network.
"Implied ordering" and "implied iteration" are useful concepts here. Implied ordering would allow people to implicitly know what tasks are used where and implied iteration takes away the need to create indexing loops into lists.
On the coding end of things its useful to separate operations on data from indexing through the data explicitly. If indexing is separated from operations, then a non-programmer can add behaviors without having to know details about the structure of the object with which they are working. An example of this is "eyes" where an image operator can be created to modify an image by just writing the code that happens at every pixel and not having to worry about how the image data is structured.
0 Comments:
Post a Comment
<< Home