-
-
Notifications
You must be signed in to change notification settings - Fork 9
Feature: alias/inheritance types #25
base: master
Are you sure you want to change the base?
Conversation
(from a person who never used inheritance in DB/ORMs entities): it may be a problem when there is no constraint that guarantees that both |
As an additional feedback, I'd add that this behavior is actually configurable case-by-case. Following cases are also possible:
|
This is probably very naive but indexing the object in i.e. |
* @return string | ||
*/ | ||
public function resolveType($type); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EOL EOF
@mnapoli yeah, that is one possible solution indeed, though it's not very efficient, isn't it? |
Not so efficient for memory usage but I have no idea if the difference is actually problematic. But in any case you will have to get the parent classes. But is that kind of metadata cached? If it is, then I guess it's just a matter of get/set X times in the array instead of once (where X is the number of parent classes). Shouldn't be too bad? |
Yep, I will cache everything possible
Probably better indeed (rather than slowing down the process for every type). I'll think about it, thanks :-) |
If there's a constraint that they all share the same id space then I would always go to the root and use its name. So for Foo extends Bar, with Foo#123 and Bar#827 there would be an |
This PR is about supporting inheritances/aliases:
Since
Bar
is a subtype ofFoo
, requestingFoo
to theIdentityMap
should also look up in theBar
instances.The opposite is not true:
I really could need some help on this, as I'm a bit confused about how to actually implement this logic in a performance-sensitive way.
I may also need to split the type resolver so that we actually loop through subclass/superclass types, or we duplicate the references in the identity map.
Thoughts anybody?