ES6 methods and @decorators

[valq7711]

1. In ES6 all methods are 'non-enumerable' by default, but in es5 - vise versa! So, code written for es5 may be crash on es6 if there are any for ... in some.prototype (uncatchable bugs will be provided, that's worse).

2. Todays es6 @decorator implementation is just class.prototype.meth = decorator(class.prototype.meth) that makes the method enumerable! So, @decorator has side unexpected effect! It may be fixed by moving 'decorations' into class vars defs (means Object.defineProperties with enumerable=false).

[atsepkov]

1. Is there a specific case where this would be a problem? It seems like non-enumerable is good design and the fact that ES5 does not do this was probably a design bug to begin with.

2. Good catch, I think that's a good suggestion and don't see any side-effects with it aside from the more verbose syntax.

[valq7711]

Yes, I had a problem, and I wasted a day to catch it - I have one function that enumerate methods to find some that have specific attribute (with es5 - works fine). The problem is that js-code use one syntax for es5 (prototype) and another for es6 (class)*, while RS-code doesn't have any differeсe in syntax, but in behaviour (with --es6 or not). And the fact that it could be a problem for only specific cases makes it worse. It's not the issue of Rapydscript self, but I think it deserves some warnings/attentions in the doc.
*means that pure js-developers sees what they do