It seems like the general functionality (i.e. GWT.isLiteral()) ought to be
implemented at the same time as method cloning. That's what makes me excited
about the whole thing. Otherwise, at least for me, it's hard to wrap my head
around how you could usefully emit different code for the same method for
different call sites. Maybe I'm missing something.
A similar but related concept that I think would be the best first step is a
parameter annotation called @MustBeLiteral. Then any method could become a
"GWT.create()" indirectly because you'd be able to write:
public <T> T myFactory(@MustBeLiteral Class<? extends T> classLit) {
T t = GWT.create(classLit);
// do some stuff to tweak the t instance
return t;
}
That seems way useful and perhaps the easiest of everything to implement.
On Mon, Apr 27, 2009 at 9:30 AM, Joel Webber <j...@google.com> wrote:
> Cool, I had no idea GCC provided that information. I won't claim to be one
> of the compiler gurus, but this sounds pretty feasible to me, and to Ray's
> point, might be a useful way of loosening the GWT.create() magic a bit.
>
> @Lex, Scott: What do you think? Is this relatively easy and useful?
>
> On Mon, Apr 27, 2009 at 4:49 AM, Vitali Lovich <vlov...@gmail.com> wrote:
>
>> Yeah, probably from a compiler's perspective, the value check may be more
>> complicated (the value may only be available after the AST stage depending
>> on when optimization is done)
>>
>> It can possibly bloat the resultant code (since I believe you may have to
>> build different implementations of each function and you may get overhead,
>> even if you inline). However, I think this might be an OK tradeoff since
>> the assumption would be that you are optimizing for speed as opposed to size
>> if you use something like GWT.isLiteral.
>>
>>
>> On Mon, Apr 27, 2009 at 3:45 AM, Ray Cromwell <cromwell...@gmail.com>wrote:
>>
>>>
>>> +1
>>>
>>> I suggested a similar feature a few days ago privately, I called it
>>> GWT.isLiteral(), since the underlying check is if its an AST literal
>>> in the compiler, although in my example, you can't do value
>>> comparisons, just assertions on the literal. The value checks would be
>>> done via traditional operators.
>>>
>>>
>>>
>>>
>>> On Mon, Apr 27, 2009 at 12:33 AM, Vitali Lovich <vlov...@gmail.com>
>>> wrote:
>>> > Kinda like with GCC, allow detection of constant values (i.e.
>>> > __builtin_constant_p). This way, you could do something like
>>> >
>>> > void addParameter (HashMap h, int size, String key, Object value)
>>> > {
>>> > if (GWT.isConstantValue(h, null)) {
>>> > if (GWT.isConstantValue(size, 0))
>>> > size = 10;
>>> > h = new HashMap(size);
>>> > }
>>> > h.put(key, value).
>>> > }
>>> >
>>> > & you could have the performance of
>>> >
>>> > void addParameter (HashMap h?, int size?, String key, Object value)
>>> >
>>> > as if you wrote overloaded methods without needing to write several
>>> > different methods that just supply default values back & forth.
>>> Sometimes,
>>> > it's also possible to use a better algorithm if parameters have a known
>>> > constant value.
>>> >
>>> > >
>>> >
>>>
>>>
>>>
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
