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: > > 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 biggest method. The entire class is only 1,749 bytes, and the entire > java.lang (for this project) is 10,535 bytes. > > Adding String.format, once, using only %s to substitute in strings easily, > would add 30%. > > On Mon Feb 09 2015 at 8:26:49 AM Benjamin DeLillo <[email protected] > <javascript:>> wrote: > >> 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 with Ray at GWT.Create >> 2013 and his take on this was that although String.format was originally >> excluded from GWT for codesize reasons, that in today's browser/internet >> ecosystem the hit would be acceptable. >> >> I do agree that any less than complete implementation needs to have as >> obvious a failure mode as possible for when it diverges from String.format >> canon, and must be well documented and easy to find. How do other JRE >> emulation implementations handle this kind of divergence? Or do they avoid >> such divergence at all costs? >> >> >> >> On Monday, February 9, 2015 at 5:13:38 AM UTC-5, Daniel Kurka wrote: >> >>> Hi Benjamin, >>> >>> thanks for reaching out to us. Answers are inline. >>> >> >>> On Sat, Feb 7, 2015 at 5:31 AM, Benjamin DeLillo <[email protected]> >>> 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 think supporting the entire java spec is impossible since we do not >>> have Locale working (for codesize reasons). So we would need to discuss >>> what a good subset would be >>> >>> >>>> Would an implementation lacking the Date/Time conversions be acceptable? >>>> >>>> Would an implementation that wraps sprintf.js be acceptable (if the >>>> licensing is compatible)? https://github.com/alexei/sprintf.js >>>> >>>> I briefly skimmed the lib and it seems huge, so I am inclined to say >>> no. In general you have to think about that any application will have the >>> hit of that method in their app as soon as they call String.format one time >>> in their code base. >>> >>> >>>> >>>> What about a minimal positional substitution implementation and nothing >>>> more? >>>> >>>> >>> Right now any code that relies on String.format will not compile in GWT >>> and thus give the author a clear indication of having a problem. Once we >>> support a subset this compile error might be gone, but we will be >>> introducing runtime errors for not supported features rather than compile >>> time errors. >>> >>> One could try to deal with these (and this is bad from the compiler >>> perspective), by looking at the parameters of String.format and only allow >>> statically resolvable arguments for the format String that are supported by >>> the emulation, but this is a very tight coupling of compiler and lib that >>> we do not want in the compiler. >>> >>> So if we want to do a minimal support of String.format these are the >>> kinds of problems we need to discuss. >>> >>> >>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "GWT Contributors" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to google-web-toolkit-contributors+unsubscribe@ >>>> googlegroups.com. >>>> To view this discussion on the web visit https://groups.google.com/d/ >>>> msgid/google-web-toolkit-contributors/bc6afdc0-eb87- >>>> 4815-b076-6db912f8f94c%40googlegroups.com >>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/bc6afdc0-eb87-4815-b076-6db912f8f94c%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Google Germany GmbH >>> *Dienerstr. 12* >>> *80331 München* >>> >>> Registergericht und -nummer: Hamburg, HRB 86891 >>> Sitz der Gesellschaft: Hamburg >>> Geschäftsführer: Graham Law, Katherine Stephens >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "GWT Contributors" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-web-toolkit-contributors/fa54c87b-c54b-4c8d-87f9-ff234c04cc35%40googlegroups.com >> >> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/fa54c87b-c54b-4c8d-87f9-ff234c04cc35%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/489b64c6-90e1-4ae3-9fc4-10d27622b6ac%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
