Channels ▼
RSS

Parallel

Fantom


Nullability

Beyond concurrency, null pointers are another major source of quality issues — which Fantom directly addresses. Fantom's type system has explicit support for "nullability." If a method signature accepts or returns a type that might be null, then it must be declared directly in code. For example:


  Int? read()  // might return null
  Int readU1() // guaranteed by compiler to never return null

Annotating fields and methods with nullability is as easy as sticking a "?" on the end of the type. We've found that the process of forcing developers to think about whether a type can be null has all sorts of implicit advantages for the design and documentation of developer intent. When you combine this with Fantom's compile-time and runtime enforcement of nullability, most null-pointer bugs are caught much sooner in the development lifecycle than they would be in a language like Java.

Modularity and Packaging

Fantom's concurrency and nullability features are just two examples where we've tried to improve the quality of software at the source code level. But what about the macro level? Much of the cost of a large software system comes after the initial code is written during the deployment and maintenance phases. The ability to assemble large systems from modular software components is fundamental to empowering large teams to build and maintain these systems. Modularity is baked directly into Fantom's architecture by packaging all code into modules called "pods." Pods are independently versioned and explicitly declare their dependencies on other pods. Fantom's type system and reflection APIs are all based around pods. The ease with which you can reflect pods, types, and slots is a pivotal feature and really allows for some creative designs. For example:


// iterate all the installed pods
Pod.list.each |pod| 
{
  // iterate all the types packaged by each pod
  pod.types.each |type|
  {
    // if the type is a concrete subclass of AutoStartService
    // then create an instance and start it up
    if (type.fits(AutoStartService#) && !type.isAbstract)
      type.make->start
  }
}

Other Goodies

We've covered some of the key features of Fantom, but there are lots of other design decisions and conveniences designed to make programming more fun:

  • Easy integration with existing Java or JavaScript code
  • Standardized build script and unit testing frameworks
  • Support for mixins which are like Java/C# interfaces, but methods can have implementations
  • Built-in human readable serialization syntax which can be used directly in Fantom source code
  • All non-const fields automatically have a getter/setter accessor method
  • Multi-line strings and string interpolation
  • Support for List, Map, Type, Slot, Uri, and Duration literals
  • Type inference for local variables
  • Method parameters can declare default values
  • We've eliminated the need to think about 32-bit versus 64-bit numbers and associated overflow problems — in Fantom all numbers are just 64-bit.

Tooling, Community, etc.

To learn more about Fantom, the first thing to do is head over to http://fantom.org/. This site is home base for the Fantom community where you can find: online documentation, examples, a forum, links to source and other downloads, plus an IRC channel.

You will find the Fantom community active and helpful. Fantom has two active projects for tooling: Xored, a company based out of Russia, has developed F4, which is an Eclipse IDE for Fantom. And Thibaut Colar is actively developing FantomIDE, a NetBeans-based IDE.

Fantom is a language developed for software engineers by software engineers. We didn't create Fantom as an academic experiment to publish research papers. We take pride in the fact that Fantom is a "boring language" — a workhorse, everyday language to build large software systems. Fantom is easy to learn and bundled with all the tools a typical project needs: module system, build system, testing framework, web server, desktop UI framework, and web UI framework all packaged up into simple, easy to use APIs. Enjoy!


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video