js-interop: can't create object with _field (private)

[denisoby]

I'm trying to create query to mongodb and use nodejs library for calls to DB.

In dart I define special object to pass to nodejs api.

@JS()
@anonymous
class mongoQuery {
  external String get _id;
  external void set _id(String _id);
  external factory mongoQuery({String _id});
}

But building fails with error:

[Error from Dart2JS on livedb|example/main.dart]: packages/livedb/nodeannotations/js.dart:27:39: Named optional parameter can't have a library private name. Try removing the '' or making the parameter positional or required. external factory mongoQuery({String _id}); ^^^

From my point of view this is incorrect, because JavaScript do not have this restrictions. And annotation should follow JS rules and allow using _fields.

P.S. Solution: define such fields as usual, and set them after constructor call: Example in https://github.com/dart-lang/sdk/issues/26468

[jacob314]

Bob I can't think of a good reason why we should prohibit in named arguments. Dart visibility rules are for class members not parameter names. Prohibiting in named parameter names seems like foolish consistency particularly if Dart adopts alternative schemes for public, protected going forward.

[floitschG]

The leading "_" is a property of identifiers. Conceptually a leading "_" of any identifier is replaced with a library-token. Since named arguments are parameters (and thus identifiers) they follow the same rules.

[denisoby]

@floitschG I understand this from darts point of view. But this is conflicting with JS integration. I can't make code that works with JS that uses "_xxxx".

This looks like "we don't play football, that's our choice - thus we will not make business with people who play football".

[floitschG]

It's more of an explanation of why this is not just that simple.

If we just went ahead and allowed named arguments with leading "_", nobody could use them. We would need to change more places in the spec (and potentially implementations) to make this work.

[denisoby]

@floitschG thanks for explanation.