ABANDONED CL: Rename readyState() to getReadyState().

ABANDONED CL (see CR comments for more details and discussion)

----------------------------

Rename readyState() to getReadyState().

The rename is needed to avoid a naming collision after changing from
Blink to Chromium naming style.  Right now we have a |ReadyState| enum
type and |readyState| accessor methods (differing by case of the first
character); after a naive rename by the rewrite_to_chrome_style tool we
would end up with |ReadyState| being the name of both the type and the
accessor methods (with both living in the same namespace).

Prepending a "get" prefix to the name of the accessor method is the
workaround that fits into the guidance on the recommended
post-Blink-to-Chromium-rename style suggested by esprehn@ in
https://crbug.com/582312#c17:
- Getters favor not using "Get", ex. FirstChild()
- Unless the type name conflicts, in which case you can either rename
  the type if it's easy and makes sense, or add "Get", ex. GetContext().

BUG=582312

[Łukasz Anforowicz, 2016-12-12 21:57:46]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[Łukasz Anforowicz, 2016-12-12 21:58:56]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-12 21:59:18]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Łukasz Anforowicz, 2016-12-12 22:01:43]

lukasza@chromium.org changed reviewers:
+ esprehn@chromium.org

[Łukasz Anforowicz, 2016-12-12 22:01:44]

esprehn@, could you PTAL?

FWIW, I've searched for "ReadyState" under out/.../gen and everything looks okay
- I think in this case we do not run into the setGetFoo issue from
https://crbug.com/673039.

[esprehn, 2016-12-12 22:09:38]

Where is the ReadyState enum used? the idl has DocumentReadyState as the enum,
maybe we should do that instead?

[Łukasz Anforowicz, 2016-12-12 22:43:49]

On 2016/12/12 22:09:38, esprehn wrote:
> Where is the ReadyState enum used?

There are 10 definitions under blink:
https://cs.chromium.org/search/?q=enum.*%5CbReadyState%5Cb+file:.*WebKit.*+la...

> the idl has DocumentReadyState as the enum,

I see that there is a blink::Document::ReadyState, so I think that we still need
to rename blink::Document::readyState to getReadyState.

Unfortunately, I wasn't able to track down where "DocumentReadyState" (from
Document.idl) ends up being used - I only see it in
out/Debug/gen/blink/bindings/core/ComponentInfoCore.pickle ...

> maybe we should do that instead?

Can you please clarify what you think we should do?

1. Are you suggesting to rename ReadyState enums?  What would
FileWriter::ReadyState be renamed to?

2. Are you suggesting to trim down the CL under review to only rename
readyState->getReadyState if there is an actual conflict?  I renamed all
"readyState()" to "getReadyState()" because 1) it was easier to do (yes, this is
a bad argument :-/ ) and 2) it felt more resilient to a risk of future conflicts
(but it only felt this way, because back then I didn't check that ReadyState is
not a *top-level* enum, but it is always embedded in a class)

FWIW, trying to consider #2 above, I went through header files touched by this
CL and annotated the changes, trying to point out the enum that conflicts with
the renamed accessor method.

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/dom/Document.h (right):

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/dom/Document.h:359: String getReadyState() const;
After naive rename this would conflict with Document::ReadyState enum defined
below.

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.h (right):

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.h:117: State
getReadyState() const;
This rename is probably not needed.

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/eventsource/EventSource.h (right):

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/eventsource/EventSource.h:76: State
getReadyState() const;
This rename is probably not needed.

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/indexeddb/IDBRequest.h (right):

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/indexeddb/IDBRequest.h:85: const String&
getReadyState() const;
After naive rename this would conflict with IDBRequest::ReadyState enum defined
above.

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/mediasource/MediaSource.h (right):

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/mediasource/MediaSource.h:85: const
AtomicString& getReadyState() const { return m_readyState; }
After naive rename this would conflict with MediaStreamSource::ReadyState enum
defined in another header file - in
third_party/WebKit/Source/platform/mediastream/MediaStreamSource.h

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/mediastream/MediaStreamTrack.h (right):

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/mediastream/MediaStreamTrack.h:68: String
getReadyState() const;
Not sure if this rename is required...

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/peerconnection/RTCDataChannel.h (right):

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/peerconnection/RTCDataChannel.h:81: String
getReadyState() const;
Not sure if this rename is required...

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/websockets/DOMWebSocket.h (right):

