StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
12414242
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
6
CommunityOwnedDate
CreationDate
2012-09-13T20:25:38.873
FavoriteCount
0
LastActivityDate
2012-09-17T20:06:20.217
LastEditDate
2012-09-17T20:06:20.217
LastEditorUserId
181460
OwnerUserId
181460
ParentId
12413080
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
Your problem might be more clear if you used explicit types instead of <code>var</code>. Declaring a variable with <code>var</code> does not make the variable type dynamic, it just makes the compiler figure out what specific type the variable needs to be (and it can be dangerous because you don't know as clearly what type it determines). So, having declared variables with a specific type (whether you know what that type is or not), you can then only access what that declared type knows unless you cast it appropriately. I think in the end there is no way to accomplish exactly what you want without specifying a type at some point as a type argument (in angle-brackets) or an explicit cast. You apparently want to convert a non-specific iherited/implementing type to a handy specific type, but that requires telling the complier a specific type for it to become. But you may get closer to what you'd like by changing your approach. What if you used a non-generic <code>IHierarchy</code>? (also correct the spelling) If... <pre><code>public inetrface IHierarchy : IHierarchyItem { IHierarchy Parent { get; set; } IList<IHierarchy> Children { get; set; } } </code></pre> ...then any <code>IHierarchy node</code> variable could access <code>node.Parent</code> and <code>node.Children</code>... and also <code>node.Id</code> and <code>node.Title</code> because the <code>IHierarchyItem</code> is required and thus is known to <code>IHierarchy</code>. This approach would handle the hierarchy aspects easily and allows polymorphism in your <code>WorkContext.Current</code> (etc) return values, but it would require explicit casting from there to access anything specific to a class outside of the defined members of <code>IHierarchy</code>. It's not clear how much of an issue that might be for your purpose. You could also perhaps layer a generic <code>IHierarchy<T> : IHierarchy</code> on top of it to allow handling by a specific type without further casting. You might have to define one or both interface members explicitly rather than implicitly (in implementing classes) to avoid name collisions on the properties without generic type arguments. EDITED TO ADD: For example, something like: <pre><code>public interface IHierarchy<T> : IHierarchy // Implies IHierarchyItem where T : IHierarchy<T> { ... } // As you had it. </code></pre> Then in your implementation class: <pre><code>public SiteMapNode : IHierarchy<SiteMapNode> // Implies IHierarchy { private SiteMapNode _Parent; private IList<SiteMapNode> _Children; // Implicit implement of IHierarchyItem and members of SiteMapNode itself. int Id { get; set; } string Title { get; set; } // Implicit implementation of IHierarchy<SiteMapNode> members // These are also members of SiteMapNode itself. SiteMapNode Parent { get { return _Parent; } set { _Parent = value; } } IList<SiteMapNode> Children { get return _Children; set _Children = value; } // Explicit implementation of IHierarchy members // The interface prefix is required to distinguish these from the // type-specific members above to declare different return types. IHierarchy IHierarchy.Parent { get { return _Parent; } // Might need (IHierarchy) cast set { Parent = (SiteMapNode)value; } } IList<IHierarchy> IHierarchy.Children { get { return _Children; } // Might need (IList<IHierarchy>) cast set { _Children = (IList<SiteMapNode>)value; } } } </code></pre> (Or get fancier and have more sanity-checking in the IHierarchy implementations.) I might have missed some other explicit casting needed also; I'm not positive that the lists can be cast directly in this way, but I think by having IHierarchy<T> inherit IHierarchy it ensures that SiteMapNode is a valid IHierarchy and thus the elements of the list work for both list types). If that list casting doesn't work, you may have to create a custom generic collection class to manage the children as both unspecified IHierarchy and as generic IHierarchy<T>. For performance reasons you may want to add <code>IHierarchy _CastParent;</code> and <code>IList<IHierarchy> _CastChildren;</code> members and save the unspecified IHierarchy casts of these objects to avoid having to repeatedly recast them. I suggest that you always cast to the specific types (when setting from the unspecified) but you might defer casting from the specific types to the unspecified references until they are actually needed. Now, all that, of course, is only if this extra complexity is actually helpful for what you need. It would allow you to handle the hierarchy objects as unspecified types (which might be cast more specific later, or never) or as specific or generic hierarchy types which would preserve their type knowledge for handling without casting. You would still need to cast to a specific type at some point to convert from an unspecified IHierarchy return type if you wanted to then handle them as the type-specific hierarchy.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POC# Generic Inheritance Issue with Base Library
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USRob Parker
UserOwnerUserId
1. USRob Parker
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POC# Generic Inheritance Issue with Base Library
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.