-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repo API: Do we need model partitions? #29
Comments
In Freon, and before in Mendix, and various other environments (Eclipse, Microsoft Modeling Tools) I have used model partitions (I currently call them model units) extensively. The private/public notion and the much smaller index allows to have e.g. all data for code completion to be locally available in the client. We had some really large models at Mendix, where it does work ok. A model partition in Freon is just another Node, with some restriction on its properties. I don't see these restrictions as essential, so it could just be a node. The main thing is that a concept can be marked as a Model Part in the meta-model of a language. In Freon Model Parts are similar to root nodes in MPS. In Freon we also have a Model Node which is the root of the model. Model Nodes can only have Model Parts as children and a Model Node is the only node that does not have a parent. We do not nest Model Parts, did not need it until now, not sure how useful that will be. An additional pro:
All properties inside a Node can be defined either be public or private. If a property is public, the nodes inside the property are visible/referrable from other model parts. This allows the language designer to hide internal details of a model part and make sure they cannot be referred to from other model parts. This makes it possible to replace a model part by another one. We call the visible nodes of a model part the |
I find these partitions useful conceptually: as a user I like to have some way to organize elements. I also think these divisions are useful for performance, scoping, encapsulation, and possibly to handle permissions (if we decided to support those) |
I find them useful as well. One drawback of the idea of a model being composed of units is that it a priori forces the organization. Can we generalize that idea in a meaningful and useful way, e.g. through defining custom partitions. Each partition could be a collection of roots, and the idea of an interface of a partition probably works the same way. |
The definition of which types of modelunits there are in a language is an important concern for the language engineer defining the meta-model of the language. Just like e.g. Java defines classes and interfaces as part of the language definition and defines which subnodes of classes and interfaces are visible/referable. A custom partition as a collection of roots is something quite different as far as I understand. |
We should separate two different wways of organising models.
The Model Units as I used them and describe them are of type 1. |
Yeah, the problem with custom grouping is that what might be interesting/necessary to expose might depend on that grouping. So, if you provide the mechanism of model units, you at least can definitively figure out what to expose. For custom groupings, you might not even be able to? |
You might use a means of grouping model units in (virtual) folders, semantically meaning nothing. |
I'm thinking along the lines of designating a bunch of roots as an “area of interest”, but I guess that's in practice probably pretty similar to a bunch of roots. |
Updated original comment to reflect decisions on 2023-06-02 |
Open questions
|
We might revisit how to mark partition Concepts once Annotations are available (#13 ) |
How to specify Partition Concepts in MPS?Assume we have a language in MPS, and want to export it to LIonWeb. How do we specify the value of the partition flag? Candidates:
|
Decision via Slack vote: Name "Partition" |
Model partitions are similar to
Use cases
Model partitions could be useful for:
If we allowed permissions on every node, we have the same issue as e.g. ACLs in NTFS
Example: Web editor checks whether it knows all the concepts in this part of the model and can display them.
Assumptions
--> partitions are "nodes with something extra"
Considerations
--> probably not more than we already have with our repository idea
Arguments
Pro:
Con:
Dealing with something else than nodes complicates APIs
Possible solution:
A partition is bound to a node in the model (e.g. by a special flag in the node's concept, or a special implemented
ConceptInterface
.) Thus we can never ask for a partition directly, but only for the node that happens to be hosted in its own partition.Might introduce issues in combination with versioning
Alternatives on partitions
Option A: No partitions
Some nodes happen to have no parent
Pro:
Con:
Option B: Non-nested partitions
Only partitions can be without parent
Pro:
Con:
Option C: Nested partitions
Subtrees of partitions can be their own partition
Pro:
Con:
How to mark partitions
Alpha: In metamodel as flag of Concept
For each concept, the language designer decides whether it's a partition concept.
A concept flagged as partition can only be used as partition.
Beta: In instance
Any instance can be marked as a partition.
If we chose option B above, then not having a parent node implies that node to be a partition. Otherwise, we can explicitly set an instance to be a partition.
Decision: Option B with variant alpha: Non-nested partitions with flag on concept for partitions
Rationale: Some kind of partition concept is useful, and non-nested partitions add only a reasonable overhead.
Consequences
We need to collect more experience with partitions. For now, we start with these assumptions:
Details on concept flag
New property in M3:
Concept
gets new propertypartition: boolean
. Default value isfalse
, value is not inherited.Example:
A { partition: true }
B extends A {}
C extends A { partition: false }
D extends A { partition: true }
Then
A
creates a partitionB
does not create a partition, it can be used as child of another nodeC
does not create a partition, it can be used as child of another nodeD
creates a partitionAlternative on concept flag: Marker interface
We ship an interface like
IPartition
in our standard library, and any concept that implements that interface is a partition.Drawback: Cannot "unset" partition flag in this way.
Alternative on concept flag: Annotation
Might be useful in future once we have annotations.
We don't want to wait for them for introducing this flag.
The text was updated successfully, but these errors were encountered: