> (1) Yeah, that's why I said to put the decoding methods into the > destination object. That way this kind of decoding can be used by > anyone.
Right, but, as a caller, setFoo() makes more sense to me than bxmlFromString(). But maybe I misunderstand the intent. It might help to see a practical example. > (2) Enum require specialised handling because some of the methods on > them are generated by the compiler, so they require some finicky > reflection, but it's certainly doable (basically requires using > reflection to call valueOf on the correct enum subclass) I couldn't get it to work, but maybe you can. I'm definitely not opposed to adding enum support directly to BXMLSerializer if it is possible, but I'm not convinced that we can (or want to) get away from setter overloads altogether (for other types).
