Overwriting JavaScript native methods? Why?

[pat...@nestlabs.com]

Hello,

I am curious as to why the HaXe compiler for JS overwrites so many of the native JavaScript object methods.

I can understand the need to provide polyfills for older browsers which lack some modern JS functionality.  But there are better ways to accomodate those browsers, without punishing the majority of browsers which don't need this.

I would like the opportunity to use HaXe for writing agnostic, multi-target algorithms.  But as-is, with the JavaScript shim written the way it is, there's really no way for me to even entertain the notion.

thanks,

Patrick

[Nicolas Cannasse]

Could you give some practical examples ?

BEst,
Nicolas

[pat...@nestlabs.com]

Hi Nicolas,

I would be happy to.  (The following comes from somewhere in the realm of the jsBoot / jsLib code.)

if(String.prototype.cca == null) String.prototype.cca = String.prototype.charCodeAt;

String.prototype.charCodeAt = function(i) {

var x = this.cca(i);

if(x != x) return null;

return x;

};

This will always overwrite the native method, even when unnecessary.

Moreover, unless I'm misreading the code, it is simply assigning the native function to a second property on the String prototype.  Environments which lack the charCodeAt will still do nothing more than return null for all input.

thanks,

Patrick

[Juraj Kirchheim]

It's all about the subtleties ;)

If you really think about the code, you will see that `(x != x)` only
ever applies for NaN, which is the whole point of this substitution.
In the haXe standard library, the return type of charCodeAt is
Null<Int> (whereas in JS it's Number, if it were defined).

From what I can tell haXe overwrites two builtin functions, which are
substr and charCodeAt. If I count correctly, that is two and that is
commonly considered lesser than "so many" ;)

[Niel Drummond]

though x != x will balk in any linter I know of, the equivalent Math.isNaN is much cleaner.

- Niel

[Nicolas Cannasse]

Le 16/12/2011 20:21, Niel Drummond a �crit :

> though x != x will balk in any linter I know of, the equivalent
> Math.isNaN is much cleaner.

And slower.

Best,
Nicolas

[pat...@nestlabs.com]

Thank you for your varied responses.  I'm not really detecting from the tone of the discussion that there is much desire to converge on a solution to my problem, nor to really understand it.  The wise thing for me to do would be to move on and look for other solutions.

cheers,

Patrick

[Simon Krajewski]

I think we just don't see what your problem actually is. You look for a
language to write multi-platform algorithms in, but drop haxe as an
option because it overwrites two Javascript string methods? I don't do
much Javascript so I wouldn't know which issues arise here, but if it's
something you legitimately worry about, you can always just comment out
the offending lines in your release output.

Regards
Simon

[Niel Drummond]

Can you mention an environment where String.charCodeAt does not exist, before making a big fuss about it ?

- Niel 

[Nicolas Cannasse]

Le 16/12/2011 22:14, Niel Drummond a �crit :

> Can you mention an environment where String.charCodeAt does not exist,
> before making a big fuss about it ?
>
> - Niel

The issue is that the default String.charCodeAt returns NaN when reading
outside of the string, which requires it to be typed as Float if we want
to be able to check it with Math.isNaN, which means you can no longer
use things such as myArray[myString.charCodeAt(0)] (you need to add an
necessary Std.int).

In that particular case, haXe is fixing a broken API.

Best,
Nicolas

[Niel Drummond]

That makes sense, thanks for the explanation.

- Niel

On Sat, Dec 17, 2011 at 7:01 AM, Nicolas Cannasse <ncan...@motion-twin.com> wrote:

[Martin Heidegger]

Fixing a API is breaking a API. If other frameworks use the
String.charCodeAt they might break because they rely on that "bug".

It is considered not-okay for any framework in the JavaScript
community to overwrite any basic
prototype (Array, etc. included)

So: Imho. the best way would be to replace the use of the haXe
"standard" method at compile time with a entirely different
methodcall.

"test".charCodeAt(); -> hx.StringShim.charCodeAt("test");

yours
Martin

On Dec 17, 3:34 pm, Niel Drummond <niel.drumm...@grumpytoad.org>
wrote:

