Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?

2015-03-05 Thread Jens
> > I'm curious if anyone knows, what is 10KB, percentage wise, vs the size of > the average GWT project? I don't know if the one I work with is average or > unusual weighing in at 7.2MB. I'm wondering if my perspective is skewed. > I guess that question is irrelevant. You will always have smal

Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?

2015-03-05 Thread Benjamin DeLillo
I'm curious if anyone knows, what is 10KB, percentage wise, vs the size of the average GWT project? I don't know if the one I work with is average or unusual weighing in at 7.2MB. I'm wondering if my perspective is skewed. On Monday, February 9, 2015 at 11:19:39 AM UTC-5, Colin Alworth wrote: >

Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?

2015-02-09 Thread 'Goktug Gokdogan' via GWT Contributors
Also Daniel's point about compile-time errors are important. That could be potentially handled with error-prone checkers. On Mon, Feb 9, 2015 at 9:39 AM, Goktug Gokdogan wrote: > > > On Fri, Feb 6, 2015 at 8:31 PM, Benjamin DeLillo > wrote: > >> For an implementation to be accepted would it hav

Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?

2015-02-09 Thread 'Goktug Gokdogan' via GWT Contributors
On Fri, Feb 6, 2015 at 8:31 PM, Benjamin DeLillo wrote: > For an implementation to be accepted would it have to conform to the entire > Java Formater spec? > http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html > > We may have 'known' limitations. > Would an implementation lacking

Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?

2015-02-09 Thread Benjamin DeLillo
Unfortunately the design of the JRE is such that a large amount of complexity is exposed through what is an otherwise fairly slim class, which I'm sure just punches a hole out to java.util.Formatter to do the heavy lifting anyway. Would having Formatter.format instead of String.format make thin

Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?

2015-02-09 Thread Colin Alworth
Its not that 3k is huge, its that it would be (to a developer, accustomed to GWT's policies) massively larger than normally expected for built-in methods. Just ran SOYC on a project (OBF but not closure), and the largest java.lang.String method is 466 bytes, greater than twice the size of the next

Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?

2015-02-09 Thread Benjamin DeLillo
Dan, Thanks for the response. sprintf.js is 3kB minified and 7.5kB uncompressed weighing in at just under 200 LoC, you mention this would be too big. Just how small would an implementation have to be to be acceptable? How large are other JRE emulation implementations by comparison? I spoke wit

Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?

2015-02-09 Thread 'Daniel Kurka' via GWT Contributors
Hi Benjamin, thanks for reaching out to us. Answers are inline. On Sat, Feb 7, 2015 at 5:31 AM, Benjamin DeLillo wrote: > For an implementation to be accepted would it have to conform to the entire > Java Formater spec? > http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html > > I

[gwt-contrib] What constitutes an acceptable emulated String.format implementation?

2015-02-07 Thread Benjamin DeLillo
For an implementation to be accepted would it have to conform to the entire Java Formater spec? http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html Would an implementation lacking the Date/Time conversions be acceptable? Would an implementation that wraps sprintf.js be acceptabl