Steve Maine put his ginormous brain to use in whipping up a late-night answer to my troubles in "getting" Prothon.

Thanks, Steve :) Good stuff.

After reading Steve's article, I've decided that for my own uses, Prothon would be:

1) Fun at home

2) Dangerous at work

One quote from Steve's post that has me thinking a bit, though, is the following:

The inherent extensibility and open content model of XML makes coming up with a statically typed representation that fully expresses all possible instance documents impossible. Thus, it would be cool if the object representation could expand itself to add new properties as it parsed the incoming stream.

I can see how this would be cool in a "Hey, that's cool" sense, but I don't see how it would help me at work. I fully admit that I might just be stupid, but I'm honestly having a hard time seeing the benefit. Right now, I'm grabbing XML in the traditional fashion of providing the name of the node that I want as a string key, and it seems to be working just fine.

However, there's more that I don't get.

If properties are being dynamically added to an object at runtime, then how are those properties accessed? Do you also have to modify the consumer? Otherwise, how would it know that new properties had been added to an object and that they could be called?

Or, would the properties be tagged with some sort of metadata that tells the caller how to handle the new properties? If that has to happen, then I'm really not seeing the benefit. It sounds like more work would have to be done just to know that your code is making use of properties instead of string keys to deal with XML.

It sounds like the benefits would really just be in automation of a process. If that's the case, then why should we care how it's done? From my point of view, properties are a design-time convenience for coders. At runtime, I don't care how data is being accessed.

Am I just really thick? I want to get this, but I feel like I'm missing something big.