Deepen model, interpreter and resolver component

[maldins46]

The model component is the essential data foundation of the project. It must be studied and founded.

[maldins46]

Summarizing today's work with @corinz97 and @ThomasAngeliniUnibo:

In 8672611 we experimented some solutions for the Item basic implementation.

What we need is a structure that makes it possible to execute an Update, when a Statement is detected, only if some conditions are satisfied. We are deepening particularly the case of the TransitiveStatement, concerning an Action and an Item.

The solution uses a PartialFunction as a trigger for the condition, which returns an Update only if the condition is satisfied. The Interpreter is the component that triggers this mechanism, started for the transitive action the Item::use method.

Very important is the manner used to engage a ready-to-use Behavior, a sort of plugin that can be attached to the Item (ex. Takeable, Openable, ecc.), that comprehends the logic, a partial function, and eventually the resulting update.

Today we experimented with the engage with a mixin. This is of course an elegant solution, but has the important problem of not being configurable: it is not possible, for example, passing parameters into a mixin in Scala (how do I specify, for example, what Room to go into passing a door with a Traversable behavior?). An alternative solution, to be tested, could be engaging a behavior as an object into the Item with a factory. Constructing the Item with a specific factory, we can introduce the possibility to add pre-configured Behaviors to the Item.

An additional comment: d574d97 was just a test, not a definitive version.

[maldins46]

What we've done today with with @corinz97 and @ThomasAngeliniUnibo (commits c2787cd and 35354bf):

• We have deepened the behavioural model with a more solid structure
• We have experimented on how to modify the State with Lens

We have some doubts about how to organize code, as the type system used for circular dependencies makes it very difficult; we should discuss together in the next general meeting about this.

[maldins46]

What on days 30th and 31th of December, we made some experiments for model refactoring in common meeting the entire group. The experiments can be consulted in fe7e37f, but they are only scratches, for future modification: they will not flow into the main branch.

The reason for this experiment is that the model has a subtle problem regarding a circular dependency between Item and State. This is a problem because, on many occasions, the concrete implementation of State should access the concrete implementation of Item, and vice versa, without losing the original references. We initially tried to solve the problem using the concept of type projection, but the initial solution had some problems when passing the state in the Interpreter component. We know that for specific cases, using type projection could be unsound (so much so that they have been removed in Scala 3), but for our specific case, it was an elegant solution; except for the fact that the aforementioned problem arose during model development.

The experimented solution, in contrast, exploits the concept of type classes, in combination with type projection for some specific steps. The solution should be perfected and applied to an official solution, but it is a good starting point for its implementation.

PS: please correct me if I said anything wrong in this meeting smmary

[maldins46]

What has been done in the latest two weeks, for this task, by the team @maldins46 / @corinz97 / @ThomasAngeliniUnibo:

• We finished and cleaned implementations for the BehavioralModel;
• We finished and cleaned Pipeline implementations and interface, for what belongs to us (Reducer,Interpreter and Resolver);
• On that basis, we have unified the "builder" style used in Pipeline and into the ItemRetriver;
• We set up the remaining unit tests.

In the end, revisioning the code, we encountered an unexpected major problem, regarding the item references: as we basically re-create the State for each Pipeline round, we are going to lose all the matches between ItemRefand Item. In other words, the initial Map[ItemRef, Item] used from the Interpreter in the first Pipeline round, can not be used in the next ones.
The solution we have come up with (together with @francescogorini) involves the insertion of the corresponding ItemRef directly inside the Item, and a new method State::extractRef() inside the State: at the end of the pipeline execution, the method is invoked, from the updated State, to recreate the Map[ItemRef, Item]. Then, the new map is passed to the next implementation of the Interpreter.