I think there's a couple of issues. The lang wrapper classes for
int/double/etc pull in a lot of compiler cruft, because the compiler doesn't
currently know how to de-box these wrappers when it can. Last time I looked,
Java Enums add a lot of bloat to the compiled output, not just at the
definition site, but from anything that references them, you get clinit
calls. I'm not saying enums are always bad, but if you're going to go wild
creating lots and lots of them, be advised there will be bloat (somewhat
fixed by Lex's eager-clinit pruning patch).
Third, the reliance on method names for the properties would make some
patterns really painful. Just try to write a method that clears all styles
using only these methods, or clears any subset. A very natural thing to do
would be to want to write something like this:
public void clearStyle(Set<Property> currentStyle) {
for(Property p : currentStyle) {
clear(p);
}
}
public void applyStyle(Map<Property, Value> style) {
for(Entry<Property, Value> entry : style.entrySet()) {
set(entry.getKey(), entry.getValue());
}
}
And then store multiple styles in your app, letting users customize them via
a UI dialog. Doing this with a bunch of methods would lead to a really big
hardcoded dispatch function.
I'm not completely opposed to a bunch of individual methods, since their
cost if zero if they are never called, but IMHO, what many people really
want is a type-safe equivalent to style.setProperty().
-Ray
On Mon, Mar 30, 2009 at 9:29 AM, Ray Ryan <[email protected]> wrote:
> Looking at this more closely now, its a pretty chatty API.
>
> What's with all the "Map because Enum.valueOf does not work in GWT" stuff?
> That's untrue, yes? It's not as efficient as it should be (
> http://code.google.com/p/google-web-toolkit/issues/detail?id=2046), but I
> hate polluting our API due to a compiler flaw, especially for such tiny
> lists of values.
> All these "clearFoo" methods are really noisy. I hate to encourage null as
> a parameter value, but I'd actually rather see setFoo(null) than five
> thousand clear*() methods. An alternative would be to have an UNSET value in
> each enum, but that seems nearly as cumbersome as all these clear methods.
>
> We'd also have to change the numeric ones from int and double to Integer
> and Double--is the compiler good about that?
>
> The getBlahAsString methods are more noise. The appropriate properties
> should implement String asString() (leaning on toString() in a public api is
> a bad habit to encourage). Perhaps they can implement a StringBasedStyle
> interface defining that method.
>
> rjrjr
>
> 2009/3/29 Freeland Abbott <[email protected]>
>
>> As we'd discussed earlier, here's a cut at giving our Style class explicit
>> accessors for the various property attributes.
>>
>> (Not that it matters, but the only thing I *really* hate about our
>> checkstyle alphabetization is that it splits clear/get/setFoo apart. C'est
>> la vie.)
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
