Skip to content
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

buffer: hard-deprecate calling Buffer without new #8169

Closed
wants to merge 5 commits into from
Closed

buffer: hard-deprecate calling Buffer without new #8169

Show file tree
Hide file tree
Changes from all 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 ' +
'`Buffer.from()`, `Buffer.allocUnsafe()` or `Buffer.alloc()` instead.',
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.

It's ok to keep allocUnsafe here, but the order should be different, I think: from, alloc, allocUnsafe.

/cc @Fishrock123

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is your concern that users will needlessly use Buffer.allocUnsafe? If so, I don't think the order matters much. The "Unsafe" part is already a good indicator that it's not recommended.

What seems a bit more likely (although still very unlikely) is that if we change the order to from, alloc, allocUnsafe, the user will stop reading after alloc, prompting a situation described in #8169 (comment).

'DeprecationWarning'
);
}
Copy link
Member

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

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

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

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

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

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
17 changes: 17 additions & 0 deletions test/parallel/test-buffer-deprecated.js
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
'use strict';
const common = require('../common');
const assert = require('assert');

const expected =
'Using Buffer without `new` will soon stop working. ' +
'Use `new Buffer()`, or preferably ' +
'`Buffer.from()`, `Buffer.allocUnsafe()` or `Buffer.alloc()` instead.';

process.on('warning', common.mustCall((warning) => {
assert.strictEqual(warning.name, 'DeprecationWarning');
assert.strictEqual(warning.message, expected,
`unexpected error message: "${warning.message}"`);
}, 1));

Buffer(1);
Buffer(1);