You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having type hierarchies across multiple files and projects will allow for extensible designs when the base class is in a consumed library. This would allow for something such as the following:
This will not work with the current way <Immutable>.To<InheritedType>() works. Perhaps those methods should be moved to extension methods, but then CreateWithIdentity(...) would have to become public and always generated.
The text was updated successfully, but these errors were encountered:
@jviau: with regard to your design that NodeA might be extended by a 3rd party, is that really a scenario? Your design seems to be each tree has exactly one NodeA, so with your proposed design, only one person can determine what NodeA-derived type to instantiate. That doesn't sound like it's consistent with the idea of many CPS extensions setting arbitrary values on these. Or is it just the tree provider (or subtree provider) that gets to determine what extra data to store?
@AArnott this scenario is mostly for subtree providers, where a customer can have the subtree provide an extended implementation of NodeA if they deem it necessary.
Having type hierarchies across multiple files and projects will allow for extensible designs when the base class is in a consumed library. This would allow for something such as the following:
Project A
Project B
This will not work with the current way
<Immutable>.To<InheritedType>()
works. Perhaps those methods should be moved to extension methods, but thenCreateWithIdentity(...)
would have to become public and always generated.The text was updated successfully, but these errors were encountered: