Your thinking makes perfect sense, but if I recall correctly, there's an implementation detail that prevents this exact scenario (that is, generating JSO impls of interfaces). It's a feature we haven't gotten to yet, and it won't make it into 2.0, sadly.
On Nov 19, 7:09 am, Brendan <[email protected]> wrote: > Now that a javascript overlay can inherit an interface, so long as it > is the only JSO that does, is there anything preventing the use of > Generators to define new JSOs? > > The use case I'm thinking of would be a javascript object that is > partially (or entirely) defined by browser specific fields and methods > (Moz*(), Webkit*(), etc). Since only one JSO would be generated per > permutation, this would guarantee that only one JSO was implementing > that interface for any particular permutation. > > While this can be accomplished by a wrapper class with overridden > methods, the boilerplate code (even auto-generated), is lengthy and > annoying to maintain for objects which need only a few methods > overridden. And more people than me must find the spread of > "impl" (impl-itis?) and decorator classes grating on a code-aesthetics > level. > > Does the compilation sequence still prevent this? Has anyone come up > with a better workaround? -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=.
