On 13 Nov., 16:16, "Peter Michaux" <[EMAIL PROTECTED]> wrote: > > The ES3.1 proposed document, which is down to almost just typo fixes > apparently, still has the future reserved words in section 7.5.3. > There is a note they will add "const", "let" and "yield". So I won't > be using any of those words for identifiers as there is inherent risk > for the future (although if they are adding to the list then there is > risk with other identifiers anyway.) > > It would be nice to be able to do > > foo.class > > without a problem. I know Douglas Crockford thought that should be > acceptable. I don't know if the ES3.1 document allows this.
I find it interesting that ES3.1 still has basically the same future reserved keywords list as ES3, given the general disregard in JS browser engines. I guess I should ask on es3.x-discuss list on why this is so. Maybe it would be better to leave default setting for future reserved keywords as disallowed, but apply the rest of the patch, i.e. remove the warning message if allowed and handle "import" and "export" as future reserved keywords as defined in the ES spec. On Nov 13, 4:53 pm, "David Parks" <[EMAIL PROTECTED]> wrote: > > 2) I'm jumping up and down in my chair for this one. Assuming it means that > the get/put operations currently implemented on ScriptableObject and its > subclasses will be reviewed and cleaned up. The current implementation is > not consistent from one subclass to the next (as described in bug #464312). > I think the work that would be required for this one would also naturally > resolve the issues described in bug #464312, and in the end we would have a > more elegant implementation. Just make sure that NativeArray > implements/overrides the interface in a way consistent with other subclasses > and I'll come give you a kiss! The implementation of the Map interface in ScriptableObject doesn't change anything in the current ScriptableObject API, it's purely an additional interface to ease interaction with Java code. I'm afraid bug #464312 is based on a misunderstanding of the API - most of what you describe as bugs is actually intentional behaviour. It is true that some of it is quirky, e.g getIds() returning strings for array indices, but that's actually based on the ES spec IIRC. On Nov 13, 4:57 pm, Attila Szegedi <[EMAIL PROTECTED]> wrote: > > Absolutely great. While we're at it, we might want to also add List > interface to NativeArray? Good point! I'll look into this. > No specific opinion about this one. I dislike having "reserved words" > in a language that were reserved speculatively long-long time ago, but > never got assigned any functionality, so yeah, it sounds good to me. As I said above, maybe it's wiser to leave the default setting as it is. After all enabling a feature or not is quite easy for anyone embedding Rhino. Hannes _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
