[webkit-reviews] review granted: [Bug 206929] Make sure MediaRecorder.requestData returns data with the new writer backend : [Attachment 401889] Adding deprecation macros

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jun 15 08:38:19 PDT 2020


Darin Adler <darin at apple.com> has granted youenn fablet <youennf at gmail.com>'s
request for review:
Bug 206929: Make sure MediaRecorder.requestData returns data with the new
writer backend
https://bugs.webkit.org/show_bug.cgi?id=206929

Attachment 401889: Adding deprecation macros

https://bugs.webkit.org/attachment.cgi?id=401889&action=review




--- Comment #5 from Darin Adler <darin at apple.com> ---
Comment on attachment 401889
  --> https://bugs.webkit.org/attachment.cgi?id=401889
Adding deprecation macros

View in context: https://bugs.webkit.org/attachment.cgi?id=401889&action=review

>
Source/WebCore/platform/mediarecorder/cocoa/MediaRecorderPrivateWriterCocoa.mm:
489
> +	       ALLOW_DEPRECATED_DECLARATIONS_BEGIN
> +	       [m_writer flush];
> +	       ALLOW_DEPRECATED_DECLARATIONS_END

Do we have to write code using a deprecated function? What’s the long term
strategy for the deprecation? Why can’t we take advantage of it now?

>
Source/WebCore/platform/mediarecorder/cocoa/MediaRecorderPrivateWriterCocoa.mm:
496
> +		   RefPtr<SharedBuffer> buffer;
> +		   if (weakThis)
> +		       buffer = WTFMove(m_data);
> +
> +		   completionHandler(WTFMove(buffer));

How about this version?

    if (!weakThis)
	return completionHandler({ });

    completionHandler(WTFMove(m_data));

Seems easier to read than the one with the local variable and double WTFMove?
And has the same early exit here as above. I probably would have written it
with nullptr and without using a "void return", but I figured we could stay
consistent.


More information about the webkit-reviews mailing list