Decorators cause issues in other variants about node-dbus-next HOT 4 CLOSED

The thing is that the decorators are just so damn beautiful I couldn't help myself. And they'll be usable one day and it will no longer be a problem.

I have an example babel setup here:

https://github.com/dbusjs/node-dbus-next/tree/master/examples/service

And it works in the widely used mpris-service package:

https://github.com/dbusjs/mpris-service

But to actually answer your question, there is no currently supported way to do this. But we could add something for it for compatibility and it wouldn't be hard.

// after the service class is declared...

MyService.configureMembers({
  properties: [
    // configure properties
  ],
  methods: [
    // configure methods
  ],
  signals: [
    // configure signals
  ]
});

It's just a matter of implementing that.

from node-dbus-next.

I've added an alternative interface. For a usage example, see this test:

https://github.com/dbusjs/node-dbus-next/blob/master/test/integration/configured-service.test.js

class ConfiguredTestInterface extends Interface {
  SomeProperty = 'foo';

  Echo(what) {
    return what;
  }

  HelloWorld() {
    return [ 'hello', 'world' ]
  }

  EmitSignals() {
    this.HelloWorld();
  }
}

ConfiguredTestInterface.configureMembers({
  properties: {
    SomeProperty: {
      signature: 's'
    }
  },
  methods: {
    Echo: {
      inSignature: 'v',
      outSignature: 'v'
    },
    EmitSignals: {}
  },
  signals: {
    HelloWorld: {
      signature: 'ss'
    }
  }
});

Let me know if this is usable for you and I'll document it and put it in the next release.

from node-dbus-next.

Hi @acrisci,
Thanks for this library! I agree with you that decorators looks much better. However, would you please consider using the legacy support from babel? This would make your implementation compatible with TypeScript. The changes to be done on your side are trivial, and would only require babel users to change the plugin they use while compiling.

Moreover, from https://github.com/tc39/proposal-decorators, they clearly advise against using the new babel syntax:

How should I use decorators in transpilers today?
Unfortunately, we're in the classic trap of, "The old thing is deprecated, and the new thing is not ready yet!" For now, best to keep using the old thing.

The decorators champion group would recommend continuing to use Babel "legacy" decorators or TypeScript "experimental" decorators. If you're using decorators today, you're probably already using one of these versions. Note that these decorators depend on "[[Set]] semantics" for field declarations (in Babel, loose mode). We recommend that these tools maintain support for [[Set]] semantics alongside legacy decorators, until it's possible to transition to the decorators of this proposal.

Babel 7 supports the decorators proposal presented to TC39 in the November 2018 TC39 meeting. It's fine to use these for experimental purposes, but they face significant performance issues, are not yet widely adopted; we don't plan to continue pushing for this proposal in TC39. As such, we recommend against using this version for serious work. In follow-on proposals to add more built-in decorators, we hope to be able to recover the extra functionality that the November 2018 decorators proposal supported.

from node-dbus-next.

@yannickadam I think we can just support both. We can just put the legacy decorators in another file and you can import from there instead.

from node-dbus-next.