Latest and greatest build is posted and online docs are updated.
Breaking Changes
Summary of breaking changes:
Move Halign, Valign, Orientation from fwt to gfx
Color.alpha => a (to match new h, s, v methods)
DateTime.timeZone => tz
Func.curry => bind
BorderPane now based on new gfx::Border API
Documentation Changes
The docCookbook manual has been removed, in favor of using example scripts for all sample code. This has some nice advantages:
unifies sample code in one place
each example is a stand alone program ready to experiment with
lets me run compiler on each example during build process
As part of this change, all the old docCookbook chapters are now example scripts. And most importantly you can browse the examples in HTML.
Obj.toImmutable
The old List.toImmutable and Map.toImmutable have been moved up to a common sys::Obj.toImmutable method. This change is part of the closures rework to support enhancements to Func immutability.
This enhancement is also used to plug a hole in the const type system. Const fields which are Obj, List, Map, or Func will implicitly have toImmutable called at construction time. Previously these checks were not applied to Obj const fields.
Closure Variables
I posted a separate blog topic about how the compiler now generates closure variables.
Curry Operator
This is the last build which will support the & operator. The compiler will now print warnings any place it is used.
The closure enhancements will now allow you to replace all occurances of the & operator with a standard closure. If you happend to be binding static methods, you can also use this trick:
&someMethod // old way
#someMethod.func // new way
Also as part of this upcoming change, I renamed Func.curry to bind since technically curry isn't the right term.
UI Enhancements
Lots of new work has gone into the gfx and fwt APIs.
The new gfx::Border class is used to declaratively model CSS-like borders. The fwt::BorderPane has been modified to use this new class. Best way to play around with this new feature is the "examples/fwt/demo".
The gfx::Color class supports new APIs for the HSV model.
The gfx::Pattern class adds support for image based brushes.
Andy has been made tons of progress on the Fan-to-JavaScript compiler:
Fields: Changed how fields get emitted in order to support overriding a method with a const field.
// Old model
foo.x$get() // getter
foo.x$set() // setter
foo.x // storage
// New model
foo.x() // getter
foo.x$() // setter
foo.m_x // storage
Trap: Changed trap to function the same was as Java/C# work. Previously used the normal JavaScript call operator. But this doesn't work correctly for using the dynamic invoke operator in Fan with fields.
FWT:
Better support for relayout after lazy loading images
Combo.selectedIndex
BorderPane (incomplete)
Button: toggle and check button modes; animate button press
Polish Dialog L&F
Sys:
Better method relfection
More List methods
Uri implemented
Change Log
Build 1.0.46 (8 Sep 09)
Closure variable redesign
Change JavaScript field naming model
gfx::Border
gfx::Pattern
Move Halign, Valign, Orientation from fwt to gfx
Color: alpha => a, makeHsv, h, s, v, lighter, darker
Obj.toImmutable
Err.trace now takes options
Fix chunked transfer encoding bug in wisp
DateTime.timeZone => tz
Func.curry => bind
WebClient.postStr
Fix fwt::ScrollPane to actually work
Compiler warning for curry & operator
#676: Compiler bug? walkback in closure type inference
Ooh, lots of new goodies to play with. Looks really good!
Fields: Changed how fields get emitted in order to support overriding a method with a const field.
A pretty standard JS convention is to have x() be the getter, and x(v) be the setter, which is implemented in pretty straightforward fashion:
function x(v) {
if (v === undefined) return m_x;
m_x = v;
}
This might make the generated JS code more friendly for use by JavaScript programmers.
andyWed 9 Sep 2009
I considered that approach (this is what I do for default arguments), though what I have was a bit simpler to implement with respect to custom accessors. We can pretty easily move to this pattern (but very painful to move back...). I don't have a strong preference either way.
brianWed 9 Sep 2009
I like the pattern JohnDB suggested, since calling foo$ to set a field is kind of obtuse.
andyFri 11 Sep 2009
FYI - the closure redesign #736 broke the JavaScript compiler. For JavaScript we "inline" closures since they are natively supported, and the compiler just needs to be reworked to support the new design. Working on that now.
andreyMon 14 Sep 2009
Looks to be a reason why graphics.fwt example do not works. hello.fwt works just fine. Is there a plan to provide 1.0.46 update addressing this issue?
brianMon 14 Sep 2009
I think Andy pushed the fix to hg (which requires a compilerJs recompile).
Although if anyone wishes the fix in a new full build, just let me know and I will be happy to do another build this week.
andreyMon 14 Sep 2009
Actually I'm fine either with hg fix or stepping back to 1.0.45 to play JS stuff... Please think about newcomers, who try JS example for first time with 1.0.46, do not see expected results and probably never get back to Fan again in near future.
andyMon 14 Sep 2009
FYI - the closure redesign #736 broke the JavaScript compiler
Everything should now be working in hg tip. While I was in there, I added proper support for multiple catch blocks and the catch all block. There are a few issues with the JavaScript Graphics impl - but that seems to be related to another change made. Will look at that before we roll another build.
brian Tue 8 Sep 2009
Latest and greatest build is posted and online docs are updated.
Breaking Changes
Summary of breaking changes:
Documentation Changes
The docCookbook manual has been removed, in favor of using example scripts for all sample code. This has some nice advantages:
As part of this change, all the old docCookbook chapters are now example scripts. And most importantly you can browse the examples in HTML.
Obj.toImmutable
The old
List.toImmutable
andMap.toImmutable
have been moved up to a commonsys::Obj.toImmutable
method. This change is part of the closures rework to support enhancements to Func immutability.This enhancement is also used to plug a hole in the const type system. Const fields which are Obj, List, Map, or Func will implicitly have
toImmutable
called at construction time. Previously these checks were not applied to Obj const fields.Closure Variables
I posted a separate blog topic about how the compiler now generates closure variables.
Curry Operator
This is the last build which will support the
&
operator. The compiler will now print warnings any place it is used.The closure enhancements will now allow you to replace all occurances of the
&
operator with a standard closure. If you happend to be binding static methods, you can also use this trick:Also as part of this upcoming change, I renamed
Func.curry
tobind
since technically curry isn't the right term.UI Enhancements
Lots of new work has gone into the gfx and fwt APIs.
The new gfx::Border class is used to declaratively model CSS-like borders. The fwt::BorderPane has been modified to use this new class. Best way to play around with this new feature is the "examples/fwt/demo".
The gfx::Color class supports new APIs for the HSV model.
The gfx::Pattern class adds support for image based brushes.
These changes are summarized in #712.
JavaScript Compiler
Andy has been made tons of progress on the Fan-to-JavaScript compiler:
Fields: Changed how fields get emitted in order to support overriding a method with a const field.
Trap: Changed trap to function the same was as Java/C# work. Previously used the normal JavaScript call operator. But this doesn't work correctly for using the dynamic invoke operator in Fan with fields.
FWT:
Sys:
Change Log
Build 1.0.46 (8 Sep 09)
&
operatorJohnDG Wed 9 Sep 2009
Ooh, lots of new goodies to play with. Looks really good!
A pretty standard JS convention is to have
x()
be the getter, andx(v)
be the setter, which is implemented in pretty straightforward fashion:This might make the generated JS code more friendly for use by JavaScript programmers.
andy Wed 9 Sep 2009
I considered that approach (this is what I do for default arguments), though what I have was a bit simpler to implement with respect to custom accessors. We can pretty easily move to this pattern (but very painful to move back...). I don't have a strong preference either way.
brian Wed 9 Sep 2009
I like the pattern JohnDB suggested, since calling foo$ to set a field is kind of obtuse.
andy Fri 11 Sep 2009
FYI - the closure redesign #736 broke the JavaScript compiler. For JavaScript we "inline" closures since they are natively supported, and the compiler just needs to be reworked to support the new design. Working on that now.
andrey Mon 14 Sep 2009
Looks to be a reason why graphics.fwt example do not works. hello.fwt works just fine. Is there a plan to provide 1.0.46 update addressing this issue?
brian Mon 14 Sep 2009
I think Andy pushed the fix to hg (which requires a compilerJs recompile).
Although if anyone wishes the fix in a new full build, just let me know and I will be happy to do another build this week.
andrey Mon 14 Sep 2009
Actually I'm fine either with hg fix or stepping back to 1.0.45 to play JS stuff... Please think about newcomers, who try JS example for first time with 1.0.46, do not see expected results and probably never get back to Fan again in near future.
andy Mon 14 Sep 2009
Everything should now be working in hg tip. While I was in there, I added proper support for multiple catch blocks and the catch all block. There are a few issues with the JavaScript Graphics impl - but that seems to be related to another change made. Will look at that before we roll another build.