> That makes sense, thanks for the explanation.
>
> - Niel
>

> On Sat, Dec 17, 2011 at 7:01 AM, Nicolas Cannasse <ncanna...@motion-twin.com

>
>
>
>
>
>
>
> > wrote:
> > Le 16/12/2011 22:14, Niel Drummond a écrit :
>
> >  Can you mention an environment where String.charCodeAt does not exist,
> >> before making a big fuss about it ?
>
> >> - Niel
>
> > The issue is that the default String.charCodeAt returns NaN when reading
> > outside of the string, which requires it to be typed as Float if we want to
> > be able to check it with Math.isNaN, which means you can no longer use

> > things such as myArray[myString.charCodeAt(0)**] (you need to add an

[Justin Donaldson]

Using a shim, you wouldn't be able to do:

"bare string".charCodeAt(0);

The same problem exists for arrays.

FYI: I haven't run into any conflicts for this, nor have I seen anyone point out an actual conflict with third party frameworks.

-justin

[Juraj Kirchheim]

Hi Martin,

The way it is now, haXe breaks a holy taboo of the JS community. But
realistically speaking, I fail to see an actual problem here. So I can
only repeat Nicolas: Can you give some practical examples, where this
is a problem?

As I have mentioned above, the two calls in question are
String::charCodeAt, which effectively alters the behaviour, and
String::substr, which actually just enforces the standard as far as I
can tell (Chrome will give you the same behaviour if you comment it
out). So as I see it, there is exactly one case, where haXe alters the
behaviour to something unexpected.
The ultimate question is not whether haXe does something "evil", but
whether this really has perceivable effects in practical scenarios.
Short of those, your point is valid, but irrelevant, because at the
current state, haXe makes a small incision at great benefits for haXe
and no known effects for JavaScript code.

@Nicolas: I've just checked (Chrome, FF, IE8), isNaN(undefined) seems
to be true in fact, as is undefined == null, so returning undefined in
charCodeAt might actually make this change unperceivable for JS
developers.
Also, as an alternative, the two "fixes" might be surrounded in #if
!no_js_fix #end, so hardliners could simply decide not to use them.

greetz
back2dos

[Nicolas Cannasse]

Le 19/12/2011 12:57, Juraj Kirchheim a �crit :

> @Nicolas: I've just checked (Chrome, FF, IE8), isNaN(undefined) seems
> to be true in fact, as is undefined == null, so returning undefined in
> charCodeAt might actually make this change unperceivable for JS
> developers.

Ah, interesting. I've made the change.

> Also, as an alternative, the two "fixes" might be surrounded in #if
> !no_js_fix #end, so hardliners could simply decide not to use them.

Yes, I am looking for a solution to do the same with all "injected"
methods.

There's not a lot but still few of them :
- Array.copy/insert/iterator/remove (added)
- String.charCodeAt/substr (modified)
- Function.bind (used by JS code generator)
- Date.now/fromTime/fromString/__class__/__name__ (added)
- Date.toString (modified)

Of course, in that case this would break all accesses either directly
from JS or when the type is Dynamic.

Best,
Nicolas

[Niel Drummond]

On Mon, Dec 19, 2011 at 4:55 PM, Nicolas Cannasse <ncan...@motion-twin.com> wrote:

Le 19/12/2011 12:57, Juraj Kirchheim a écrit :

Yes, I am looking for a solution to do the same with all "injected" methods.

There's not a lot but still few of them :
 - Array.copy/insert/iterator/remove (added)
 - String.charCodeAt/substr (modified)
 - Function.bind (used by JS code generator)
 - Date.now/fromTime/fromString/__class__/__name__ (added)
 - Date.toString (modified)

Of course, in that case this would break all accesses either directly from JS or when the type is Dynamic.

It's probably not worth trying to satisfy the pedantic JS type, because there are lots of other areas you would have cover too (like the use of __proto__ in Hash and other places). Additionally, he will come back and say that it doesn't work with Dynamic!

In js it's best to have something that works well with untyped access too, there are miles more problems with libraries using common method names like '$', than a small fix to a native API.

- Niel

[Kevin Newman]

What if someone includes a JS library that relies on that "broken API"?
Now haXe has broken the JS library.

Or what if someone includes a JS library that changes one of the base
String.prototype (et al) methods? Now that library may have broken haXe
runtime (and probably more - see first point).

That's why it's taboo to overwrite native methods in JS.

Aside: I'm actually curious about how all of this runs with "use
strict"; do you guys test with that?

Kevin N.

[Juraj Kirchheim]

> What if someone includes a JS library that relies on that "broken API"? Now
> haXe has broken the JS library.

This seems to be a hypothetical scenario. As before, practical
evidence is called for.

> Or what if someone includes a JS library that changes one of the base
> String.prototype (et al) methods? Now that library may have broken haXe
> runtime (and probably more - see first point).

What's your point? I can break jQuery, by including a JS library, that
changes jQuery's methods. I can break anything and everything. Trying
to make this hard for me will only lead to accidents like Java, where
nothing is breakable, because nothing works to start with.

To quote Flon's Law:

There does not now, nor will there ever exist, a programming
language in which it is the least bit hard to write bad programs.

> That's why it's taboo to overwrite native methods in JS.

I think we all know the reasons why this is a taboo. As pointed out,
there is a lack of practical evidence, that they apply here.

> Aside: I'm actually curious about how all of this runs with "use strict"; do
> you guys test with that?

I seriously doubt haXe output will pass JSLint.

JSLint is intended to be "The JavaScript Code Quality Tool". Code
means "source code" here. From a haXe perspective, JavaScript is not
source code, but machine language, as from a GWT or Dart or
Parenscript or CoffeeScript perspective.
More importantly, JSLint is not part of the standard, but just the
holy grail of the fanatic fraction in the JS community. It has just as
many opponents. Ext, jQuery and many other major libraries do not pass
JSLint, even though they are JavaScript source code libraries.

I only speak for myself, but I don't think haXe should or will bend to
religious beliefs in the JavaScript community, which include the
mandatoryness of passing JSLint or the total taboo of overwriting
native methods.

[Niel Drummond]

I agree, it will break in that case. But I don't think that rewriting the call at compile time is warranted.

There is some ugliness in the internals of haxe, but the benefits outweigh the negatives, and you if ever encounter an issue, it is trivial to override the STD classes. 

It would not be trivial to revert this if the compiler is changed as proposed.

- Niel 

[Cauê Waneck]

Juraj,

beautifully said! : )

