Oren Eini

CEO of RavenDB

a NoSQL Open Source Document Database

Get in touch with me:

oren@ravendb.net +972 52-548-6969

Posts: 7,500
Comments: 51,069
Privacy Policy · Terms
filter by tags archive
time to read 1 min | 200 words

Here is a small, but interesting tidbit. Yesterday I have finally sat down and documented a lot of the changes that I made in Brail recently, I was surprised to see how much I had to document:

  • Auto Imports
  • Strongly typed variables
  • Sections
  • The "?variableName" syntax
  • Symbols
  • Null Propagation

The last part is what I want talk about now. Brail is a .Net language, which means that something like this:

output user.Parent.Name

will raise NullReferenceException if the user's parent is null. That can be somewhat of a pain in many scenarios. Brail now has a better syntax for this:

output ?user.Parent.Name

 will ignore any null values that it encounter in the way. It is will either output the parent's name or nothing at all.

The small print:

This will work only for variables that you get from the controller via the PropertyBag or Flash. You can't use it on variables that you define in the view. However, that is rare enough that I don't think that it is going to be a problem.

Note that I didn't document the DSL support in Brail yet, that is going to wait until it is stabilized a bit.

time to read 1 min | 114 words

Harris has more details about the internal implementation of Brail's DSL Support

Following the same line of thoughts, Alex has a similar implementation using C# 3.0. Personally, I think that Alex's implementation is cool, but it looks really similar to LISP, and that sort of scares me. I am currently reading about ANTLR, so it actually makes sense, in a weird way, except that I keep looking for the lower level implementation.

And as long as I am busy in link aggregation, Tom Opgenorth has posted a guide to Binsor, including a Getting Started example!

time to read 3 min | 438 words

The technical details are going to be of interest to a limited number of people, but it comes down to a design choice that I made when I first wrote Brail. It has to do with how the text is outputted into the compiler, and some tricky bits that can happen there because Boo's compiler understand that "this is ${code}" and can turn it into the correct string, based on the value of the variable "code".

That was fine until I realized that I can do more than a simple variable substitution in there. You can call anything that returns a value, which is very valuable for code such as:


The problem started when the code inside the expression got even more complicated. No longer a single method call, but method calls that wanted to pass string parameters (with " in the middle), or maybe they wanted to use inline expressions as well. I always work-around those issues, but today I got a piece of code that was too pretty to give up on, so I fixed the Brail pre-parser (thrice, until I got it right) so it would output the correct code to the compiler.

What this basically boils down to is that this is now valid code:

${Html.LinkToAttributed( title ,@customers, @list, {
      @onclick: "paginate(${pageIndex});" 

If you are interested, the output of this is:


a href="/customers/list.rails" onclick="paginate(5);">first </a>

I like it.


  1. re: Secure Drop protocol - about one day from now

There are posts all the way to May 29, 2024


  1. re (33):
    16 Aug 2022 - How Discord supercharges network disks for extreme low latency
  2. Recording (13):
    05 Mar 2024 - Technology & Friends - Oren Eini on the Corax Search Engine
  3. Meta Blog (2):
    23 Jan 2024 - I'm a JS Developer now
  4. Production postmortem (51):
    12 Dec 2023 - The Spawn of Denial of Service
  5. Challenge (74):
    13 Oct 2023 - Fastest node selection metastable error state–answer
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats