Sapphire is the name of a new programming language. It has a Ruby-like syntax - but much simplified. The overriding design principle of Sapphire is that the language should be consistent, unambiguous and deeply object oriented. In order to achieve this we have removed many constructs from Ruby: whereas Ruby often has many alternative ways of accomplishing the same effect, Sapphire aims to have one way of doing one thing.

See also: Ruby, Sapphire and Amethyst (27th July, 2007)

The syntax of Sapphire is much stricter than that of Ruby. For example, commands (method calls without parenthesis) are not available. A method name without parentheses is not a method-call but a method-reference. Methods can be assigned to variables and passed as arguments. Lambda methods (nameless methods implemented as blocks) are assigned in a similar manner and these are first class objects. A lambda method is always an instance of the Block class and it has the same independent existence as any other type of object.

Our implementation of object orientation is more rigorous than that of Ruby. We have gone back to the fundamental principles of object orientation epitomised by Smalltalk. This means, for example, that encapsulation and data-hiding is enforced. There are a number of ways of breaking encapsulation as a ’side effect’ in Ruby; this is not allowed in Sapphire.

Another important feature is the ability to assert expected types and ranges. If a method can only operate successfully on string arguments, say, and should always return an array, you may specifically assert that the ingoing arguments are strings and the returned value is an array. You may also assert that values fall within specific ranges (for example that an integer must be between 1 and 100). These assertions are not required and type violations may be optionally treated as errors, warnings or may be ignored. So Sapphire does not ‘remove’ duck-typing and it does not demand type declarations. Its type assertions are there as development and debugging tools - aimed at finding and trapping potential bugs as an integral part of program development rather than having to rely solely on testing.

So, in brief, these are the design principles of Sapphire:

 A simple, consistent, unambiguous syntax
 Rigorous object orientation
 Everything (even blocks and methods) are objects
 A high degree of modularity/encapsulation
 Optional object type checking via assertions

We plan to define a clear specification of the Sapphire language and to make this publically available at an early stage. This will begin when we release the ANTLR grammar of the first draft of the Sapphire syntax later this month. Our own implementation of Sapphire will be developed for .NET (running on the Dynamic Language Runtime) and will be supported by a programming environment code-named Amethyst. If other developers are interested in implementing Sapphire for other platforms, we would be very pleased to work with you, so please get in touch!

For a background to the Smalltalk version of Object Orientation, see: Ruby The Smalltalk Way

Note: Sapphire is not intended to complete with Ruby but to complement it. SapphireSteel Software remains completely committed to supporting Ruby and Microsoft’s IronRuby as a primary goal. Moreover, it is our aim to ensure that our implementation of Sapphire is able to cooperate closely with other .NET languages including IronRuby.