Bug 27521 – Move m_context out of generator into superclass

• Status: RESOLVED
• Resolution: FIXED
• Component: SVG

[Eric Seidel (no email)]

Move m_context out of generator into superclass

This will reduce WebCore's code size.  This will also make it easier for me to incrementally move classes over to holding an m_globalObject pointer.

[Eric Seidel (no email)]

Created attachment 33217 [details]
patch

[Adam Barth]

Comment on attachment 33217 [details]
patch

This looks good.  Perl is super ugly.

[Eric Seidel (no email)]

Created attachment 33227 [details]
Move out into a file to fix WebKit build


---
 9 files changed, 113 insertions(+), 43 deletions(-)

[Eric Seidel (no email)]

Created attachment 33228 [details]
Fix WebKit build by moving into new file


---
 9 files changed, 121 insertions(+), 43 deletions(-)

[Adam Barth]

Comment on attachment 33228 [details]
Fix WebKit build by moving into new file

okedoke

[Eric Seidel (no email)]

Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	WebCore/ChangeLog
	M	WebCore/WebCore.gypi
	M	WebCore/WebCore.pro
	M	WebCore/WebCore.vcproj/WebCore.vcproj
	M	WebCore/WebCore.xcodeproj/project.pbxproj
	A	WebCore/bindings/js/DOMObjectWithSVGContext.h
	M	WebCore/bindings/js/JSEventCustom.cpp
	M	WebCore/bindings/scripts/CodeGeneratorJS.pm
Committed r46201
	M	WebCore/WebCore.pro
	M	WebCore/ChangeLog
	M	WebCore/WebCore.vcproj/WebCore.vcproj
	M	WebCore/WebCore.gypi
	M	WebCore/bindings/scripts/CodeGeneratorJS.pm
	A	WebCore/bindings/js/DOMObjectWithSVGContext.h
	M	WebCore/bindings/js/JSEventCustom.cpp
	M	WebCore/WebCore.xcodeproj/project.pbxproj
r46201 = ef823b64df0e4d61afa35bb385e3fa577ac0f419 (trunk)
No changes between current HEAD and refs/remotes/trunk
Resetting to the latest refs/remotes/trunk
http://trac.webkit.org/changeset/46201

[Sam Weinig]

Out of curiosity, what is the reason that the context can't be in the JSSVGPODTypeWrapper class?

[Adam Barth]

(In reply to comment #7)
> Out of curiosity, what is the reason that the context can't be in the
> JSSVGPODTypeWrapper class?

The context will eventually move to the impl, so I'm not sure it matters that much were it is in the intermediate term.

[Eric Seidel (no email)]

(In reply to comment #7)
> Out of curiosity, what is the reason that the context can't be in the
> JSSVGPODTypeWrapper class?

Sam is correct, that in the case of POD types, JSSVGPODTypeWrapper is the impl.

For things like SVGPathSeg, those classes will have to change to hold some sort of context pointer.

JSSVGPODTypeWrapper will be the "easy" case.