I should have been more specific......

ECMA compliant "syntactically".

So - I think we are on the same page.

I actually don't really go in for the compliance at that "object" level (as not all environments would be able to support all the same objects).  If they did - we would only need one language!

So - I guess I am a cherry picker.  I will take what I like and throw away what I dont like.  Which is why I persist with CFSCRIPT because (despite the few short-comings) it matches more closely with the JS/Java/C/C++/C# work that I do.

Regards,
Gary


On 5/10/06, Mark Stanton <[EMAIL PROTECTED]> wrote:

Hey Gary

I have no experience writing language parsers so I could be way off
the mark here, but with all due respect I think ECMA compliance is not
just a matter of making something that exists "standard" or standards
compliant.

"A conforming implementation of ECMAScript must provide and support
all the types, values, objects, properties, functions, and program
syntax and semantics described in this specification."

My reading of this is that there is a heap of stuff in ECMAScript that
does not exist in CF at all or directly conflicts with the way things
are done in CF. The Null type, support for finally in try/catch
blocks, date handling, arrays starting at 0, etc..

I'm all for cfscript getting ECMA style operators like ++, <, > and so
on, but I think that this is worlds apart from ECMA compliance.


--
Mark Stanton
Gruden Pty Ltd
http://www.gruden.com



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "cfaussie" group.
To post to this group, send email to cfaussie@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cfaussie
-~----------~----~----~----~------~----~------~--~---

Reply via email to