Add a version of SVGLengthContext::valueForLength with explicit dimension

Add a version of SVGLengthContext::valueForLength with explicit dimension

Used by SVGTextLayoutEngineBaseline::calculateBaselineShift.

BUG=461375
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=191299

[fs, 2015-02-26 13:23:02]

fs@opera.com changed reviewers:
+ ed@opera.com, pdr@chromium.org

[fs, 2015-02-26 13:24:08]

Follow-up to https://codereview.chromium.org/956553004/ as requested. PTAL.

[Erik Dahlström (inactive), 2015-02-26 14:11:16]

https://codereview.chromium.org/960843003/diff/1/Source/core/svg/SVGLengthCon...
File Source/core/svg/SVGLengthContext.h (right):

https://codereview.chromium.org/960843003/diff/1/Source/core/svg/SVGLengthCon...
Source/core/svg/SVGLengthContext.h:72: static float valueForLength(const
Length&, float dimension, const LayoutStyle&);
Is there a reason for not going with the same parameter order as the non-static
version (Length first, then LayoutStyle, then the rest)?

[fs, 2015-02-26 14:27:32]

https://codereview.chromium.org/960843003/diff/1/Source/core/svg/SVGLengthCon...
File Source/core/svg/SVGLengthContext.h (right):

https://codereview.chromium.org/960843003/diff/1/Source/core/svg/SVGLengthCon...
Source/core/svg/SVGLengthContext.h:72: static float valueForLength(const
Length&, float dimension, const LayoutStyle&);
On 2015/02/26 14:11:15, Erik Dahlström wrote:
> Is there a reason for not going with the same parameter order as the
non-static
> version (Length first, then LayoutStyle, then the rest)?

Yes, this order makes me worry less about implicit type conversions.

[fs, 2015-02-26 14:45:35]

https://codereview.chromium.org/960843003/diff/1/Source/core/svg/SVGLengthCon...
File Source/core/svg/SVGLengthContext.h (right):

https://codereview.chromium.org/960843003/diff/1/Source/core/svg/SVGLengthCon...
Source/core/svg/SVGLengthContext.h:72: static float valueForLength(const
Length&, float dimension, const LayoutStyle&);
On 2015/02/26 14:27:31, fs wrote:
> On 2015/02/26 14:11:15, Erik Dahlström wrote:
> > Is there a reason for not going with the same parameter order as the
> non-static
> > version (Length first, then LayoutStyle, then the rest)?
> 
> Yes, this order makes me worry less about implicit type conversions.

I suppose an 'enum class' for SVGLengthMode might solve that. Will have to look
into how much work that change would be.

[fs, 2015-03-03 17:20:51]

On 2015/02/26 14:45:35, fs wrote:
>
https://codereview.chromium.org/960843003/diff/1/Source/core/svg/SVGLengthCon...
> File Source/core/svg/SVGLengthContext.h (right):
> 
>
https://codereview.chromium.org/960843003/diff/1/Source/core/svg/SVGLengthCon...
> Source/core/svg/SVGLengthContext.h:72: static float valueForLength(const
> Length&, float dimension, const LayoutStyle&);
> On 2015/02/26 14:27:31, fs wrote:
> > On 2015/02/26 14:11:15, Erik Dahlström wrote:
> > > Is there a reason for not going with the same parameter order as the
> > non-static
> > > version (Length first, then LayoutStyle, then the rest)?
> > 
> > Yes, this order makes me worry less about implicit type conversions.
> 
> I suppose an 'enum class' for SVGLengthMode might solve that. Will have to
look
> into how much work that change would be.

That's now uploaded at https://codereview.chromium.org/966923003 (so much
typesafe!)

[pdr., 2015-03-03 18:04:26]

On 2015/03/03 at 17:20:51, fs wrote:
> On 2015/02/26 14:45:35, fs wrote:
> >
https://codereview.chromium.org/960843003/diff/1/Source/core/svg/SVGLengthCon...
> > File Source/core/svg/SVGLengthContext.h (right):
> > 
> >
https://codereview.chromium.org/960843003/diff/1/Source/core/svg/SVGLengthCon...
> > Source/core/svg/SVGLengthContext.h:72: static float valueForLength(const
> > Length&, float dimension, const LayoutStyle&);
> > On 2015/02/26 14:27:31, fs wrote:
> > > On 2015/02/26 14:11:15, Erik Dahlström wrote:
> > > > Is there a reason for not going with the same parameter order as the
> > > non-static
> > > > version (Length first, then LayoutStyle, then the rest)?
> > > 
> > > Yes, this order makes me worry less about implicit type conversions.
> > 
> > I suppose an 'enum class' for SVGLengthMode might solve that. Will have to
look
> > into how much work that change would be.
> 
> That's now uploaded at https://codereview.chromium.org/966923003 (so much
typesafe!)

LGTM

[fs, 2015-03-04 14:00:52]

https://codereview.chromium.org/960843003/diff/1/Source/core/svg/SVGLengthCon...
File Source/core/svg/SVGLengthContext.h (right):

https://codereview.chromium.org/960843003/diff/1/Source/core/svg/SVGLengthCon...
Source/core/svg/SVGLengthContext.h:72: static float valueForLength(const
Length&, float dimension, const LayoutStyle&);
On 2015/02/26 14:45:35, fs wrote:
> On 2015/02/26 14:27:31, fs wrote:
> > On 2015/02/26 14:11:15, Erik Dahlström wrote:
> > > Is there a reason for not going with the same parameter order as the
> > non-static
> > > version (Length first, then LayoutStyle, then the rest)?
> > 
> > Yes, this order makes me worry less about implicit type conversions.
> 
> I suppose an 'enum class' for SVGLengthMode might solve that. Will have to
look
> into how much work that change would be.

Made the argument order more consistent.

[Erik Dahlström (inactive), 2015-03-04 14:04:47]

On 2015/03/04 14:00:52, fs wrote:
>
https://codereview.chromium.org/960843003/diff/1/Source/core/svg/SVGLengthCon...
> File Source/core/svg/SVGLengthContext.h (right):
> 
>
https://codereview.chromium.org/960843003/diff/1/Source/core/svg/SVGLengthCon...
> Source/core/svg/SVGLengthContext.h:72: static float valueForLength(const
> Length&, float dimension, const LayoutStyle&);
> On 2015/02/26 14:45:35, fs wrote:
> > On 2015/02/26 14:27:31, fs wrote:
> > > On 2015/02/26 14:11:15, Erik Dahlström wrote:
> > > > Is there a reason for not going with the same parameter order as the
> > > non-static
> > > > version (Length first, then LayoutStyle, then the rest)?
> > > 
> > > Yes, this order makes me worry less about implicit type conversions.
> > 
> > I suppose an 'enum class' for SVGLengthMode might solve that. Will have to
> look
> > into how much work that change would be.
> 
> Made the argument order more consistent.

lgtm \o/

[fs, 2015-03-04 14:07:13]

The CQ bit was checked by fs@opera.com

[fs, 2015-03-04 14:07:13]

The patchset sent to the CQ was uploaded after l-g-t-m from pdr@chromium.org
Link to the patchset: https://codereview.chromium.org/960843003/#ps20001 (title:
"Rebase; Change argument order.")

[commit-bot: I haz the power, 2015-03-04 14:08:07]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/960843003/20001

[commit-bot: I haz the power, 2015-03-04 17:28:50]

Committed patchset #2 (id:20001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=191299