[Webkit-unassigned] [Bug 18994] LANG/LC_ALL influences the result of element.style.opacity

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=18994





--- Comment #118 from Gavin Barraclough <barraclough at apple.com>  2010-10-11 14:18:53 PST ---
> > In a trivial implementation all arguments would be 'const String&'s, and String::cat() could just wrap StringBuilder (rather than using StringBuilder directly) such that the internal implementation can be improved later.
> Excellent, that would be really handy. Do you have already started coding this?

I haven't, but this should be pretty trivial:

String String::cat(const String& s1, const String& s2)
{
    StringBuilder builder;
    builder.append(s1);
    builder.append(s2);
    return builder.toSting();
}

String String::cat(const String& s1, const String& s2, const String& s3)
{
    StringBuilder builder;
    builder.append(s1);
    builder.append(s2);
    builder.append(s3);
    return builder.toSting();
}

And so on for more more arguments.  One problem, I think StringBuilder is currently in WebCore, not WTF, if should move to wtf/text with the rest of the string code.  (I have a patch I'm working on to rewrite StringBuilder, so we may conflict a little there, but if you're just moving the code should be easy to resolve for whoever lands second!)

> > A better implementation we could make the arguments to cat be templated such that data could be added to the string without converting all arguments to String format first.  We already have this implemented in JavaScriptCore (and since we're close to unifying the string implementations we could ultimately fully share this code), in a set of methods called makeString.  These allow an arbitrary mix of UStrings and plain C-strings to be concatenated together, without first converting the C-strings to Strings.
> I see, seems like it would be very wise to share the code in wtf/.

*nod.  The only reason this code is currently JSC specific is because it works on UStrings not Strings, and the difference in String::number & UString::number is one of the few remaining issues to resolve before we can remove UString, so this change should get us closer.

> > * The rules for number to String conversion are different in different web technology specifications.
> > * SVG has an uncommon requirement, in that it never overflows to an exponential representation.
> > * HTML5 and ECMAScript agree on number-to-string conversion (in that the HTML5 spec requires ECMAScript conversion).
> SVGs requirement is uncommon right, but we don't want this for the render path dumps, we definately want exponential numbers in the SVG DRT dumps.

Ah I see, yes okay.  so for these cases the HTML5/ECMAScript behaviour should probably be okay?

> > We should probably add a different method specifically for SVG's number-to-string behaviour.  This could be a free function within the svg code, taking a double and returning an String.  This method should also be able to use DecimalNumber in its implementation, but would likely chose to always call toStringDecimal, rather than toStringExponential.
> I'm not sure if we need a special SVG method, I'd rather prefer an enum that describes how the number conversion should happen. The default should match HTML5/ECMAScript.
>
> Excellent! I'm happy to work on this, I hope you already wrote the String::cat stuff? If yes, I'd work on a String::number() implementation (like the one in my attached patch) which gives us more flexibility (add an FloatingPointConversionMode enum, with AvoidExponentials, RoundSiginifcantFigures, RoundDecimalPlaces modes, that can be OR'ed together, etc..)

My main concern here would be that UString::number can be a hot function, so it would probably be undesirable to add unnecessary overhead to switch on a parameter to check the conversion type.  Also, there may be some subtleties to the requirements of any other conversion functions, so we may be better adding them as we need them.  For example, the decimal number conversion uses a fixed size buffer on the stack, which would not be safe to convert large double values to decimal format.  To safely use this conversion the simple solution would probably be to truncate values into a range (which I believe is explicitly permitted in the SVG spec, Simon?) – however String::number having this truncation built in would be a little weird and arbirtary.  Also, to-fixed methods may require a precision argument.

So perhaps it would just be best to switch String::number to have the HTML5/ECMAScript behaviour (matching UString::number) for all uses, for now?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.