For what it's worth, I like the moniker class idea best. Staying type
safe, IMHO, is always a good thing.
With regards to the downside John Tamplin mentioned (multiple runAsync
calls in one class), why not consider that a feature? Since the
original idea of naming the runAsync call is to allow for prefetching,
putting several runAsync class in one class could allow you to easily
prefetch a particular large chunk of code. If you find you don't want
to prefetch, nothing happens and little pieces download each time.
If you put this together with Bruce's class hierarchy idea, you might
be able to provide a single name to call to fetch the entire
application. This could be integrated with a "Go offline" button for
an easy download everything call.
With this idea of using moniker classes, would you still provide the
class name as a parameter to runAsync or would the compiler just
assume the name of the runAsync call is the name of the class it lives
in? If you allow providing a class name, would you check it's the name
of the class the call is in? I like the automagic naming using the
class name.
Best regards,
--
Arthur Kalmenson
P.S. Naming to allow for prefetching is an awesome idea. I was
thinking how one would prefetch components while watching the GWT
Google I/O sessions. This would definitely make going offline easy
too.
On Wed, Jun 24, 2009 at 10:55 PM, Cameron Braid<came...@braid.com.au> wrote:
> All good points.
>
> Would interfaces be supported as well ?
>
> Are there any dangers of allowing arbitrary classes (or interfaces) to be
> used as monikers ?
>
> i.e from your example, would there be anything wrong with using
> EmailCompositionView.class as the moniker ?
>
>> void onComposeButtonClicked() {
>> GWT.runAsync(EmailCompositionView.class, new AsyncCallback() {
>> public void onError(Throwable e) { ... }
>> public void onSucess() {
>> new EmailCompositionView().activate();
>> }
>> });
>
> I guess the compiler would have to verify that each call to runAsync uses a
> unique moniker - is there anything else ?
>
> Must the moniker class exists in your own module ?
>
> Would you only allow leaf classes to be used as monikers, i.e. could you use
> OfficeSuiteSplitPoint.class as a moniker ?
>
> Cam
>
> 2009/6/25 Bruce Johnson <br...@google.com>
>>
>> Four additional arguments in favor of using "split point moniker classes"
>> is that they
>> 1) are easier to find within an IDE (i.e. "Show References" in your IDE
>> from a moniker class declaration would show you the associated runAsync
>> call),
>> 2) can take advantage of inheritance as a way to group split points into
>> meaningful families (which would make them more easily browsable and
>> navigable in javadoc and in an IDE),
>> 3) can be javadoc'ed to explain what they do, and
>> 4) they could potentially be augmented with additional hints to the code
>> splitter using annotations (these are a stretch; Lex might be able to think
>> of more realistic example annotations)
>>
>> /**
>> * Split points in this hierarchy relate to the email functionality within
>> the office suite.
>> */
>> class EmailSplitPoint extends OfficeSuiteSplitPoint {
>> }
>>
>> /**
>> * This split point carves out all heavyweight functionality related to
>> composing emails,
>> * most importantly, the rich text area clases.
>> */
>> @ProhibitPreloading
>> @MustBeExclusiveFragment
>> class EmailCompositionSplitPoint extends EmailSplitPoint {
>> }
>>
>> // ... elsewhere ...
>>
>> void onComposeButtonClicked() {
>> GWT.runAsync(EmailCompositionSplitPoint.class, new AsyncCallback() {
>> public void onError(Throwable e) { ... }
>> public void onSucess() {
>> new EmailCompositionView().activate();
>> }
>> });
>> }
>>
>> On Wed, Jun 24, 2009 at 6:50 PM, Cameron Braid <came...@braid.com.au>
>> wrote:
>>>
>>> Each of these different libraries would be enclosed within a unique GWT
>>> module therefore when you refer to the split point name, can't you just use
>>> the module name + split point name ?
>>>
>>> in module ThirdParty :
>>>
>>> GWT.runAsync("one", new RunAsyncCallback() { ... });
>>>
>>> in MyModule :
>>>
>>> GWT.runAsync("one", new RunAsyncCallback() { ... });
>>>
>>> <extend-configuration-property
>>> name="compiler.splitpoint.initial.sequence" value="MyModule#one" />
>>> <extend-configuration-property
>>> name="compiler.splitpoint.initial.sequence" value="ThirdParty#one" />
>>>
>>> Cam
>>>
>>> 2009/6/25 Lex Spoon <sp...@google.com>
>>>>
>>>> On Wed, Jun 24, 2009 at 2:15 PM, Lex Spoon<sp...@google.com> wrote:
>>>> > Overall, unless I missed something,
>>>>
>>>> Okay, Bruce pointed out a new constraint to me: if different libraries
>>>> name their runAsync calls, then we want to able to refer to those
>>>> calls reliably even if different libraries choose the same name. This
>>>> isn't an issue immediately, but it likely will be in the future.
>>>>
>>>> Thinking about libraries, I would add another constraint: we don't
>>>> want libraries to have to expose their implementation. Library
>>>> writers should ideally be able to document a named runAsync call
>>>> without exposing the precise arrangement of their internal classes.
>>>>
>>>> After some discussion at the office, a tweak to option 4 fixes things
>>>> up handily. Instead of passing in a string to the method, act like a
>>>> Java framework and require passing in a class literal. A typical use
>>>> in application code would pass in the enclosing top-level class:
>>>>
>>>> package org.foodity.impl;
>>>> class Cookies {
>>>> ...
>>>> GWT.runAsync(Cookies.class, new RunAsyncCallback() { ... });
>>>> ...
>>>> }
>>>>
>>>> A library writer could instead specify a public class, so as not to
>>>> expose their internal factoring.
>>>>
>>>> A user of the name in a gwt.xml file would use the fully qualified
>>>> version:
>>>>
>>>> <extend-configuration-property
>>>> name="compiler.splitpoint.initial.sequence"
>>>> value="org.foodity.impl.Cookies" />
>>>>
>>>> A user in another Java file would use imports to make the name short:
>>>>
>>>> import org.foodity.impl.Cookies;
>>>>
>>>> RunAsyncQueue.startPrefetching(Cookies.class);
>>>>
>>>>
>>>> Thoughts? The main downside I know of is the one John Tamplin has
>>>> pointed out: if there are multiple runAsync calls within a single
>>>> class -- as sometimes happens -- then the programmer has to code up
>>>> some new classes that will only be used for naming. Can we live with
>>>> that?
>>>>
>>>> Lex
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
