logo

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.

Email

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.