RESOLVED FIXED 49705
[HTML5] Rename member variables of HTMLScriptElement
https://bugs.webkit.org/show_bug.cgi?id=49705
Summary [HTML5] Rename member variables of HTMLScriptElement
Ryosuke Niwa
Reported 2010-11-17 18:31:46 PST
We should rename member variables of HTMLScriptElement to match the terminology used in HTML5 spec.
Attachments
renamed (13.85 KB, patch)
2010-11-17 18:36 PST, Ryosuke Niwa
no flags
fixed per Darin's comment (14.56 KB, patch)
2010-11-18 10:43 PST, Ryosuke Niwa
no flags
updated ChangeLog (14.58 KB, patch)
2010-11-18 10:46 PST, Ryosuke Niwa
no flags
fixed comment (14.78 KB, patch)
2010-11-18 11:06 PST, Ryosuke Niwa
darin: review+
Ryosuke Niwa
Comment 1 2010-11-17 18:36:41 PST
Created attachment 74189 [details] renamed
Darin Adler
Comment 2 2010-11-17 22:11:18 PST
Comment on attachment 74189 [details] renamed View in context: https://bugs.webkit.org/attachment.cgi?id=74189&action=review > WebCore/dom/ScriptElement.h:92 > + bool m_insertedByParser; > + bool m_extrnalScript; > + bool m_alreadyStarted; > bool m_firedLoad; Boolean data members should be named so that they finish a sentence "script element <xxx>". That’s why they often start with something like “was”. I suggest: m_wasInsertedByParser m_isExternalScript m_wasAlreadyStarted m_hasFiredLoadEvent I also suggest renaming functions, not just the data members. "extrnalScript" needs an "e".
Ryosuke Niwa
Comment 3 2010-11-18 10:43:54 PST
Created attachment 74256 [details] fixed per Darin's comment
Ryosuke Niwa
Comment 4 2010-11-18 10:46:44 PST
Created attachment 74259 [details] updated ChangeLog
Darin Adler
Comment 5 2010-11-18 10:49:39 PST
Comment on attachment 74256 [details] fixed per Darin's comment View in context: https://bugs.webkit.org/attachment.cgi?id=74256&action=review > WebCore/dom/ScriptElement.cpp:164 > // m_createdByParser is never reset - always resied at the initial value set while parsing. > // m_evaluated is left untouched as well to avoid script reexecution, if a <script> element Didn’t we rename m_createdByParser and m_evaluated? Comment should be fixed. > WebCore/dom/ScriptElement.cpp:178 > - if (m_isEvaluated || sourceCode.isEmpty() || !shouldExecuteAsJavaScript()) > + if (wasAlreadyStarted() || sourceCode.isEmpty() || !shouldExecuteAsJavaScript()) Why the change from looking at the data member to calling the function? > WebCore/dom/ScriptElement.cpp:205 > - if (m_isEvaluated || sourceCode.isEmpty()) > + if (wasAlreadyStarted() || sourceCode.isEmpty()) Same question.
Darin Adler
Comment 6 2010-11-18 10:50:06 PST
Comment on attachment 74259 [details] updated ChangeLog Later we could rename the haveFiredLoadEvent function to hasFiredLoadEvent or maybe an even better name.
Ryosuke Niwa
Comment 7 2010-11-18 10:58:57 PST
(In reply to comment #5) > > WebCore/dom/ScriptElement.cpp:164 > > // m_createdByParser is never reset - always resied at the initial value set while parsing. > > // m_evaluated is left untouched as well to avoid script reexecution, if a <script> element > > Didn’t we rename m_createdByParser and m_evaluated? Comment should be fixed. Oops, will do. > > WebCore/dom/ScriptElement.cpp:178 > > - if (m_isEvaluated || sourceCode.isEmpty() || !shouldExecuteAsJavaScript()) > > + if (wasAlreadyStarted() || sourceCode.isEmpty() || !shouldExecuteAsJavaScript()) > > Why the change from looking at the data member to calling the function? > > WebCore/dom/ScriptElement.cpp:205 > > - if (m_isEvaluated || sourceCode.isEmpty()) > > + if (wasAlreadyStarted() || sourceCode.isEmpty()) > > Same question. So we're inconsistent in calling accessor vs. accessing member variable directly. I tried to make this consistent by always calling the accessor but I can do the other way, which is to replace all calls to accessor by accessing member variables directly.
Ryosuke Niwa
Comment 8 2010-11-18 11:06:54 PST
Created attachment 74263 [details] fixed comment
Ryosuke Niwa
Comment 9 2010-11-30 17:42:07 PST
Hi Darin, could you review this patch?
Ryosuke Niwa
Comment 10 2010-11-30 17:54:47 PST
Thanks for the review!
Ryosuke Niwa
Comment 11 2010-11-30 18:09:48 PST
Note You need to log in before you can comment on or make changes to this bug.