
Roadmap
Current Status
Fan is currently in development of its initial 1.0 release. The core language and Java runtime are quite stable. The .Net runtime is almost there, but not quite. At this point, we are building out system APIs for concurrency, database access, and web applications.
Stability
The functionality in each build should be stable. We are very committed to fixing bugs and getting existing code solid before moving on to new features. However Fan is still new, and like all software platforms it still needs to be wrung out in lots of different applications.
We can't promise that we won't make breaking language or API changes. We need the freedom to change things as we learn what does and does not work. However in practice, we've made very few breaking changes over the past year. Be aware of APIs which are still evolving such as concurrency, namespaces, and webapp - these are the most likely to change.
New Features
The list of features on our radar for the next year or two (in no particular order):
Namespaces
The namespace APIs are a work in progress. These APIs and the design will evolve as we plug new implementations into this framework such as HTTP-REST and cloud computing.
.NET Runtime
Some of the .NET runtime is incomplete:
- Get sys tests passing 100%
- We need to get the
sql
APIs working on .NET. - Performance needs to be improved
This Types
There are a ton of cases where you want to declare a type in a method signature to be of instance itself. For example to enable method chaining, many methods are specified to return this
. The problem is that when declared they return the declaring type. That doesn't necessarily work so hot when using that method on a subclass. Subclasses can override to be covariant - but that is ugly. We will be adding support for the generic parameter T
to represent the this type. This should provide an elegant solution to this problem.
Threadlocals
As we start to design libraries and applications with Fan, it is clear that we are relying on thread locals to a much greater extent than in our past lives. Today thread locals are stored in a big map which is ok, but we can do better. The plan is to add support for a threadlocal
keyword which will let you declare thread locals much like you would a static field. With that feature, many APIs can be reworked - for example Weblet can declare req/res as thread locals.
Native Java/.NET Integration
Our main focus has been on making Fan APIs portable between both Java and .NET. As a result little effort has been made to easily allow Fan code to call out to native Java or .NET APIs. From a simple perspective it would be nice to access native Objects and work with them dynamically using the ->
operator. Other efforts might include tools to generate Fan stubs for Java or .NET class libraries. But there is definitely a lot we can do to make Fan suitable as an alternative language using the existing Java or .NET class libraries.
XML
We need basic XML parsing/writing APIs which will likely will be based on uxparser. The API will provide both memory-tree and pull-parser support. We'll probably also include some higher level APIs such as XPath support.
JSON
A library to read/write Fan objects to JavaScript object notation would be handy.
Basic support for SMTP, POP3, and probably IMAP is required. This work will include standardized APIs for modeling multi-part email messages. Current plan is to write these protocols cleanly from scratch rather than wrap something like JavaMail.
Sys APIs
Some of the sys
APIs are imcomplete, such as Process
and Regex
.
Web APIs
The web
APIs are incomplete, such as client side HTTP support and HTTPS.
Web App
The web application framework is just an early prototype and will be evolving.
Crypto
We need standardized APIs for cryptographic operations and algorithms. This work will include support for the SSL protocol.
Closure Type Inference
It would be ideal to allow closures passed as arguments to a method to infer their argument types. The biggest issue with this feature is parsing the grammar unambiguously - which we should be able to do with our two-pass parser by looking for the closing "| {".
IDE Support
We aren't IDE users ourselves, so this isn't our highest priority. But we realize it is a requirement for a successful ecosystem, so we'll be keeping our eye on this one.
Switch
Today the Fan switch statement is a not much different than its C and Java ancestors. It seems to make sense to enhance the switch statement to embody more of what functional languages do with pattern matching. We'll need to do some brainstorming on this one.
Web Server Integration
All of our initial work with the web
API has been with our own web server implementation (wisp). Although the plan is to eventually plug the web
API into Java servlet based containers, into IIS, and to have a mod_fan for Apache.