On Wed, Dec 3, 2008 at 5:27 PM, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: > Adam Winer <[EMAIL PROTECTED]> writes: > >>OK, but can you defend SHINDIG-759 as you just filed? Once the >>XStream code has been fixed, why should @ImplementedBy be removed? >>How does this patch make things better? IMO, it makes things *far* >>worse. Either a developer uses this new DefaultGuiceModule and >>DefaultOpenSocialObjectsModule or you don't. If the developer does, >>their life is unchanged. If the developer doesn't, their code breaks >>every time we add a new entry to one of these modules, which means >>their life is worse. > > It seems that you believe, that every shindig release (there is no > release yet, right?) must be drop-in compatible to the previous one.
As much as is sensible. That's critically important, otherwise your users stop upgrading. This has been true on every library I've ever worked on. > I very much support your suggestion to pull out all bindings that are > related to setting up a sample server into its own package. Agreed, if they're purely sample code that should not be used in production. > IMHO there > should be no Guice Module in gadgets, common and social-api. That doesn't follow. It's flat out wrong. > And yes, I fully expect people embedding Shindig to read documentation > that says what is wireable and how it must be wired. And use the > sample container as a guideline on how to do it. The less documentation they need to read, the less things they need to get right, the better. > SHINDIG-759 is as it is mainly to be as closely to the current code > structure as possible. > > If you are an early adopter using the svn version of Shindig directly, > you can't expect your code to not break when you do "svn up". > > People who don't want to dig into the inner workings of Shindig, > probably can get away with using the sample container code and > adapting this, thus never directly diving into the actual inner > workings of the code. No one should EVER have to "adapt" a sample container (copy, paste, keep modifying as you upgrade) if there's a better way. And there is. > But using @ImplementedBy to provide "default implementations" and > sprinkle these definitions all over the code base is plain wrong. It > is as wrong as reflecting on classes and overload the semantics of the > annotation to "find my implementation class". No, it's not even close to being "as wrong". The XStream code is clearly wrong, without ambiguity. @ImplementedBy is a judgement call and a gray area. > Do it right or don't do > it at all. And at the moment, it is not done right. > > Ciao > Henning > > -- > Henning P. Schmiedehausen - Palo Alto, California, U.S.A. > [EMAIL PROTECTED] "We're Germans and we use Unix. > [EMAIL PROTECTED] That's a combination of two demographic groups > known to have no sense of humour whatsoever." > -- Hanno Mueller, de.comp.os.unix.programming >