2011/12/19 Juraj Kirchheim <back...@googlemail.com>

[Kevin Newman]

JS community has learned through troubled times to code defensively,
which is what all that discipline is about.

The haXe community is of course free to do as they like - but haXe will
not likely get broader use in the web-dev community with that principle
in place.

/2cents

Kevin N.

[Justin Donaldson]

http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to-jshint/

JsLint is a highly opinionated code quality tool.  It's useful if you want to write JS more like Douglas Crockford.  It's not going to help you write coherent, efficient js.

Defensive coding is all about minimizing the unknowns.  You know that whatever haxe does, it does consistently.  Haxe is also performing hundreds-to-thousands of static type/field checks every time you compile.  No js tool compares to that.  Working with haxe is like putting up walls against all the unknowns in js.  The compiler is providing more defense for you than you could on your own.  You make a very small compromise (in terms of overrides) for that security.  You also know that the contributors here haven't run across any issues with major third party js libs.  Even if there was an issue in a third party lib, it would be far easier to fix/accommodate that, than to change the entire haxe infrastructure. 

I think the rest of your fear is that you've been in the (js) wilderness for too long.  You don't have to torture yourself over trying to write effectively in such a primitive, stunted language.

-Justin

[Martin Heidegger]

I do not have a example where it is broken. And to be honest it is
ridiculous to wait for it as it will show up in a bug 2 days before
the release of a project. As do all nasty, small detail bugs. This
"religious" belief is based on experience. Prototype.js has learned
that painfully. It is in part a question if haXe does "something evil"
as it is a question for developers who see haXe code. In fact: This
whole discussion just arises because haXe does something "evil" and
not because it doesn't work at the moment.

