Skip to content

buffer: hard-deprecate calling Buffer without new #8169

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
seishun wants to merge 5 commits into from
Closed

buffer: hard-deprecate calling Buffer without new #8169

Changes from 3 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
996389c
buffer: hard-deprecate calling Buffer without new
seishun Aug 18, 2016
63172e4
use shiny new syntax
seishun Aug 19, 2016
54ca2d8
use emitWarning directly
seishun Aug 19, 2016
fccd038
add backticks and parentheses
seishun Aug 19, 2016
91c72fa
add test
seishun Aug 19, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions lib/buffer.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -64,7 +64,17 @@ function alignPool() {
* much breakage at this time. It's not likely that the Buffer constructors
* would ever actually be removed.
**/
var newBufferWarned = false;
function Buffer(arg, encodingOrOffset, length) {
if (!new.target && !newBufferWarned) {
newBufferWarned = true;
process.emitWarning(
'Using Buffer without `new` will soon stop working. ' +
'Use `new Buffer`, or preferably ' +
Copy link
Contributor

@Fishrock123 Fishrock123 Aug 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually since this will be in v7... maybe we should only recommend Buffer.from() and Buffer.alloc() (pref with the parenthesis?)

Copy link
Member

@jasnell jasnell Aug 19, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That works for me misread the comment... see #8169 (comment) instead.

'Buffer.from, Buffer.allocUnsafe or Buffer.alloc instead.',
Copy link
Contributor

@Fishrock123 Fishrock123 Aug 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since my previous comment got squashed... maybe without allocUnsafe?

I think the people who need that will be able to find it.

Copy link
Contributor Author

@seishun seishun Aug 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might backfire. People might be using Buffer() in performance-critical code. They might try Buffer.alloc in a hurry, see that it slows down their code, then shrug and just use new Buffer().

Copy link
Member

@jasnell jasnell Aug 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would keep all three listed and just drop the 'Use new Buffer'... just point to the three new constructors in the order: Buffer.from(), Buffer.alloc(), and Buffer.from().

Also, a small nit: @seishun, can you add the () after each of the functions?

Copy link
Contributor Author

@seishun seishun Aug 19, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I imagine users who don't keep track of Node.js development would be thoroughly confused by a message that says they shouldn't call Buffer without new and then tells them to use something entirely different. They would wonder whether they can just use new Buffer and if not, why they don't get such a message with new Buffer.

The current message at least gives them the choice to either read the documentation and learn about the new APIs, or do the quick fix if they're in a hurry.

Copy link
Member

@ChALkeR ChALkeR Aug 19, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jasnell What order did you mean? As there is clearly a mistype somewhere. =)

'DeprecationWarning'
);
}
Copy link
Member

@jasnell jasnell Aug 18, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of this, please use process.emitWarning() ...

process.emitWarning(
  'Calling Buffer() without `new` is deprecated. Use Buffer.alloc(), ' +
  'Buffer.allocUnsafe(), Buffer.from(), or new Buffer() instead.',
  'DeprecationWarning'
);

Copy link
Member

@addaleax addaleax Aug 18, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jasnell That would emit a warning every time Buffer() is called, not only the first time, right?

Copy link
Member

@jasnell jasnell Aug 18, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right.. there should be a gate... like so:

var newBufferWarned = false;
function Buffer(arg, encodingOrOffset, length) {
  if (!new.target && !newBufferWarned) {
    newBufferWarned = true;
    process.emitWarning(
      'Calling Buffer() without `new` is deprecated. Use Buffer.alloc(), ' +
      'Buffer.allocUnsafe(), Buffer.from(), or new Buffer() instead.',
      'DeprecationWarning'
    );
  }
  //...

Copy link
Contributor Author

@seishun seishun Aug 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you clarify the purpose of such change? It would introduce needless boilerplate and make it inconsistent with the rest of node.

Copy link
Member

@jasnell jasnell Aug 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #8166 ... I'm working towards making this more consistent. If you look at the current implementation of the internal/util printDeprecationMessage() you'll see that it simply defers to the process.emitWarning() method already, so it's a bit of an unnecessary indirection.

Also, the way that bufferDeprecationWarning() is implemented in this PR is unnecessarily more complex than it needs to be. There's no reason to create a new object and closure.

Copy link
Contributor Author

@seishun seishun Aug 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jasnell Done. I kept the wording because "Calling Buffer() without new is deprecated." implies that calling Buffer with new is not deprecated.

// Common case.
if (typeof arg === 'number') {
if (typeof encodingOrOffset === 'string') {
Expand Down