https://codereview.chromium.org/2572603002/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/websockets/DOMWebSocket.h:106: State
getReadyState() const;
Not sure if this rename is actually required.

[esprehn, 2016-12-12 23:01:11]

Right, just rename all the ReadyState enums to ReadyStateType or something.

[Łukasz Anforowicz, 2016-12-13 00:14:44]

On 2016/12/12 23:01:11, esprehn wrote:
> Right, just rename all the ReadyState enums to ReadyStateType or something.

Ok.  I agree that Document::ReadyState -> Document::DocumentReadyState is better
than the changes originally proposed in this CL.  Let me do exactly this rename
in https://codereview.chromium.org/2567943004.

I'll keep the CL under review opened for a little while, until I figure out what
to do with the remaining conflicts in
- third_party/WebKit/Source/modules/indexeddb/IDBRequest.h
- third_party/WebKit/Source/modules/mediasource/MediaSource.h and
third_party/WebKit/Source/platform/mediastream/MediaStreamSource.h
(either spinning them off into separate CL like I did with Document::ReadyState
or handling them right here).

[commit-bot: I haz the power, 2016-12-13 01:19:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-13 01:19:44]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Łukasz Anforowicz, 2016-12-22 17:36:18]

On 2016/12/13 00:14:44, Łukasz Anforowicz wrote:
> On 2016/12/12 23:01:11, esprehn wrote:
> > Right, just rename all the ReadyState enums to ReadyStateType or something.
> 
> Ok.  I agree that Document::ReadyState -> Document::DocumentReadyState is
better
> than the changes originally proposed in this CL.  Let me do exactly this
rename
> in https://codereview.chromium.org/2567943004.
> 
> I'll keep the CL under review opened for a little while, until I figure out
what
> to do with the remaining conflicts in
> - third_party/WebKit/Source/modules/indexeddb/IDBRequest.h
> - third_party/WebKit/Source/modules/mediasource/MediaSource.h and
> third_party/WebKit/Source/platform/mediastream/MediaStreamSource.h
> (either spinning them off into separate CL like I did with
Document::ReadyState
> or handling them right here).

Abandoning this CL - nasko@ says that we don't have a class-vs-method anymore
with the remaining cases of readyState.

[Łukasz Anforowicz, 2016-12-22 17:36:50]

Description was changed from

==========
Rename readyState() to getReadyState().

The rename is needed to avoid a naming collision after changing from
Blink to Chromium naming style.  Right now we have a |ReadyState| enum
type and |readyState| accessor methods (differing by case of the first
character); after a naive rename by the rewrite_to_chrome_style tool we
would end up with |ReadyState| being the name of both the type and the
accessor methods (with both living in the same namespace).

Prepending a "get" prefix to the name of the accessor method is the
workaround that fits into the guidance on the recommended
post-Blink-to-Chromium-rename style suggested by esprehn@ in
https://crbug.com/582312#c17:
- Getters favor not using "Get", ex. FirstChild()
- Unless the type name conflicts, in which case you can either rename
  the type if it's easy and makes sense, or add "Get", ex. GetContext().

BUG=582312
==========

to

==========
ABANDONED CL (see CR comments for more details and discussion)

----------------------------

Rename readyState() to getReadyState().

The rename is needed to avoid a naming collision after changing from
Blink to Chromium naming style.  Right now we have a |ReadyState| enum
type and |readyState| accessor methods (differing by case of the first
character); after a naive rename by the rewrite_to_chrome_style tool we
would end up with |ReadyState| being the name of both the type and the
accessor methods (with both living in the same namespace).

Prepending a "get" prefix to the name of the accessor method is the
workaround that fits into the guidance on the recommended
post-Blink-to-Chromium-rename style suggested by esprehn@ in
https://crbug.com/582312#c17:
- Getters favor not using "Get", ex. FirstChild()
- Unless the type name conflicts, in which case you can either rename
  the type if it's easy and makes sense, or add "Get", ex. GetContext().

BUG=582312
==========