@Nicolas
Just a thought: Why not just change the API documentation of haxes
String.charCodeAt() to: "In JavaScript it returns NaN and in other
Environments null". Every developer accessing that system will then
have to sanitize their code their code with #if js
That would remove the need to "fix" the API, the size of the generated
js would be smaller and it would be clear that this particular API is
different in different systems. As this breaks your "write-once-
deploy-everywhere" mentality you could just offer a
<Standardized>.charCodeAt(str, no) function that actually standardizes
a charCodeAt call.

[pat...@nestlabs.com]

Colleagues,

I asked the original question, I accepted the original answer, and I have since pursued other solutions.  The fact that haXe sees no reason to bend to my will and fancy doesn't really impact me much.

But I have continued to follow this thread.  I think there may be a few points here where I can share some insight.  (And for what it's worth, I have been a JavaScript developer for 16+ years.  Netscape 2 beta 1 was released in 1995, and I began to program the language on the day it was released.)

Here are some things I believe to be true:

1)  The haXe language is well designed.  It borrows from many other languages, but that is a virtue, not a fault.

2)  The versatility of the haXe language to compile to other target languages is commendable.  I want to say it has no equal, but I am not qualified to; I will instead say it offers the truest hope of universal portability that I have seen.  And that is no small feat.

3)  Despite its elegance, almost nobody really wants to be a haXe programmer.  The language designers obviously do.  And a few others have found their way to haXe.  But it is not qualitatively different enough from other post-C++ languages to intrigue most programmers.  EXCEPT for the fact of (2), above.

4)  Many people will find their way to haXe caring less about haXe than about the languages it will compile to.  (I am in this class.)  They will judge the quality of haXe by the quality of the lowest common denominator of the target languages which interest them.

5)  It is the absolute RIGHT of the designers of haXe to prioritize the development of their language in ANY way they desire.  Period.  (And veteran JavaScript programmers should expect no special treatment here.)

6)  It easy to adopt the perspective that the output of haXe is object code.  Written by machine, read by machine; humans need not worry.

7)  In direct CONFLICT with (6) above, veteran JavaScript programmers have learned through painful experience that there are no safe ways to write unsafe JavaScript and still guarantee safety.  Web scripts must often have more than one origin; sometimes even the loading order of scripts cannot be guaranteed.

8)  The haXe community does not place much value upon honoring  JavaScript best practices.  Consequently, the JavaScript community will be unlikely to place much value upon the code haXe produces.  (A shame, perhaps, if viewed from the perspective of a JavaScript developer.  But since the haXe team has undoubtedly already consulted at great length with some of the leading experts in JavaScript development with regard to strategy, surely there is no way that haXe could improve upon its JavaScript compatibility.)

9)  The posture of the haXe community feels resoundingly *young*.  Youth is a wonderful thing, and in many ways there is no substitute. But it's not the only thing.  Deep experience is also a wonderful thing, and in many ways there is no substitute.

10) The exercise is left to the reader.

cheers,

Patrick

[tom rhodes]

" But since the haXe team has undoubtedly already consulted at great length with some of the leading experts in JavaScript development with regard to strategy, surely there is no way that haXe could improve upon its JavaScript compatibility. "

i doubt that's true in all honesty. you seem to have ignored a few proposals that have been talked about in this thread though? and by safe javascript is that in line with the JSLint verifier?

[Philippe Elsass]

As a long time JS coder myself, I think haxe JS output is actually quite readable and easily maps with haxe code.

But as a moderate haxe user I'm often baffled too by the "not an issue for me" mentality of many, otherwise talented, haxe coders.

I certainly agree with the fact that haxe JS output should be improved to avoid changing the behavior of default JS methods & objects. This is something you can ignore for many haxe targets, but not for JS which is a specific context where libraries often get mixed in one page with no sandboxing mechanism.

