[webkit-reviews] review denied: [Bug 10750] SVG needs SVGAnimatedTypeNamePropertyName<ClassName> classes : [Attachment 10494] Updated complete patch

bugzilla-request-daemon at opendarwin.org bugzilla-request-daemon at opendarwin.org
Sun Sep 10 23:44:44 PDT 2006

Eric Seidel <macdome at opendarwin.org> has denied Eric Seidel
<macdome at opendarwin.org>'s request for review:
Bug 10750: SVG needs SVGAnimatedTypeNamePropertyName<ClassName> classes

Attachment 10494: Updated complete patch

------- Additional Comments from Eric Seidel <macdome at opendarwin.org>
This is going to take a couple passes.	314k is a big patch to try and review
in one go.

darin is never a fan of these comments (with ellipses):
+    # Start actual generation...

This should probably be a subroutine:
-	 $implIncludes{"${type}.h"} = 1;
+	 if ($type ne "SVGRect" and
+	     $type ne "SVGPoint" and
+	     $type ne "SVGNumber") {
+	     $implIncludes{"${type}.h"} = 1;
+	 }

This also seems rather specific and probably should be a sub-routine:
-    push(@headerContent, "class $implClassName;\n\n");
+    push(@headerContent, "class $implClassName;\n\n")

Again, subroutine:

+  if ($className =~ /^JSSVGAnimated/) {
+    my $type = $interfaceName;
+    $type =~ s/SVGAnimated//; 
+    if ($type eq "SVGRect" or
+	 $type eq "SVGPoint" or
+	 $type eq "SVGNumber") {
+      $implIncludes{"JSSVG$type.h"} = 1;
+    } else {
+      push(@implContentHeader, "#include \"PlatformString.h\"\n") if($type eq
+    }
+  }

+    return 1 if $type eq "SVGAnimatedAngle" or
+		 $type eq "SVGAnimatedBoolean" or
+		 $type eq "SVGAnimatedEnumeration" or
+		 $type eq "SVGAnimatedInteger" or

This would be easier written by using:
$type =~ s/SVGAnimated/
%w{ Angle Boolean Enumeration }.contains $type, or something similar.
(I think that works in perl, I know it does in ruby...)

+	JSSVGAnimatedAngle.h \
+	JSSVGAnimatedBoolean.h \

I don't understand what "nodptr" is.  Seems like a bad name if nothing else:
+  interface [nodptr, Conditional=SVG] SVGAnimatedPoints { 

darin prefers new Foo; in these sorts of cases (no ()):
+    , m_tableValues(new SVGNumberList())
Yet another thing which should be added to the style guidelines.

I've been removing KSVG_ as well from these:
-#endif // KSVG_SVGPreserveAspectRatioImpl_H
+#endif // KSVG_SVGPreserveAspectRatio_H

since it's now sorta all WebCore (not that we don't like KSVG!)

No need for the argument name here:
+	 SVGTransform* createSVGTransformFromMatrix(SVGMatrix* matrix) const;

What a fabulous change:
-    viewBoxBaseValue()->setX(x);
-    viewBoxBaseValue()->setY(y);
-    viewBoxBaseValue()->setWidth(w);
-    viewBoxBaseValue()->setHeight(h);
+    setViewBoxBaseValue(FloatRect(x, y, w, h));

Normally we do ! instead of == 0, also if( needs a space:
+    if(viewBoxRect.width() == 0 || viewBoxRect.height() == 0)

Conditional=SVG seems redundant if everything is inside module SVG:
+module svg
+  interface [Conditional=SVG] SVGAnimatedRect { 

No need to explicitly initialize m_vector:

+	 SVGListBase() : m_vector() { }

These are beautiful:
+	// Specialization for String...
+	template<>
+    class SVGList<String> : public SVGListBase<String>

This needs to move off of DeprecatedString, but not necessarily in this patch:

+void SVGStringList::reset(const DeprecatedString& str)

We need to have a good method of codifying this:
+	      attribute core::DOMString baseVal;
+			  // raises DOMException on setting

I think you already have a FIXME in SVGAnimatedTemplate.  WE shoudl file a bug
as well though.

again, confused by "nodptr"

+  interface [nodptr, Conditional=SVG] SVGAnimatedPathData { 

Seems silly to have a separate line for return here:
+    RefPtr<ClassName::SVGAnimatedTemplate##UpperProperty> ret; \
+    ret = new ClassName::SVGAnimatedTemplate##UpperProperty(context); \
+    return ret; \

here again:
+    RefPtr<ClassName::SVGAnimatedTemplate##UpperProperty> ret; \
+    ret = new ClassName::SVGAnimatedTemplate##UpperProperty(this); \
+    return ret; \

No need to create a new floatRect here on property at a time, or?
), viewBox().y(), viewBox().width(), viewBox().height()));

and again:
+    rootContainer->setViewBox(FloatRect(viewBox().x(), viewBox().y(),
viewBox().width(), viewBox().height()));

I'm not sure why this is necessary:
+// Special handling for WebCore::FloatRect
+inline FloatRect SVGDocumentExtensions::baseValue<FloatRect>(const SVGElement*
element, const AtomicString& propertyName) const

You can have pointer and non-pointer specializations.  Vector uses something
like that.

This may be simply the most beautiful patch I have ever seen. :)

I would r+ it right here and now, but since you don't (yet!) have commit
privileges, I think we should go one more round on this one to fix a few of the
little issues I've mentioned above.

I *can't wait* to see this land!!

More information about the webkit-reviews mailing list