"bearophile" <bearophileh...@lycos.com> wrote in message news:hqlko7$do...@digitalmars.com... > Nick Sabalausky: >> I use Haxe for any and all PHP and Flash development > > I have an OT question: Haxe and similar things add another layer between > the code you write and the program that gets run. Isn't this extra > distance (and the semantic adaptations it requires) cause of problems? For > example when you put a bug in your Haxe code. >
Sometimes I get errors from the haxe compiler, and sometimes I get errors from the PHP runtime. But if I weren't using Haxe then all the errors would be from the PHP runtime, so I count that as a net improvement. About the only problem I've seen from the extra layer of abstraction is that the PHP runtime errors show the file/line of haxe's php output instead of the file/line in the original haxe source. So you have to go to the php file that haxe generated to see where the problem occurred. However: 1. At worst, that's only a minor inconvenience. 2. It's not a completely insurmountable problem. I can think of lots of ways that problem could be mitigated, if not outright eliminated. For instance, Haxe could output a file-by-file/line-by-line mapping from the php output to the haxe source and another program could take the that info and the error message and translate back. Or PHP could add some feature or features to help in that regard (ie, something comparable to how D's "#line" feature exists to make it easy for a theoretical D preprocessor to not screw up the line numbers output by DMD). Or, in some cases, Haxe could just tighten up it's static analysis and not let the issue get to the run-time stage. Does that answer your question?