You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Nicolas Cannasse <nc...@motion-twin.com> on 2012/02/22 11:34:39 UTC
Flex adopting haXe ?
Hi,
I was asked to comment on the possibility of the Apache Flex Community
to port Flex to haXe, and use it has its main technology. Sorry for the
long mail ;)
I would say that there actually two choices to make there : one from a
technical point of view, and one from a political point of view.
From the technical point, and with all due respect to AS3, haXe
as-a-language is way ahead in terms of features. I'll not make the list
of all the improvements we made, please look at the documentation and
make your own idea about it.
Of course, haXe is a different language from AS3. In particular because
it's been designed from the very start to be able to compile and run
efficiently on different platforms (Flash, JavaScript, but also
PHP,C++,C#,Java,etc.)
Efficiently is the keyword here.
Everybody working on compilers know that running a X language on a Y
platform it's not been designed to run on is HARD. You can easily
convert it to 80% - the part that always looks easy - then the next 10%
are very hard, and the last 10% almost impossible without killing
overall performances.
The reason is simple : most of the languages (including AS3) have been
designed together with the platform/VM they run on, so adapting it to
another runtime which made different choices is like trying to fit a
square in a round hole : it doesn't fit - unless maybe you cute the
square corners.
haXe has been designed from the start to favor features that enable us
to compile it efficiently on all platforms. It doesn't mean that we are
using the lowest common denominator of all possible platforms, it's just
that we make actual design choices that enable us to have great
highlevel language features while still being able to compile them
natively and efficiently on each platform.
I'm explaining that because I know you want to target Javascript/HTML5
with Flex as well. Don't take it lightly : one good share of Flex future
is definitely there, and trying to do everything by yourself is
definitely a very hard road to take.
I'm not a Flex expert, and to be honest I have never used it, so there
might be pending issues and technical questions that you have regarding
the best way to port Flex to haXe : feel free to ask them there, I'll
try to answer them to my best.
Now from the political point of view :
First, let me say that in the Flash world, haXe is one of the most
active open source community and we are very happy to welcome Apache
Flex developers as a open source sister community.
I've personally always been a huge support of open source philosophy :
some of you might also have used MTASC a long time ago, I hope you
enjoyed its quality and speed and that you will find the same enjoyment
at using haXe - if you use it at some point.
You are now an independent community, which is great : you can now make
your own choices, which should not be based on marketing, branding or
overselling of a given tech, but on technical points.
Adobe is currently pressured and has to make hard choices. You don't
know what they will be, you don't know where they will go, and if they
say Left, it might finally be Right after a few months. I don't blame
them : they're a commercial company, they have their own agenda to take
care of, it's just the way it is.
OTOH, haXe community has no hidden agenda : we thrive for the best
technology, everything is open source, discussions and patches are
welcome. We of course need to be conservative in terms of language
features in order to not bloat the compiler and to keep the language
elegant and coherent, so in the past years we've been improving things
step by step, without either hurrying or slowing down.
In the past year, while Flash has suffered several drawbacks, haXe has
definitely gained a huge momentum. In great part this is thanks to its
community which has been writing code, but also making things more
visible / accessible for developers.
For instance http://haxenme.org is a great example of it : haXe now
enables to write-once compile-natively-everywhere on iOS, Android,
Flash, Desktop and much more. You could do it before, but it's now much
more easy, and people know about it.
Sorry if I feel to much enthusiast about it, but I'm definitely excited
about the times to come.
Momentum is an important things for technology, especially when it's
open source : it keeps developers motivated, it brings new people to the
community, it helps making the right choices at the good time.
I'm definitely sure that haXe momentum can help the Flex community, and
vice-versa.
Now I guess you have two distincts choices left : continue to follow
Adobe plans or adopt another technology (haXe or something else) and
move forward.
I can't decide for you, but I can at least answer the questions you
might have.
Best,
Nicolas
Re: Flex adopting haXe ?
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 23/02/2012 02:01, Nicolas Cannasse wrote:
> Le 22/02/2012 17:56, Martin Heidegger a écrit :
>
>>> in haXe case, "this" is always the object in which the local function
>>> function has been declared, not the one on which the event listener is
>>> added.
>>
>> Did you see my example code? I am not sure how to name that particular
>> difference.
>>
>> In ActionScript you can pass a method reference like this
>>
>> addEventListener(Event.COMPLETE, this.onComplete);
>>
>> And any caller of this anonymous function would be calling the this
>> where its coming from.
>
> Yes, closure creation is supported by haXe as well.
>
> Best,
> Nicolas
Uh *facepalm* I had a typo in the short sample code that I pulled together.
thanks: those closures are awesome, just what I need :)
yours
Martin.
Re: Flex adopting haXe ?
Posted by Nicolas Cannasse <nc...@motion-twin.com>.
Le 22/02/2012 17:56, Martin Heidegger a écrit :
>> in haXe case, "this" is always the object in which the local function
>> function has been declared, not the one on which the event listener is
>> added.
>
> Did you see my example code? I am not sure how to name that particular
> difference.
>
> In ActionScript you can pass a method reference like this
>
> addEventListener(Event.COMPLETE, this.onComplete);
>
> And any caller of this anonymous function would be calling the this
> where its coming from.
Yes, closure creation is supported by haXe as well.
Best,
Nicolas
Re: Flex adopting haXe ?
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 23/02/2012 00:48, Nicolas Cannasse wrote:
> Well, speaking of the niceties of haXe, we have
> --dead-code-elimination now that will only include in the output the
> methods/fields actually used by the application.
That is treating the symptom not the problem. The dead-code-elimination
(like unused protected functions) is a problem if you load subsystems at
runtime that adress other parts of the same Structure. Things like
Reflections become unreliable - tiny inconsistencies. I find it very
good that I can define a hard reference just to the methods I need.
Splitting them up in is a lot like splitting classes up in files -
theoretically you put them all in one put but there are good reasons for
this separation.
> The idea of macros is that you cannot modify haXe syntax, but you can
> enrich semantics, so you could have the following :
>
> var b : String = "foo";
> var a : Xml = XML("<{b}></{b}>");
I see - very powerful system I must say - even thought the result is not
a comfortable to read. These particular two lines of code look a lot
like magic if someone from another programming language (say
ActionScript) saw it the first time. But I can see where you are coming
from.
> Yes, haXe also automatically create method closures, the same AS3
> does. It also do it automatically for JS target for instance.
>
> The part I was refering is when using "this" in a local function, such
> as :
>
> class Loader {
> function load() {
> myMC.addEventListener(Event.COMPLETE,function(e) {
> this.onComplete();
> });
> }
> function onComplete() {
> }
> }
>
> in haXe case, "this" is always the object in which the local function
> function has been declared, not the one on which the event listener is
> added.
Did you see my example code? I am not sure how to name that particular
difference.
In ActionScript you can pass a method reference like this
addEventListener(Event.COMPLETE, this.onComplete);
And any caller of this anonymous function would be calling the this
where its coming from.
> That depends on documentation tool, this is just a matter of XML
> manipulation, no showstopper here either.
I see - then this would mean a bit of work.
> Thanks, definitely doable with macros, since it allows you to write
> custom compile time code generators directly in haXe, without
> modifying the compiler itself.
Cool. Sounds good.
yours
Martin.
Re: Flex adopting haXe ?
Posted by Nicolas Cannasse <nc...@motion-twin.com>.
Le 22/02/2012 15:30, Martin Heidegger a écrit :
> The point of the functions-files is that you don't create huge code
> dependencies: Say you create a dependency to StringTools.endsWith() then
> the compiler better compiles all functions of StringTools into the swf
> so it can be loaded properly. In AS3: If i just create a dependency to
> one function file (without a prefixing class) then it will just include
> this one function, once. Allows a slimmer swf, doesn't it? Having import
> statics will not solve that problem, right?
Well, speaking of the niceties of haXe, we have --dead-code-elimination
now that will only include in the output the methods/fields actually
used by the application.
> Aside from that, I read a little into the Macro language and I wonder
> that is really implementable, I think specially about things like:
>
> var b: String = "foo";
> var a: XML = <{b}></{b}>;
> // <foo></foo>
>
> or
>
> var a: XML = <b/>;
> a = a + <c/>;
> // <b/><c/>
>
> Can that be implemented with Macros?
The idea of macros is that you cannot modify haXe syntax, but you can
enrich semantics, so you could have the following :
var b : Srting = "foo";
var a : Xml = XML("<{b}></{b}>");
>> We have "real this" support in local functions : it means it's the
>> "this" of the class in which the local function is declared, not the
>> one of the "current this" in which context this function which be
>> called. This gives real strict typing since we don't know the latter.
>
> The AS3 compiler creates automatic method closures. I am not entirely
> sure how they are treated by the Flash Player. It seems I lack the
> vocabulary to describe the difference properly so I attached a zip. The
> haxe version will display "b" where the as3 version displays "a". I hope
> with this I can make myself clear.
Yes, haXe also automatically create method closures, the same AS3 does.
It also do it automatically for JS target for instance.
The part I was refering is when using "this" in a local function, such as :
class Loader {
function load() {
myMC.addEventListener(Event.COMPLETE,function(e) {
this.onComplete();
});
}
function onComplete() {
}
}
in haXe case, "this" is always the object in which the local function
function has been declared, not the one on which the event listener is
added.
> This "logic" is very important through all AS3 code I have ever seen.
> The "JavaScript" approach of handling "this" requires a lot of
> rethinking within the AS3 community as many concepts won't work anymore
> as expected - or just with hacks.
Agreed.
>> Not really an issue there, the documentation format is flexible and
>> you can get your raw /** ... **/ comments as XML output and deal with
>> it as you wish.
>
> But it doesn't do it out of the box? I mean: translation? asdoc allowed
> using additional xml files to inject translation based on property flags.
That depends on documentation tool, this is just a matter of XML
manipulation, no showstopper here either.
> Binding essentially modifies the code to send events on change. So if
> you write
>
> [Bindable]
> public var foo: String;
>
> then it makes something like
> public function get foo():String {
> return _barMD5;
> }
> public function set foo(bar:String):void {
> if( _barRandomKey != bar ) {
> dispatchEvent( new PropertyChangeEvent("propertyChange", _barRandomKey,
> _barRandomKey = bar) );
> }
> }
>
> and if the class wasn't extending EventDispatcher before than it will be
> "modifed" to do it now. Horrible mechanism..... but comfortable to use.
Thanks, definitely doable with macros, since it allows you to write
custom compile time code generators directly in haXe, without modifying
the compiler itself.
Best,
Nicolas
Re: Flex adopting haXe ?
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 22/02/2012 21:02, Nicolas Cannasse wrote:
> Well, I think most of them comes down to design choices. Instead of
> focusing on what AS3 have and haXe does not, maybe focusing on what
> haXe has and AS3 haven't would also be useful ? Unless it's a clear
> showstopper feature of course.
From the AS3 developers (my) point of view the list of things that haXe
is not capable of is more important as it will interrupt our current
concepts. That is why I focused on it. I think its important to know
about it in this list.
>> *) Standalone variables/constants/function files outside of a class
>> context. I found them very liberating and as far as I can tell: haXe
>> only allows class/ENum/ alike.
>
> We have plans for Java-like "import statics" for haXe 3.0 : this will
> enable you to import all statics of a given class into the global
> namespace.
The point of the functions-files is that you don't create huge code
dependencies: Say you create a dependency to StringTools.endsWith() then
the compiler better compiles all functions of StringTools into the swf
so it can be loaded properly. In AS3: If i just create a dependency to
one function file (without a prefixing class) then it will just include
this one function, once. Allows a slimmer swf, doesn't it? Having import
statics will not solve that problem, right?
> We have haxe.xml.Fast API which is maybe not as much powerful as E4X
> but still very convenient for quick XML parsing. It should be possible
> to write a quite complete E4X equivalent with haXe macros.
>
>
> Keep in mind also that XML is being replaced in lot of cases by JSON.
Specially due to the lack of proper documentation and validation of JSON
(namespace...) - xml will stay a standard that is used in enterprise
environments still for a while. Specially with namespaces e4x is a
blessing. However: This just means that we would need to help with e4x
macros for haXe.
Aside from that, I read a little into the Macro language and I wonder
that is really implementable, I think specially about things like:
var b: String = "foo";
var a: XML = <{b}></{b}>;
// <foo></foo>
or
var a: XML = <b/>;
a = a + <c/>;
// <b/><c/>
Can that be implemented with Macros?
> Is this really a showstopper feature ? :)
Initializers are not a show-stopper but incredibly handsome on the daily
job :)
> We have "real this" support in local functions : it means it's the
> "this" of the class in which the local function is declared, not the
> one of the "current this" in which context this function which be
> called. This gives real strict typing since we don't know the latter.
The AS3 compiler creates automatic method closures. I am not entirely
sure how they are treated by the Flash Player. It seems I lack the
vocabulary to describe the difference properly so I attached a zip. The
haxe version will display "b" where the as3 version displays "a". I hope
with this I can make myself clear.
This "logic" is very important through all AS3 code I have ever seen.
The "JavaScript" approach of handling "this" requires a lot of
rethinking within the AS3 community as many concepts won't work anymore
as expected - or just with hacks.
>
>> *) Namespaces: While I don't "like" namespaces particularly, porting
>> Flex to haXe might be difficult without it.
>
> Indeed. But Javascript does not have namespaces either, so if you want
> to compile to JS you'll have to deal with it somehow.
Theoretically namespaces are hackable using prefixes. Even though they
would consume quite some javascript size I guess.
> We have a pending draft for access control customization. It's not yet
> implemented but could be done in matter of days, please check it there :
> http://haxe.org/manual/acl
That is a very nice draft. Looks awesome!
>
>> *) Compiling the "asdoc" to different locales
>
> Not really an issue there, the documentation format is flexible and
> you can get your raw /** ... **/ comments as XML output and deal with
> it as you wish.
But it doesn't do it out of the box? I mean: translation? asdoc allowed
using additional xml files to inject translation based on property flags.
>> *) Documentation on Meta-tags
>
> Like http://haxe.org/manual/metadata ?
I am talking about a way to document the meta data (like [Style]) use.
that can be represented in the asdocs. In UIComponent for example all
documentation of Styles [1] can be found inline in the code [2] and is
automatically created.
>
>> *) Binding
>
> I'm not familiar with Binding, but it needs to either be translated to
> property access or another corresponding low level feature. I guess
> this can be achieved with compiletime code generation thanks to
> macros, and again using such not-native scheme will enable it to work
> on all platforms supported by haXe as well.
Binding essentially modifies the code to send events on change. So if
you write
[Bindable]
public var foo: String;
then it makes something like
public function get foo():String {
return _barMD5;
}
public function set foo(bar:String):void {
if( _barRandomKey != bar ) {
dispatchEvent( new PropertyChangeEvent("propertyChange",
_barRandomKey, _barRandomKey = bar) );
}
}
and if the class wasn't extending EventDispatcher before than it will be
"modifed" to do it now. Horrible mechanism..... but comfortable to use.
> We have support for bitmaps so far, by using :
>
> @:bitmap("myfile.png") class Bmp extends flash.display.BitmapData {}
That is a big feature that was essential to many parts of the code.
Embed fonts are very important. I have read of hxswfml but I am not sure
how far that would go.
yours
Martin.
[1]
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/core/UIComponent.html#styleSummary
[2]
https://svn.apache.org/repos/asf/incubator/flex/trunk/frameworks/projects/framework/src/mx/core/UIComponent.as
(see [Style...] )
Re: Flex adopting haXe ?
Posted by Avinash Narayanan <av...@gmail.com>.
Hi Nicolas,
Speaking from a purely enterprise point of view, in what way is haXe going
to help me in terms of scale, support, dev tools. Pardon me because I
haven't done my homework on haXe. Also, how is this different from
rhomobile?
Thanks
Avinash Y
On Wed, Feb 22, 2012 at 5:32 PM, Nicolas Cannasse <ncannasse@motion-twin.com
> wrote:
> Le 22/02/2012 12:35, Martin Heidegger a écrit :
>
> However I used ActionScript a lot in the past years and found ways to
>> work with it that are unlike the work with haXe because when I recently
>> tried out haXe again I was bothered by a few language features that I
>> use heavily in ActionScript and have not found a good equivalent in haXe
>> (in other words: they are missing in haXe - aren't they?):
>>
>
> Well, I think most of them comes down to design choices. Instead of
> focusing on what AS3 have and haXe does not, maybe focusing on what haXe
> has and AS3 haven't would also be useful ? Unless it's a clear showstopper
> feature of course.
>
>
> *) Standalone variables/constants/function files outside of a class
>> context. I found them very liberating and as far as I can tell: haXe
>> only allows class/ENum/ alike.
>>
>
> We have plans for Java-like "import statics" for haXe 3.0 : this will
> enable you to import all statics of a given class into the global namespace.
>
>
> *) e4x: Its such a pleasure to use in AS3.
>>
>
> We have haxe.xml.Fast API which is maybe not as much powerful as E4X but
> still very convenient for quick XML parsing. It should be possible to write
> a quite complete E4X equivalent with haXe macros.
>
> Keep in mind also that XML is being replaced in lot of cases by JSON.
>
>
> *) Default initialized properties:
>> class ABC {
>> public var x: int = 1;
>> }
>>
>
> Is this really a showstopper feature ? :)
>
>
> *) Working "this" in function references: Using function references has
>> become such a normal thing in AS3 that I wouldn't know how to implement
>> a similar design with without them.
>>
>
> We have "real this" support in local functions : it means it's the "this"
> of the class in which the local function is declared, not the one of the
> "current this" in which context this function which be called. This gives
> real strict typing since we don't know the latter.
>
>
> *) Namespaces: While I don't "like" namespaces particularly, porting
>> Flex to haXe might be difficult without it.
>>
>
> Indeed. But Javascript does not have namespaces either, so if you want to
> compile to JS you'll have to deal with it somehow.
>
> We have a pending draft for access control customization. It's not yet
> implemented but could be done in matter of days, please check it there :
> http://haxe.org/manual/acl
>
>
> *) Compiling the "asdoc" to different locales
>>
>
> Not really an issue there, the documentation format is flexible and you
> can get your raw /** ... **/ comments as XML output and deal with it as you
> wish.
>
> *) Documentation on Meta-tags
>>
>
> Like http://haxe.org/manual/**metadata <http://haxe.org/manual/metadata> ?
>
> *) Binding
>>
>
> I'm not familiar with Binding, but it needs to either be translated to
> property access or another corresponding low level feature. I guess this
> can be achieved with compiletime code generation thanks to macros, and
> again using such not-native scheme will enable it to work on all platforms
> supported by haXe as well.
>
>
> *) Assets (Fonts!) loaded compiled through meta-data
>>
>
> We have support for bitmaps so far, by using :
>
> @:bitmap("myfile.png") class Bmp extends flash.display.BitmapData {
> }
>
> Other assets could be easily added as well, there's already third party
> tools for that.
>
> Best,
> Nicolas
>
RE: Flex adopting haXe ?
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>> *) e4x: Its such a pleasure to use in AS3.
>We have haxe.xml.Fast API which is maybe not as much powerful as E4X but still very convenient for quick XML parsing. It should be possible to write a quite complete E4X equivalent with haXe macros.
>Keep in mind also that XML is being replaced in lot of cases by JSON.
On a quick side note, 3 of the largest Flex enterprise apps in existence use XML over HTTP exclusively for their data transfer needs. Losing some form of e4x support means losing those apps which collectively employ near a thousand flex developers. Can't see that we have a community so big right now we could lose that.
Mike
Re: Flex adopting haXe ?
Posted by Robert Cesaric <ro...@cesaric.com>.
On Feb 22, 2012, at 10:45 AM, Left Right wrote:
> I honestly believe that a concept of 3 different nulls (null, undefined and
> false) in ECMAScript is... well, just yet another thing ECMAScript did
> wrong. By reducing it to 2 nulls HaXe did it some justice, but I'd still be
> happier with only one :P
I understand the point but I do have to admit that I like having the different possible values. The context of null or undefined to keep track of VO properties has been really helpful in ORM's when you have DB's like MySQL that accept null values.
Shortened example:
public class UserVO extends AbstractVO
{
private var _age:*;
public function get age():Number
{
return _age;
}
public function set age(value:Number):void
{
_age = value;
}
}
The AbstractVO Class has some helper functions and a writeExternal() hook that allows us recreate a basic VO and determine which private properties to ignore (undefined), set as null in the DB or set a legitimate value to (which could be 'false') for CRUD operations.
-Rob
By the way I've enjoyed reading your feedback. Great insight.
Re: Flex adopting haXe ?
Posted by Left Right <ol...@gmail.com>.
I honestly believe that a concept of 3 different nulls (null, undefined and
false) in ECMAScript is... well, just yet another thing ECMAScript did
wrong. By reducing it to 2 nulls HaXe did it some justice, but I'd still be
happier with only one :P
And, you are really arguing on unimportant issues - how many poor victims
of Sun and Oracle write that x == null every single minute of their working
days? I think that if they can, we could've done that too... Actually, in
this regard Lisp offers a good solution - just use a function: (null x) or
(zerop x) and so on! :P
Re comparison vs cast - that's precisely the same speed, tested in depth on
many platforms, I would even assume that the ARM or MIR or w/e it's called
what gets generated from that expression is the same. It is also the exact
same count of bytecode instructions. But the time used to execute either
set of instructions is _absolutely negligible_ even if you are writing a
highly optimized algorithm, such as to do cryptography or image processing
- it doesn't matter! Trust me, I'm almost an engineer! (well, I did some
cryptography, seriously).
The [] vs new Array() - is by the virtue of ASC, it is true, that there's a
difference in performance, but it shouldn't be like that. If ASC was
smarter, it wouldn't matter. It's not like in C++ you'd allocate on heap vs
allocate on stack etc - it's really a matter of writing a sane compiler.
HaXe provides very basic documentation API - it only gathers the comments
and it would expose it to any program willing to process them. That's why I
mentioned NaturalDocs. The later, however, is much more robust tool then
ASDoc. You are just thinking very specific to AS3, not realizing there may
be entirely different solution that both covers your needs, and, may,
potentially create other interesting opportunities.
XML and JSON are equally bad formats :) I kind of fail to even notice the
difference. So, arguing in favor of one of them is like choosing the kind
of punishment for yourself - I'm not sure I'd like it either way.
Re' your particular example - I'd be rather thinking about a printf-like
function that would format strings, so that you could avoid verbose string
concatenation. To help that a bit, HaXe supports multiline string literals,
so given your example, the theoretical printf could be something like:
XML.parse( printf(
"<%1>
%2
</%1>", "foo", "bar")) => <foo>bar</foo>
One step away from XML.printfAndParse(
"<%1>
%2
</%1>", "foo", "bar") => <foo>bar</foo>
Kind of looks OK to me... :)
Re: Flex adopting haXe ?
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
I did performance tests ... but these things change very often.
My understanding is that there is no casting going on. It is just a test
if the "memory" at x is filled or not.
However at a==null it tries to verify if statement a is same as
statement b putting each in a memory.
yours
Martin.
On 23/02/2012 00:25, David Arno wrote:
>> From: Martin Heidegger [mailto:mh@leichtgewicht.at]
>> Sent: 22 February 2012 15:18
>> Also another thing is that
>>
>> if(a == null) is slower than if(a) .... at least compiled with mxmlc.
> Is it really? I didn't know that.
>
> Writing code that enables a cast + comparison to happen quicker than a
> direct comparison takes some doing! :/
>
> David.
>
>
>
Re: Flex adopting haXe ?
Posted by Nicolas Cannasse <nc...@motion-twin.com>.
Le 22/02/2012 19:31, Martin Heidegger a écrit :
> Thanks for explaining that, Gordon. I guess everybody wonders why the
> compiler doesn't make use of those opcodes in the the other syntax.
>
> yours
> Martin.
For the record, haXe compiler does.
It's 4 times faster and uses less bytes.
There are actually many of these tricks that the AS3 compiler doesn't
exploit, some of them that they can't even do because it might change
some very rare corner cases.
Best,
Nicolas
RE: Flex adopting haXe ?
Posted by Gordon Smith <go...@adobe.com>.
I'll try to make it happen in Falcon.
- Gordon Smith, Falcon team, Adobe
-----Original Message-----
From: Martin Heidegger [mailto:mh@leichtgewicht.at]
Sent: Wednesday, February 22, 2012 10:31 AM
To: flex-dev@incubator.apache.org
Subject: Re: Flex adopting haXe ?
Thanks for explaining that, Gordon. I guess everybody wonders why the compiler doesn't make use of those opcodes in the the other syntax.
yours
Martin.
On 23/02/2012 03:25, Gordon Smith wrote:
> Flash Player has special newarray and newobject bytecodes that are used for array literals like [ 1, 2, 3 ] and object literals like { a: 1, b: 2, c: 3 } and are faster than a generic constructor call. That's why the coding guidelines for Flex recommend using the literal syntax rather than new Array() or new Object().
>
> - Gordon Smith, Falcon team, Adobe
>
> -----Original Message-----
> From: Roland Zwaga [mailto:roland@stackandheap.com]
> Sent: Wednesday, February 22, 2012 7:29 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex adopting haXe ?
>
>>> From: Martin Heidegger [mailto:mh@leichtgewicht.at]
>>> Sent: 22 February 2012 15:18
>>> Also another thing is that
>>>
>>> if(a == null) is slower than if(a) .... at least compiled with mxmlc.
>> Is it really? I didn't know that.
>>
>> Writing code that enables a cast + comparison to happen quicker than
>> a direct comparison takes some doing! :/
>
> I'm hoping that Falcon wil emit some more sane opcodes as well.
> Actionscript is rife with such weird performance behaviors.
>
> Apparently this:
> var array:Array = [];
> is faster than:
> var array:Array = new Array();
>
> There's plenty more examples like that...
>
>
Re: Flex adopting haXe ?
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
Thanks for explaining that, Gordon. I guess everybody wonders why the
compiler doesn't make use of those opcodes in the the other syntax.
yours
Martin.
On 23/02/2012 03:25, Gordon Smith wrote:
> Flash Player has special newarray and newobject bytecodes that are used for array literals like [ 1, 2, 3 ] and object literals like { a: 1, b: 2, c: 3 } and are faster than a generic constructor call. That's why the coding guidelines for Flex recommend using the literal syntax rather than new Array() or new Object().
>
> - Gordon Smith, Falcon team, Adobe
>
> -----Original Message-----
> From: Roland Zwaga [mailto:roland@stackandheap.com]
> Sent: Wednesday, February 22, 2012 7:29 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex adopting haXe ?
>
>>> From: Martin Heidegger [mailto:mh@leichtgewicht.at]
>>> Sent: 22 February 2012 15:18
>>> Also another thing is that
>>>
>>> if(a == null) is slower than if(a) .... at least compiled with mxmlc.
>> Is it really? I didn't know that.
>>
>> Writing code that enables a cast + comparison to happen quicker than a
>> direct comparison takes some doing! :/
>
> I'm hoping that Falcon wil emit some more sane opcodes as well.
> Actionscript is rife with such weird performance behaviors.
>
> Apparently this:
> var array:Array = [];
> is faster than:
> var array:Array = new Array();
>
> There's plenty more examples like that...
>
>
RE: Flex adopting haXe ?
Posted by Gordon Smith <go...@adobe.com>.
Flash Player has special newarray and newobject bytecodes that are used for array literals like [ 1, 2, 3 ] and object literals like { a: 1, b: 2, c: 3 } and are faster than a generic constructor call. That's why the coding guidelines for Flex recommend using the literal syntax rather than new Array() or new Object().
- Gordon Smith, Falcon team, Adobe
-----Original Message-----
From: Roland Zwaga [mailto:roland@stackandheap.com]
Sent: Wednesday, February 22, 2012 7:29 AM
To: flex-dev@incubator.apache.org
Subject: Re: Flex adopting haXe ?
>
> > From: Martin Heidegger [mailto:mh@leichtgewicht.at]
> > Sent: 22 February 2012 15:18
> > Also another thing is that
> >
> > if(a == null) is slower than if(a) .... at least compiled with mxmlc.
> Is it really? I didn't know that.
>
> Writing code that enables a cast + comparison to happen quicker than a
> direct comparison takes some doing! :/
I'm hoping that Falcon wil emit some more sane opcodes as well.
Actionscript is rife with such weird performance behaviors.
Apparently this:
var array:Array = [];
is faster than:
var array:Array = new Array();
There's plenty more examples like that...
Re: Flex adopting haXe ?
Posted by Roland Zwaga <ro...@stackandheap.com>.
>
> > From: Martin Heidegger [mailto:mh@leichtgewicht.at]
> > Sent: 22 February 2012 15:18
> > Also another thing is that
> >
> > if(a == null) is slower than if(a) .... at least compiled with mxmlc.
> Is it really? I didn't know that.
>
> Writing code that enables a cast + comparison to happen quicker than a
> direct comparison takes some doing! :/
I'm hoping that Falcon wil emit some more sane opcodes as well.
Actionscript is rife with such weird performance behaviors.
Apparently this:
var array:Array = [];
is faster than:
var array:Array = new Array();
There's plenty more examples like that...
RE: Flex adopting haXe ?
Posted by David Arno <da...@davidarno.org>.
> From: Martin Heidegger [mailto:mh@leichtgewicht.at]
> Sent: 22 February 2012 15:18
> Also another thing is that
>
> if(a == null) is slower than if(a) .... at least compiled with mxmlc.
Is it really? I didn't know that.
Writing code that enables a cast + comparison to happen quicker than a
direct comparison takes some doing! :/
David.
Re: Flex adopting haXe ?
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 23/02/2012 03:29, Alex Harui wrote:
> On 2/22/12 7:18 AM, "Martin Heidegger"<mh...@leichtgewicht.at> wrote:
>
>> Also another thing is that
>>
>> if(a == null) is slower than if(a) .... at least compiled with mxmlc.
> Did you try if(a === null)
> IIRC, there are lots of things going on when you use "==".
I created the test [1] again and it seems like there was some
improvement in a later version (god knows which).
Now the performance is pretty much same.
yours
Martin.
[1] http://wonderfl.net/c/w4Ai
Re: Flex adopting haXe ?
Posted by Alex Harui <ah...@adobe.com>.
On 2/22/12 7:18 AM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
>
> Also another thing is that
>
> if(a == null) is slower than if(a) .... at least compiled with mxmlc.
Did you try if(a === null)
IIRC, there are lots of things going on when you use "==".
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Flex adopting haXe ?
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 23/02/2012 00:13, David Arno wrote:
> read into coding with haXe...
>
> The problem with your examples Martin is that you have the resultant code
> equivalent slightly wrong unfortunately and this slight difference can be
> the cause of problems. The correct version is:
>
> var a: String= ...;
> return a || "b";
> // equals
> return !(a == null || a == "") ? a : "b";
>
> Whilst nowhere near as bad as JavaScript, the way that ActionScript will
> implicitly cast anything to a boolean is a source of some horrible bugs.
> Remember that null, 0 and "" all cast to false. So:
>
> function f(p1:Object)
> {
> // initialise p to a new object if null
> p1 ||= {};
> ...
> }
>
> breaks if f(false) or f(0) are called. This was a real-world bug with AS3
> Signals at one point I believe.
>
> Whilst ||= looks succinct, it is dangerous to use. We have banned it where I
> work therefore and doing "if (obj != null)" rather than "if (obj)" is
> mandatory for us. The improved reliability of the code outweighs the slight
> disadvantage of longer syntax IMO.
>
> David.
Hello David,
I am aware of that definition and I use that logic just for variables of
custom types that can not be
0 but just null/undefined. Also it doesn't matter for internal data
holders. I am also aware that
null and undefined are not the same. I use it specially for object
pooling a lot and it allows lazy initialization
with relatively few code.
Also another thing is that
if(a == null) is slower than if(a) .... at least compiled with mxmlc.
yours
Martin.
RE: Flex adopting haXe ?
Posted by David Arno <da...@davidarno.org>.
> From: Martin Heidegger [mailto:mh@leichtgewicht.at]
> Sent: 22 February 2012 14:55
> I just remembered another thing that makes me a little mad every time I
read into coding with haXe...
The problem with your examples Martin is that you have the resultant code
equivalent slightly wrong unfortunately and this slight difference can be
the cause of problems. The correct version is:
var a: String= ...;
return a || "b";
// equals
return !(a == null || a == "") ? a : "b";
Whilst nowhere near as bad as JavaScript, the way that ActionScript will
implicitly cast anything to a boolean is a source of some horrible bugs.
Remember that null, 0 and "" all cast to false. So:
function f(p1:Object)
{
// initialise p to a new object if null
p1 ||= {};
...
}
breaks if f(false) or f(0) are called. This was a real-world bug with AS3
Signals at one point I believe.
Whilst ||= looks succinct, it is dangerous to use. We have banned it where I
work therefore and doing "if (obj != null)" rather than "if (obj)" is
mandatory for us. The improved reliability of the code outweighs the slight
disadvantage of longer syntax IMO.
David.
Re: Flex adopting haXe ?
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
<soft rant>
I just remembered another thing that makes me a little mad every time I
read into coding with haXe:
var a: String= ...;
return a || "b";
// equals
return a != null ? a : "b";
is so incredibly comfortable in ActionScript3. And it can be 100%
syntatically right. And the ||= is even more
awesome:
return inst ||= "b";
// equals:
return inst != null ? inst : inst = "b";
A lot less code with exact and easy to understand meaning.
</soft rant>
yours
Martin.
Re: Flex adopting haXe ?
Posted by Nicolas Cannasse <nc...@motion-twin.com>.
Le 22/02/2012 12:35, Martin Heidegger a écrit :
> However I used ActionScript a lot in the past years and found ways to
> work with it that are unlike the work with haXe because when I recently
> tried out haXe again I was bothered by a few language features that I
> use heavily in ActionScript and have not found a good equivalent in haXe
> (in other words: they are missing in haXe - aren't they?):
Well, I think most of them comes down to design choices. Instead of
focusing on what AS3 have and haXe does not, maybe focusing on what haXe
has and AS3 haven't would also be useful ? Unless it's a clear
showstopper feature of course.
> *) Standalone variables/constants/function files outside of a class
> context. I found them very liberating and as far as I can tell: haXe
> only allows class/ENum/ alike.
We have plans for Java-like "import statics" for haXe 3.0 : this will
enable you to import all statics of a given class into the global namespace.
> *) e4x: Its such a pleasure to use in AS3.
We have haxe.xml.Fast API which is maybe not as much powerful as E4X but
still very convenient for quick XML parsing. It should be possible to
write a quite complete E4X equivalent with haXe macros.
Keep in mind also that XML is being replaced in lot of cases by JSON.
> *) Default initialized properties:
> class ABC {
> public var x: int = 1;
> }
Is this really a showstopper feature ? :)
> *) Working "this" in function references: Using function references has
> become such a normal thing in AS3 that I wouldn't know how to implement
> a similar design with without them.
We have "real this" support in local functions : it means it's the
"this" of the class in which the local function is declared, not the one
of the "current this" in which context this function which be called.
This gives real strict typing since we don't know the latter.
> *) Namespaces: While I don't "like" namespaces particularly, porting
> Flex to haXe might be difficult without it.
Indeed. But Javascript does not have namespaces either, so if you want
to compile to JS you'll have to deal with it somehow.
We have a pending draft for access control customization. It's not yet
implemented but could be done in matter of days, please check it there :
http://haxe.org/manual/acl
> *) Compiling the "asdoc" to different locales
Not really an issue there, the documentation format is flexible and you
can get your raw /** ... **/ comments as XML output and deal with it as
you wish.
> *) Documentation on Meta-tags
Like http://haxe.org/manual/metadata ?
> *) Binding
I'm not familiar with Binding, but it needs to either be translated to
property access or another corresponding low level feature. I guess this
can be achieved with compiletime code generation thanks to macros, and
again using such not-native scheme will enable it to work on all
platforms supported by haXe as well.
> *) Assets (Fonts!) loaded compiled through meta-data
We have support for bitmaps so far, by using :
@:bitmap("myfile.png") class Bmp extends flash.display.BitmapData {
}
Other assets could be easily added as well, there's already third party
tools for that.
Best,
Nicolas
Re: Flex adopting haXe ?
Posted by Nicolas Cannasse <nc...@motion-twin.com>.
Le 22/02/2012 15:33, ganaraj p r a écrit :
> Thanks Nicolas,
>
> I was the one who mentioned you in a post and wanted your inputs on "How we
> could go about porting Flex to Haxe?".. I assumed that since you built Haxe
> ( duh! ) and that since Haxe is inspired by AS3, you would be able to
> provide some deep insights into the migration of Flex to Haxe.. If we even
> go ahead with it. These are a few questions that come to my mind..
Hi,
> 1 ) I know Haxe is a budding and growing community. Has anyone attempted to
> get Flex onto Haxe? In terms of porting! Have you ever considered doing it
> ( Since it seems like a logical step to get more traction into the language
> itself! ) , starting it ?
I think David Arno have thought about doing it. I guess he had some
issues that I think are currently being resolved.
Not being a Flex user myself, I'm only here to answers questions and
give you advices if at some time you want to do this port. I'll not
myself write code.
> 2 ) Can you see any pitfalls of porting this huge mammoth (from the top of
> your head! )?
a) huge codebase with dependencies, takes a while until something
actually compiles, which need a small team of motivated people to get there
b) find ways to map AS3-specific behaviors into haXe equivalents, but I
guess this can be resolved with discussions. I can help here.
> 3 ) If we are going to go down the cross compilation route we have
> primarily 2 choices. Dart or Haxe. Why should we choose Haxe over Dart? Can
> you give us any insights and points to choose Haxe over dart? One of them ,
> I can already guess is that Haxe is closer to AS3 than Dart is... Any other
> advantages?
a) haXe is ready, been there for years
b) haXe has a Flash target, Dart doesn't
c) haXe targets mobiles (natively), Dart doesn't
d) haXe is a better language than Dart (IMHO, I guess it depends on your
personal tastes).
e) haXe favor syntax conservatism (good for the enterprise) : any
AS3/Java developer can feel comfortable with haXe in a few days.
> 4 ) Its usually the UI which is going to be platform dependent. The logic
> for most of the stuff can easily ported from one Platform to another. Does
> Haxe make you UI agnostic?
The language itself does not help with that.
The API does.
For instance the NME api (from http://haxenme.org) implements all the
Flash Graphics api (beginFill etc.) and bitmaps, events, etc on native
platforms such as iOS/Android/Desktop, and JEASH (http://jeash.org) does
it for JS/HTML5.
haXe enable you to write and improve this kind of libraries.
> I might be wrong but I believe that the Flex community is much larger than
> the community supporting Haxe. So, I personally believe that porting Flex
> onto Haxe should turn out to be a hugely beneficial move in terms of Haxe,
> strategically.
I agree that it would be good for haXe, but I also definitely think it
would be good for Flex as well. That's what you call a win-win
relationship I guess ;)
> Anyways thanks for this mail. Its always great to get inputs
> from people like you when we are talking about open source efforts.
You're welcome,
Best,
Nicolas
Re: Flex adopting haXe ?
Posted by ganaraj p r <ga...@gmail.com>.
Thanks Nicolas,
I was the one who mentioned you in a post and wanted your inputs on "How we
could go about porting Flex to Haxe?".. I assumed that since you built Haxe
( duh! ) and that since Haxe is inspired by AS3, you would be able to
provide some deep insights into the migration of Flex to Haxe.. If we even
go ahead with it. These are a few questions that come to my mind..
1 ) I know Haxe is a budding and growing community. Has anyone attempted to
get Flex onto Haxe? In terms of porting! Have you ever considered doing it
( Since it seems like a logical step to get more traction into the language
itself! ) , starting it ?
2 ) Can you see any pitfalls of porting this huge mammoth (from the top of
your head! )?
3 ) If we are going to go down the cross compilation route we have
primarily 2 choices. Dart or Haxe. Why should we choose Haxe over Dart? Can
you give us any insights and points to choose Haxe over dart? One of them ,
I can already guess is that Haxe is closer to AS3 than Dart is... Any other
advantages?
4 ) Its usually the UI which is going to be platform dependent. The logic
for most of the stuff can easily ported from one Platform to another. Does
Haxe make you UI agnostic? What I mean is if we are going from Flash to Web
then we need to map Sprites to something! So how easy would it be to switch
from one to another.. Does Haxe do what JQuery and other frameworks do to
Browsers and their implementation of javascript ?
I might be wrong but I believe that the Flex community is much larger than
the community supporting Haxe. So, I personally believe that porting Flex
onto Haxe should turn out to be a hugely beneficial move in terms of Haxe,
strategically. Anyways thanks for this mail. Its always great to get inputs
from people like you when we are talking about open source efforts.
On Wed, Feb 22, 2012 at 1:07 PM, Left Right <ol...@gmail.com> wrote:
> I think I could add more info on HaXe vs linking assets.
>
> There used to be a project SamHaXe - no longer developed, sadly. About a
> year or so ago I made this plugin for FD to have some kind of graphical
> interface for embedding different stuff it supported:
> http://www.flasher.ru/forum/blog.php?b=187 (sorry, the text is in Russian,
> but you could understand from the images what does it do, well, I hope so
> :).
> The way it used to work was different, but, in my opinion, better approach
> then [Embed] meta - it used a resource file descriptor, which then would be
> processed by the encoder (which was basically an adapter to other encoders,
> such as Imagemagic for example), then you would "feed" the produced SWF to
> the compiler as a reference.
>
> However, there is yet another project that does it, and it does it
> significantly better: http://code.google.com/p/hxswfml/ this is something
> that allows not only embedding, but also generating SWF graphical content,
> such as shape primitives, text snapshots and so on.
>
> Other bonus points: it wasn't possible with Flex encoders to embed, for
> example FLV video data or PCM sound data - I'm sure that HXSWFMill can do
> the first, and almost sure about the last :) I'm not sure about what font
> formats are supported though.
>
> Something about Flex binding: in a trivial case, it would be really a
> trivial compiler macro, however, with some more complex cases, like,
> binding tag used on class declaration it may not be so trivial (but, why,
> why on Earth would you do that?..) anyways, that would be still doable, but
> would involve more sophisticated macro. There are, however, more complex
> things, which I, to be honest, don't even know how they function - the
> [Inspectable] meta and whatever relates to live preview and stuff like
> that.
>
> Re' ASDoc - sorry, but that wasn't a very good tool :( I mean, OK, it did
> the job, but the HTML output from it is terrific. Try to feed the
> documentation page to HTML validator service - it has hundreds if not
> thousands of errors. But not only that, the generated HTML is not
> optimized, it repeats a lot of things that needs not be repeated (it could
> be actually reduced up to 50% as it is now, but given some thought it could
> be even more).
> On the other hand, HaXe is easily recognizable by tools like NaturalDocs,
> which actually produces better quality HTML output. It requires different
> type of writing the comments (it's not entirely different, but still). So,
> if you think about documenting HaXe source, then it would hardly be an
> issue. NaturalDocs is an established well-known tool used since like
> prehistoric era, but still been actively developed and maintained :)
> http://www.naturaldocs.org/
>
> Re' E4X - many-many years ago I tried to "fix" this for myself :) It might
> be a bit funny code, and it uses old XML API, but the concept should be
> still understandable:
>
> http://code.google.com/p/e4xu/source/browse/trunk/haxe/src/org/wvxvws/xml/W.hx
> So, for example something like:
>
> xml.*.(foo(valueOf()))..*.@bar
>
> would look like:
>
> W.alk(xml).c(foo).d().a("bar")
>
> It's not as fast as the original E4X, but it's not that slow really, and,
> after all, if you wanted speed, you should be using XMLNode anyway.
>
> At the same time I started writing a validating SAX parser for XML, never
> finished it though, but "finishing" it means ensuring things really work as
> advertised. If implemented using fast memory, it could be, possibly, quite
> fast, but even if not, then it would be still faster then a regular
> expression based version.
>
> http://code.google.com/p/e4xu/source/browse/trunk/haxe/src/org/wvxvws/xml/Sax.hx
>
--
Regards,
Ganaraj P R
Re: Flex adopting haXe ?
Posted by Left Right <ol...@gmail.com>.
I think I could add more info on HaXe vs linking assets.
There used to be a project SamHaXe - no longer developed, sadly. About a
year or so ago I made this plugin for FD to have some kind of graphical
interface for embedding different stuff it supported:
http://www.flasher.ru/forum/blog.php?b=187 (sorry, the text is in Russian,
but you could understand from the images what does it do, well, I hope so
:).
The way it used to work was different, but, in my opinion, better approach
then [Embed] meta - it used a resource file descriptor, which then would be
processed by the encoder (which was basically an adapter to other encoders,
such as Imagemagic for example), then you would "feed" the produced SWF to
the compiler as a reference.
However, there is yet another project that does it, and it does it
significantly better: http://code.google.com/p/hxswfml/ this is something
that allows not only embedding, but also generating SWF graphical content,
such as shape primitives, text snapshots and so on.
Other bonus points: it wasn't possible with Flex encoders to embed, for
example FLV video data or PCM sound data - I'm sure that HXSWFMill can do
the first, and almost sure about the last :) I'm not sure about what font
formats are supported though.
Something about Flex binding: in a trivial case, it would be really a
trivial compiler macro, however, with some more complex cases, like,
binding tag used on class declaration it may not be so trivial (but, why,
why on Earth would you do that?..) anyways, that would be still doable, but
would involve more sophisticated macro. There are, however, more complex
things, which I, to be honest, don't even know how they function - the
[Inspectable] meta and whatever relates to live preview and stuff like that.
Re' ASDoc - sorry, but that wasn't a very good tool :( I mean, OK, it did
the job, but the HTML output from it is terrific. Try to feed the
documentation page to HTML validator service - it has hundreds if not
thousands of errors. But not only that, the generated HTML is not
optimized, it repeats a lot of things that needs not be repeated (it could
be actually reduced up to 50% as it is now, but given some thought it could
be even more).
On the other hand, HaXe is easily recognizable by tools like NaturalDocs,
which actually produces better quality HTML output. It requires different
type of writing the comments (it's not entirely different, but still). So,
if you think about documenting HaXe source, then it would hardly be an
issue. NaturalDocs is an established well-known tool used since like
prehistoric era, but still been actively developed and maintained :)
http://www.naturaldocs.org/
Re' E4X - many-many years ago I tried to "fix" this for myself :) It might
be a bit funny code, and it uses old XML API, but the concept should be
still understandable:
http://code.google.com/p/e4xu/source/browse/trunk/haxe/src/org/wvxvws/xml/W.hx
So, for example something like:
xml.*.(foo(valueOf()))..*.@bar
would look like:
W.alk(xml).c(foo).d().a("bar")
It's not as fast as the original E4X, but it's not that slow really, and,
after all, if you wanted speed, you should be using XMLNode anyway.
At the same time I started writing a validating SAX parser for XML, never
finished it though, but "finishing" it means ensuring things really work as
advertised. If implemented using fast memory, it could be, possibly, quite
fast, but even if not, then it would be still faster then a regular
expression based version.
http://code.google.com/p/e4xu/source/browse/trunk/haxe/src/org/wvxvws/xml/Sax.hx
Re: Flex adopting haXe ?
Posted by Nicolas Cannasse <nc...@motion-twin.com>.
Le 22/02/2012 13:09, Carlos Rovira a écrit :
[...]
> Now haXe has evolved great and Apache Flex could go the haXe way to be a
> real open source framework that does not depend only in Adobe's runtime.
>
> The problems behind : This way is hard, but feasible, and take into account
> that principal actors using Flex nowadays are IT departments of huge
> organizations and enterprise customers that need a viable migration path to
> all applications deployed until now.
>
> We must to take into account, that Flex is MXML and AS3 right now. People
> that wants to move from adobe flex sdk latest sdk (4.6) to apache flex,
> need a migration path that could be done with more or less pain. If we
> chage in a radical manner and adobe sdk and apache flex sdks is radicaly
> different, we could loose in the process lots of users.
Hi Carlos, long time no talk ;)
While not being myself a Flex user, I definitely understand your point
here. Things needs to be done carefully, and you need a plan for that.
However it's not like all flex users will have to switch to haXe either.
Rewriting Flex in haXe would allow people to use haXe, and I guess you
would also need it to target JS/HTML5, but you could also give AS3 users
a precompiled SWC that would work exactly the same for them as if if was
written in AS3.
Looks like a migration plan does it ?
Best,
Nicolas
Re: Flex adopting haXe ?
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Nicolas,
I think the proposal to port Apache Flex to haXe sounds very good since
many of us know you, your talent and what you did with MTASC and later with
haXe. Your quality writing compilers and getting the right solution is
superb.
Many of still remember the open source flash era back in 2005 when a
vibrant community was making the osflash movement successful. Then Adobe
comes with brutal changes that broke the community : Flash 9, AS3, Flex 2,
FDS, and so on. You decided to create haXe as well.
Now haXe has evolved great and Apache Flex could go the haXe way to be a
real open source framework that does not depend only in Adobe's runtime.
The problems behind : This way is hard, but feasible, and take into account
that principal actors using Flex nowadays are IT departments of huge
organizations and enterprise customers that need a viable migration path to
all applications deployed until now.
We must to take into account, that Flex is MXML and AS3 right now. People
that wants to move from adobe flex sdk latest sdk (4.6) to apache flex,
need a migration path that could be done with more or less pain. If we
chage in a radical manner and adobe sdk and apache flex sdks is radicaly
different, we could loose in the process lots of users.
I, as many others, would love to see haXe and you (Nicolas) contributing
to the effort, but I think we should have a feasible plan in order to see
this as a viable option.
Is strange, but seems things are turning to the state we left in 2005-6 ;)
Great to see you here Nicolas! :)
Carlos Rovira
2012/2/22 Martin Heidegger <mh...@leichtgewicht.at>
> Hello Nicolas,
>
> Thank you, I can only speak on my behalf but I think its a very nice post.
> I have tried to get into haXe in the beginning and was thrilled but I was
> never able to get the companies I worked in to use haXe. I know that haXe
> has a lot of features that AS3 doesn't have. Particularly "using" is just
> plain awesome. Others are debatable like typedef+interfaces or the notation
> for properties.
>
> However I used ActionScript a lot in the past years and found ways to work
> with it that are unlike the work with haXe because when I recently tried
> out haXe again I was bothered by a few language features that I use heavily
> in ActionScript and have not found a good equivalent in haXe (in other
> words: they are missing in haXe - aren't they?):
>
> *) Standalone variables/constants/function files outside of a class
> context. I found them very liberating and as far as I can tell: haXe only
> allows class/ENum/ alike.
> *) e4x: Its such a pleasure to use in AS3.
> *) Default initialized properties:
> class ABC {
> public var x: int = 1;
> }
> *) Working "this" in function references: Using function references has
> become such a normal thing in AS3 that I wouldn't know how to implement a
> similar design with without them.
> *) Namespaces: While I don't "like" namespaces particularly, porting Flex
> to haXe might be difficult without it.
>
> There are other features in the compiler that are worth talking about that
> I am sure would be reasonable to continue having in Flex.
>
> *) Compiling the "asdoc" to different locales
> *) Documentation on Meta-tags
> *) Binding
> *) Assets (Fonts!) loaded compiled through meta-data
>
> Have there been discussions about this points in the haXe community?
>
> yours
> Martin.
>
>
>
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Flex adopting haXe ?
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
Hello Nicolas,
Thank you, I can only speak on my behalf but I think its a very nice
post. I have tried to get into haXe in the beginning and was thrilled
but I was never able to get the companies I worked in to use haXe. I
know that haXe has a lot of features that AS3 doesn't have. Particularly
"using" is just plain awesome. Others are debatable like
typedef+interfaces or the notation for properties.
However I used ActionScript a lot in the past years and found ways to
work with it that are unlike the work with haXe because when I recently
tried out haXe again I was bothered by a few language features that I
use heavily in ActionScript and have not found a good equivalent in haXe
(in other words: they are missing in haXe - aren't they?):
*) Standalone variables/constants/function files outside of a class
context. I found them very liberating and as far as I can tell: haXe
only allows class/ENum/ alike.
*) e4x: Its such a pleasure to use in AS3.
*) Default initialized properties:
class ABC {
public var x: int = 1;
}
*) Working "this" in function references: Using function references
has become such a normal thing in AS3 that I wouldn't know how to
implement a similar design with without them.
*) Namespaces: While I don't "like" namespaces particularly, porting
Flex to haXe might be difficult without it.
There are other features in the compiler that are worth talking about
that I am sure would be reasonable to continue having in Flex.
*) Compiling the "asdoc" to different locales
*) Documentation on Meta-tags
*) Binding
*) Assets (Fonts!) loaded compiled through meta-data
Have there been discussions about this points in the haXe community?
yours
Martin.