Hello,
on page 9, line 28/29 the specification states:
There exists a default recipe for each basic dish, but restaurants are allowed to customize them.
But in the config file it is not visible how this customization would take place. A restaurant only gets assigned a number of ids for recipes but no option on how to change these.
The “Recipe Change” incident changes the recipe for all restaurants and not only one, so I would argue that this is not meant here as “customization”.
Hi,
A restaurant customizes a basic dish by owning a different recipe object for it: a second recipe with the same dishName as the default one, but without the basicDishFor property — only the default recipe carries it, since there must exist exactly 1 recipe per basic dish. The restaurant then lists the id of that recipe in its recipes array instead of the id of the default one. As each restaurant may have only 1 recipe per dish name, it must not reference both.
In the given config file this simply is not used — every restaurant references the default recipes, so no customization happens there. You are right that the “Recipe Change” incident is not what is meant by customization here.
So there can be multiple instances of one dishName in the config file, with different IDs. And each restaurant would reference the different IDs depending on their customization?
And if they do not reference any ID for that dish, they would take the default recipe?
yes, that’s a right understanding
But the dishes, that are cooked with any recipe which contains this dishname are still basicdishes as long as one of the recipes has the basicDIshFor property, regardles which recipevariation our Dish is actually cooked with?
yes for the adaptation case, but “basic dish” has to be scoped to the restaurant’s own type, for a restaurant R of type T, a dish D is a basic dish in R exactly when the food file contains a recipe with dishName == D and basicDishFor == T. Whether R serves D through that default recipe or through its own adapted recipe (same dishName, no basicDishFor of its own) changes nothing. When the spec says “basic dishes take precedence”(cook assignment, partial serving, delivery order), it means this set of dishes.
The part that is not “regardless”: if the only recipe carrying basicDishFor for that dish names a different restaurant type, the dish is an additional dish in R, not a basic dish. In the appendix, restaurant “Fire” is EUROPEAN and owns recipe 1 “chicken rice” (basicDishFor: ASIAN), that’s an additional dish there, and it does not get basic-dish precedence in that restaurant.
What does the constraint "There must exist exactly 1 recipe per basic dish name.” then mean?
I have interpreted it as there must exist exactly 1 basicDishFor property for all names that are dishNames with a basicDishFor property.
For example if “Chicken Rice” is a basic dish for Restaurant Type ASIAN, there can not be a recipe “Chicken Rice” which is a basic dish for any other Restaurant Type, but there can exist a recipe with no basicDishFor property with dishName “Chicken Rice”.
However, I am not entirely sure with my interpretation and would appreciate any corrections.
Hi
This is correct.
This is also correct, also, if Chicken Rice is a basic dish for restaurant type Asian, then a restaurant of another type can still include this exact recipe in their recipe ids as their normal dish.