I believe it would be possible for the compiler to replace uses of charCodeAt by another method name. I'm also very concerned by the replacement of Date.toString as it could break a lot of existing code. And haxe's Function.bind should also be renamed because the implementation adds those metas here too and it shouldn't overwrite an existing browser implementation.

Aside from that, haxe having reflection capabilities we can't avoid having additional meta information in objects - I believe this shouldn't be a problem for most libraries.

--
Philippe

[Juraj Kirchheim]

On Tue, Dec 20, 2011 at 10:37 AM, Philippe Elsass
<philipp...@gmail.com> wrote:
> As a long time JS coder myself, I think haxe JS output is actually quite
> readable and easily maps with haxe code.
>
> But as a moderate haxe user I'm often baffled too by the "not an issue for
> me" mentality of many, otherwise talented, haxe coders.

I beg to differ. It's not "not an issue for me" but "not an actual
issue". That is the whole point.
There's a couple of rules held up by one part of the JavaScript
community, that when followed avoid a number of issues. However this
does not mean, that conversely the issues they are meant to avoid will
actually arise, only because the rules themselves are not followed.
By virtue of Russell's teapot, the burden of proof lies with those
assuming the existence of actual issues.

[blackdog]

Stephane had a large issue he tackled with 3rd party libraries recently
due to overriding of default methods, so this problem requires
addressing imo.

Jslint is a non-issue as it serves to help remove the problems haxe
addresses through compilation anyway - so there's no major benefit - on
saying that anything that benefits human readability is a plus.

I think making sure we are google closure compilable (which we are
already with a few warnings) has much more value as it provides further
runtime optimisation. clojurescript is treating this as a big
feature/plus point of it's experience, like haxe it's targeting full
tier large apps.

The scripting space is chocablock with good alternatives, for me, haxe
for js should be targeted for better optimisation of large apps (js as
assembler) rather than existing conventions.

R

--
Simplicity is the ultimate sophistication. ~ Leonardo da Vinci

[Nicolas Cannasse]

> 8) The haXe community does not place much value upon honoring JavaScript
> best practices. Consequently, the JavaScript community will be unlikely
> to place much value upon the code haXe produces. (A shame, perhaps, if
> viewed from the perspective of a JavaScript developer. But since the
> haXe team has undoubtedly already consulted at great length with some of
> the leading experts in JavaScript development with regard to strategy,
> surely there is no way that haXe could improve upon its JavaScript
> compatibility.)

This point has bit evolved in the past years.

Originally I was mostly interesting in getting the JS output to actually
work and be efficient enough. I didn't care much about following X or Y
convention since the JS output is only supposed to read by the web
browser, not by actual users.

But since we got many people asking for improvements of the output -
sometimes for valid reasons, sometimes just for code nazification - I
made several changes :

- the first one was to allow custom JS output by using a haXe macro
clas, which enable power-users to customize the whole JS structure. This
enable to split your code into one js file per-package or per-class, and
to customize the way classes structures are initialization is performed.
I think it really helps people that want to integrate haXe into a larger
JS architecture but doesn't solve your point about
haXe-first-timer-reading-JS-code-output

- then we modified several times the default JS output to makes things
"nicer", such as passing google closure, but also "sanitizing" the code
output by removing all extra parenthesises, etc etc.

The only issues left at that point are :

- the usage of local-immediate-functions such as (function($this){ ....
})(this); in order to transform JS statements into expressions. And this
is planned for a fix,
see http://code.google.com/p/haxe/issues/detail?id=247

