> - Instantiating a final class with no public no-arg constructor > (UnfriendlyPOJO example) > - Instantiating an immutable object (essentially the same as above) > - Instantiating objects via a 'Builder' style pattern (similar to the above) > - Retrieving objects via a factory (similar to previous items)
You are correct that none of these are directly supported, but you can accomplish them by subclassing BXMLSerializer and overriding newTypedObject(Class<?>). > - Ability to return a different class to the one that would otherwise > be instantiated (see the PasswordInput & TableBuilder examples) > (This is similar to the first batch, but stresses a key concept) You could use newTypedObject() to achieve this, but it seems like it would be really confusing. A big part of the value of BXML (in my opinion) is its opaqueness. Returning a different object than the one specified goes very much against that. > - Hiding attribute ordering restrictions from the end user (ListView example) I must have missed this example so I'm not entirely sure what the use case is, but the order in which BXML's attributes are processed is quite deterministic. Attempting to circumvent it is more likely to cause confusion than anything else. > - Ability to 'create' 0 or >1 objects > See the conditional BXML inclusion example for when returning 0 items > might be useful. Again, this is by design. A serializer returns a single object. If you want to return multiple objects, have your serializer return a collection. >>> The fact that it is a small, backwardly compatible change >> FWIW, I don't see this as a small change. > Obviously I respect your personal opinion on the size of the change, > and know that you have far more experience with BXMLSerializer than I > do. Is there perhaps some fundamental problem that you can see but I > might be overlooking? It's not the literal size of the change (i.e. number of lines) but the nature of the change that I'm not really in favor of. From my perspective, many of the changes you propose are simply not in line with the intent of BXML. >>> Because it is such a small change, and limited to BXMLSerializer, it >>> would be easy to just push this into a tiny Apache Extras project as >>> Sandro suggested. >> >> You can do this of course, but you'd basically be forking the code and >> opening the door to future incompatibility. > That is a little melodramatic considering it potentially concerns just > a few changes in a single class. It's not melodramatic - it's just accurate. If you copy a class and modify it without pushing those changes back into the main source tree, you have forked the code. > And anyway, is there another option if it doesn't fit or belong with > Pivot proper? No, probably not. G
