Greg, I have been away from my desk for the last 2 days, so apologies for the delay, but this is the first chance I have had to reply.
Firstly, I want to clarify that my desire for functionality is the driver here, and that I have no special attachment to the specifics of the proposal. Any other simple method to achieve the same things would be welcomed with open arms. Replies/questions in-line. On 5 July 2011 21:59, Greg Brown <gk_br...@verizon.net> wrote: >> You mention concerns, but do you see any value in i? Whether in my examples >> or in other areas? > > If the same thing can be accomplished via existing means (which, based on > your examples, seems possible), then I don't personally see a strong case for > it. Unless I am missing something, at least some of the provided examples *cannot* be accomplished via existing means (whether by design or otherwise). Please correct me if I am mistaken, as I can think of valid uses for all of the following, but don't know how to achieve any with BXML. - 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) - 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) - Hiding attribute ordering restrictions from the end user (ListView example) - Ability to 'create' 0 or >1 objects See the conditional BXML inclusion example for when returning 0 items might be useful. A dynamic GUI creation Transformable example might wish to return multiple individual Components rather than a single parent Container. >> 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? I don't imagine for a second that this is a panacea, but it offers many options. > I also don't like the inconsistencies it would create (as outlined in my > previous email). What inconsistencies did you mean? You mentioned the use of a non-Pivot Collection, but that could clearly be changed to a Pivot one or simply Object[]. Are you perhaps referring to the intent of the Serializer interface? And that the result of 'creating' an item in BXML would depend on whether the element represents a traditional Java bean class or a Transformable implementation? >> 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. And anyway, is there another option if it doesn't fit or belong with Pivot proper? Chris
