On Wed, Aug 3, 2011 at 2:36 PM, <jbrosenb...@google.com> wrote:
> On 2011/08/03 20:03:28, rjrjr wrote:
>
>> Oh, and putClientData seems like a better name.
>>
>
>
> Done
>
> On Wed, Aug 3, 2011 at 1:02 PM, Ray Ryan <mailto:rj...@google.com>
>>
> wrote:
>
> > I'm still not crazy about having addClientData() and getClientData()
>>
> on
>
>> > separate objects. It seems to me that you've violated your own
>>
> principal
>
>> > that the GeneratorContext should be the only object that has to get
>>
> passed
>
>> > to the generator's helpers.
>> >
>> > Can addClientData() move to the context? That would require
>>
> getClientData()
>
>> > to be able to retrieve both cached and freshly added data. Is that
>> > practical? Sounds like it would be hugely convenient.
>> >
>>
>
> I'm not sure I see why it makes sense for it not to be part of the
> cached result. It is indeed closely associated specifically with that
> previously generated result. By keeping it as part of the cachedResult,
> it makes one less thing that needs to be passed around internally to the
> generator (only the context needs to be passed around).
>
No, I have two things to pass around. I have to pass around generatorContext
to allow helpers to fetch cached data, and I also have to pass around
something to allow helpers to post new cached data.
That is, in the current scheme I have to write something like:
generateIncrementally(TreeLogger logger, GeneratorContext context, String
typeName) {
Map<String, Serializable> helperCachedData;
new HelperOne(context, helperCachedData).run();
new HelperTwo(context, helperCachedData).run();
RebindResult result = new RebindResult(USE_WHATEVER, typeName + "Impl");
for (Map.Entry<String, Serializable> entry : helperCachedData) {
result.putClientData(entry.key, entry.value);
}
return result;
}
instead of
generateIncrementally(TreeLogger logger, GeneratorContext context, String
typeName) {
new HelperOne(context).run();
new HelperTwo(context).run();
return new RebindResult(USE_WHATEVER, typeName + "Impl");
}
Further, my helpers have to look in two places for cacheable data generated
by an upstream helper.
> The context is specific to the currently running generator environment,
> and generally gets reset for each generator invocation. Adding more
> data to the context requires more api and more things for the context to
> keep track of (currently it just keeps track of a CachedRebindResult
> object, which it would still need to do).
>
> Maybe there's a better name than "clientData" here, suggestions? It's
> specific to a generator run invoked that was invoked with the same
> rebind rule and requested type name as are currently in effect. But
> it's historical data, and in fact is not essential at all to the
> generator (if it's not there, the generator will run to completion).
>
>
> http://gwt-code-reviews.**appspot.com/1468804/<http://gwt-code-reviews.appspot.com/1468804/>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
