|Please place new discussions at the bottom of the talk page.|
|This is the talk page for discussing improvements to the Haxe article.|
|This article is of interest to the following WikiProjects:|
I have edited the article removing and clarifying claims such as "full support for iPhone, Android, Windows, Unix, Mac, etc", since Haxe currently only supports a subset of the full platform API. Please do not remove this clarification. Before my edit, Haxe appeared to be a full-featured multiplatform language which it is currently not. Please do not add biased statements into the article inferring the same.
Nicolas Cannesse and friends, please stop adding the JS/NodeJS and other langs to the "full support" category unless you can prove full platform API supported. If it does, add refs to prove it. Currently the API page has 40 JS classes. Is that full support? And what about the 100 NodeJS classes? Unless you can show EVERY function from EVERY class, it does not qualify as full support and therefore Haxe cannot be used as a full replacement to that platform's native language. Saying it has full support is misleading and incorrect. -- Tom Jenkins (reply) 06:44, 6 February 2013 (UTC)
@Tom Jenkins You seem to be under the impression that full support for compiling code to a certain language requires all the APIs of the respective standard library of the target language to be included into the standard library of the source language. You are mistaken.
Haxe provides support for all of JS per definition - each and every function in every prototype that JS or any third-party JS library offers, is usable from haxe directly, without any further work. The same is true for any other dynamic target language. The simple reason is that the Haxe type-system provides support for "Dynamic" instances - those can be any function, object, prototype in JS. What you are talking about are static type definitions ("extern class" definitions in Haxe) for these APIs, but those are just a nice-to-have, not a requirement, let alone their inclusion into the standard library. In fact, by your standards, JS itself doesn't have any support for JS or any JS libraries, because there are no static type definitions in the language.
NodeJS is a third-party platform/API, and haxe usually provides support for third-party APIs in third-party libraries (in the form of collections of extern class definitions). That doesn't make the support go away.
JS is not an OOP language, but a prototyped language. There are no classes in JS. You're demanding that haxe supports things that don't even exist.
Sufficient proof for all this (where's the precedence for demanding proofs, btw?) are the both the compilers source code, and the compilers very trivially observable behavior. If you don't understand that, that's not the problem of those writing the WP article about Haxe.
So before you change the article again - please show me a single piece of JS code that in your opinion can't be written in (or used from) Haxe, and I'll give you the proof that you demand. -- TOderson