When I iterate over my list of ContentNodes, I would like to be able to figure out if I'm looking at a ContentNode or a UrlNode. When I print out the object, it tells me that it is a <Component: roSGNode:UrlNode> but when I print out type(object) it tells me that it's an roSGNode.
Assuming that we can all agree that testing (object.feed_url <> invalid) would be cheating, how can I determine the subclass of an roSGNode?
What I would do here is check the last few characters of the url itself. If it's an mp4 then it's progressive video, mp3 audio, hls, or html or php or asp. That way you aren't extending the content node which has quite an impact on larger content sets. When you do need to have a few extra fields, it's preferable (IMO) to use existing fields you are not utilizing like "album".
That's an answer I was not expecting. I see that you've made over 2500 posts, so I don't quickly discard your opinion. That said, I would like to benefit from your experience by digging a little deeper.
What's your confidence level regarding the performance impacts of subclassing in BrightScript? Is there a number of child objects where it starts to become problematic?
Is the impact lessened, increased or similar if you use addField() to add a slot dynamically vs formally subclassing via an additional XML file?
Does BrightScript have profiling mechanisms to test these hypotheses on working hardware with incrementally larger iterations? Usually, these sorts of problems have a curve.
Ultimately, my reason for asking is deeper understanding. As I suggested at the end of my post, I could also just test object.feed_url <> invalid and move on, but that feels gross and leads to special cases in your codebase whereas most languages have a mechanism for reflecting on polymorphic class meta-information. A urlNode is a contentNode but the opposite is not necessarily true.