jmix-framework
Some methods of the MetadataTools extends corresponding methods of the MetaClass
There is a method io.jmix.core.metamodel.model.MetaClass#getPropertyPath. It doesn't work with the properties of extensions like the Dynamic Attributes. But there are method io.jmix.core.MetadataTools#resolveMetaPropertyPath that do it.
This is not obvios for the programmer that in order to work with all amount of the properties he have to use API of the MetadataTools but not the API of the MetaClass. This might be a couse of the mistakes. Futhermore it is more natural and straightforward to use MetaClass API.
In order to do it we should put MetadataExtension, MetaPropertyPathResolver instances(or its results) into the MetaClass and modify its API.
The same problem is with methods io.jmix.core.metamodel.model.MetaClass#getProperty. We should use io.jmix.core.MetadataTools#resolveMetaPropertyPathOrNull instead of it.
Not equal but very similar situation is with methods io.jmix.core.metamodel.model.MetaClass#getProperties and io.jmix.core.MetadataTools#getAdditionalProperties.
The proposal is to add overloaded methods "getProperties", "getProperty" and "getPropertyPath" with boolean parameter that determines to take extensions into account or not. Old methods in the MetaClass and in the MetadataTools should be deprecated.
Additionaly if the MetaClass will support properties extentsions the io.jmix.core.MetadataTools#isAdditionalProperty method can be added to MetaClass too.
see the last part of https://github.com/jmix-framework/jmix/issues/4874#issuecomment-3529350987
Adding beans to MetaClass(1700+ usages)/MetaProperty(1000+ usages) descriptors - how it will affect performance? hashCode calculation?
Blurring border between these classes and MetadataTools looks like a bad practice and violation of single responsibility principle. Especially since we will not fully get rid of MetadataTools, but just move part of methods, making responsibility and usage of these classes less clear.
Dynamic attributes is a standalone functionality with special methods to access these attributes as described in documentation. It is not worth to distort the architecture of metadata which works fine in 99% of cases to make 1% of usages simpler.
It will also break extensibility of logic. Currently, in order to modify MetadataTools logic, we can just override this bean.
In case of moving it's logic to MetaProperty and MetaClass it will not be possible anymore since MetaProperty and MetaClass are not beans and they cannot be replaced.