- "sandboxed" JS mode to remove all extra methods that this thread is
talking about (see http://code.google.com/p/haxe/issues/detail?id=247).
However for compatibility reasons this should maybe not be activated by
default, which would then not be seen by first-timers.

Any other suggestions on how to sexify haXe JS output are welcome.

Best,
Nicolas

[Kevin Newman]

This entire thread has made it pretty clear to me why haXe hasn't been
adopted more widely for professional use.

It's still a fun language to play with though. :-)

cheers.

Kevin N.

[Ken Rogers]

I actually find that this entire thread makes it pretty clear why Haxe should be adopted more widely for professional use.

I have a profound respect for the method in which "issues" are weighed out and handled.  The "X Compile" sector of software engineering is one of the trickiest sectors to develop tools, languages or libraries for.   

I think the Haxe community should be praised for all the epic decision making that goes in to getting something as far along as this language has come.

I have seen some very tough decisions being made over the years and I have actually learned quite a bit about how to weigh things out.

Bravo, Nicolas. Bravo, community.

Carry on,

Ken Rogers

Professional Adopter of Unprofessional Languages

[blackdog]

It's a fun language that provides, imo, some real competitive advantage
- so as long as the professionals futz about with slow/no compilers it's
all good to me.

R

[Ken Rogers]

Blackdog, you rock, man. I have seen you posting on haxe since like 2005.  It is people like you that help people like Nicolas make this language what it is today.  I had to bail out in 2005 on haxe due to job changes and general lack of time with 2 new babies.

Times have changed and I see that my opportunities with haxe are reemerging. Cross compile is more important than ever to developers(and soon, employers, imo) and ALL approaches will have to make a few compromises.  I think haxe has minimized those compromises more than anyone else out there. Very exciting times. 

[Juraj Kirchheim]

Your contribution to this thread thus far has been no more than a
couple of "what if"-s, unsubstantial statements, unbacked claims and
plain fallacies.

If you do have constructive criticism backed up by hard data, you are
more then welcome to come forward.

However, if argumentum ad populum/verecundiam and reductio ad
ridiculum is the best you have to offer, you should not only
reconsider your position, but also your general discussion culture.

[Juraj Kirchheim]

On Tue, Dec 20, 2011 at 6:07 PM, blackdog <blac...@cloudshift.cl> wrote:
>
> It's a fun language that provides, imo, some real competitive advantage
> - so as long as the professionals futz about with slow/no compilers it's
> all good to me.
>
>
> R

+1. If professionals are those who's favorite word is "professional",
then I think we're well off without them :)

[Simon Krajewski]

Am 20.12.2011 17:40, schrieb Kevin Newman:
> This entire thread has made it pretty clear to me why haXe hasn't been
> adopted more widely for professional use.

I highly doubt that the lack of professional adoption of haxe is due to
topics mentioned in this thread so far.

I think it's mostly an IDE thing and while Flash Develop is great from a
programmer's point of view, there are no designer friendly tools that
allow designers to work with haXe. If there was a user-friendly GUI tool
for haXe (like Visual Studio for WPF-related stuff) that is based on a
cross-platform markup language, haXe would surely gain a huge adoption
boost.

Regards
Simon

[Niel Drummond]

On Tue, Dec 20, 2011 at 9:46 AM, <pat...@nestlabs.com> wrote:

9)  The posture of the haXe community feels resoundingly *young*.  Youth is a wonderful thing, and in many ways there is no substitute. But it's not the only thing.  Deep experience is also a wonderful thing, and in many ways there is no substitute.

While I mostly agree with your points, I feel a little bit snubbed by reading this statement. There are some very experienced people on this list stemming from a wider and more diverse background than you, or those you will find in the js community. Experience is only worthwhile when it assimilates more than one way of thinking.

I would love to see some javascript ideologies transferred to haXe, but I don't see them as compatible. For example: Jquery's Sizzle seems to write nulls and different types into its arrays, coming from a haXe background I find this is "evil" and unacceptable, but I am sure you would find jQuery more amenable to your ideology. 

Similarly, what you find unacceptable in haxe, I find a little dirty but necessary and ultimately less of an issue than javascript's dynamic typing, lack of structured programming techniques, and last but not least x-target capability.

- Niel

[Tarwin Stroh-Spijer]

I think you all might want to look at the JS target in context. That is, what exactly you are targeting inside the "world of JS".

I understand that if you're writing JS embedded inside a site, or to be used in a widget that may be used anywhere, then haxe output may conflict in some ways.

But if it is used for things such as Node.js, a game, a full application (Sencha, WebGL something, Titanium etc), then it is unlikely to cause problems (or at least that is my understanding).

Personally, I never use haxe js output for "in page" JS, as it simply makes it more work. If there's especially large or complex tasks it makes them a breeze. This might be different if I had time to learn custom JS generators, and maybe build something into a framework (poko, ufront etc) but really, front-end JS is mostly simple glue-x-to-y and it's more easy to do that with pure jQuery anyway.

Also, stop fighting. Calling people / haxe unprofessional really does no one any good. I know a lot of good people doing a lot of good work with it and that makes it professional to me. Personally I'd call my work horridly unprofessional, but I am implementing a full haxe workflow in a silicon valley company as we speak, so that's got to count for something right? 

My 2 cents.

Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________

[tom rhodes]

i think in page has to be considered though, i've just  built a front end for a really simple cms but brought a lot of my 12 years of flash experience to it in terms of look and feel solely because i can use haxe to target JS+jQuery. i'm not saying i couldn't have done it in pure JS with jQuery but it woudl have taken me 10 times longer and would have been massively less reusable. that's probably because of my failings as a JS developer (i've only ever done wrappers or simple communication apis to enclose my flash work) but still that's why haxe is valuable to me. 

i think it should be a concern if there are possible conflicts with other JS libraries being used in the same page. i think the custom JS output macro stuff has opened up a lot of possibilities for some people with bigger brains than me to push the JS target forward though so it probably won't be a problem for long...

[Tarwin Stroh-Spijer]

I think, as has been discussed a little earlier, a "standard" custom generator for this would be perfect. That is specific for targeting different JS "platforms".

Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________

[Ken Rogers]

I think that is an ingenious solution.  There are quite a few companies that do things a bit differently based on if it is a "web app" or not.  Most recently I saw this on the Ninject downloads page. I use it to do injection for my Sifteo apps (C#).  You can see how they offer a few different types of "distros".

http://ninject.org/download.html

Offering a "JS" and a "JS for Web" target(or something similar) may give everyone what they need.

[Ken Rogers]

Or maybe "JS Web Strict" ?

[Juraj Kirchheim]

I apologize for my tone here.

Still, I find your way of approaching this discussion (and especially
your conclusion of it) unfruitful and rather insulting, but the latter
may be just my perception of things.

If you have something to say, then please do, but please take the time
to provide verifiable arguments and also to react to the counter
arguments you are confronted with. I don't think you can expect anyone
to just believe whatever you say, no matter how important you believe
it to be or how strongly you appeal to its self-evidence.
Providing concrete problems, or better yet, suggestions for workable
solutions will get us all much further, then ridiculing a thread and
even the whole haXe language.

[pat...@nestlabs.com]

I have reconsidered my last post.  I wish now that I had not raised the subjects of youth and experience.  That is the parlance of ageism, and it has no place in the civil discussion of software design.

(Using age as an indication of merit makes as little sense as using a scalar to represent a vector.)

Also, I am heartened to hear that some haXe community members understand that in JavaScript, the practice of overwriting host methods is a de facto taboo.

(Yes, of course you *can* do it.  You can also burn household trash in your fireplace.  The repercussions will be few in either case.  And constructing a formal complaint for how you are misbehaving might not show enough net gain for the law to take notice.  But it is still not the right thing to do.  It is incumbent upon the good citizen, once he realizes he's strayed, to find his way back to the right path.)

embracing truthiness,

Patrick

[Kevin Newman]

I didn't mean to offend anyone - but I can see how I what I wrote could
come off that way (tone is hard to replicate in text).

To offer criticism intended to be constructive - find ways to assimilate
the preferences, history and knowledge of existing communities (JS in
this case) into the haXe runtime design.

You will get only resistance from the participants in those parallel
communities - the very ones who will be asked to vet the quality of the
haXe runtime (in the JS example again) by so willfully ignoring their
concerns (extending native classes in this case). It may not be a
strictly technical problem, but not every problem is.

The haXe community is of course free to decide to do whatever it wants
(and those decisions are generally on good solid technical ground) - and
they surely will - but it would seem the "we know best about your
platform and community" posture is at odds with the desire to gain wider
use. Whether the decision is the correct technical decision or not isn't
even the issue at that level.

Kevin N.