

Note: A New, Simple Encoding for Objects - breck
https://github.com/breck7/note

======
jscheel
Hmm, it looks like a lot of work has been put into simplifying object notation
down to it's bare minimum, but the trailing whitespace and array
representation both concern me. Significant trailing whitespace, as @cynwoody
said, is a really bad approach to the multiline solution. Also, having to
number arrays means ordering is a nightmare. Overall, it's a cool approach
that needs some work, and could probably benefit from looking at YAML, instead
of HAML, for inspiration.

~~~
breck
Very good observations. Thanks for taking a careful look.

We've run into both points in practice over the past year.

See my comments to @cynwoody regarding the whitespace.

For an array, while Note doesn't support an array type, you can extend Note
with a higher level language that does.

For example, I could create a higher level language on top of Note that
supports types:

    
    
      favorite_colors ['blue', 'green', 'red']
    

Your language could interpret the value of favorite_colors as an array, and so
you could access favorite_colors[0], favorite_colors.length, and so forth.

~~~
jscheel
No problem. I think the suggestion below, about using empty lines, might be a
good approach to pursue. One additional thing to consider about the trailing-
whitespace, a lot of (sometimes anal) developers have set up hooks to
automatically strip whitespace at the end of a file every time they hit save.
To clarify the array, in your suggestion, the favorite_colors would come out
as a string, that I would then eval or parse, correct?

~~~
breck
> One additional thing to consider about the trailing-whitespace, a lot of
> (sometimes anal) developers have set up hooks to automatically strip
> whitespace at the end of a file every time they hit save.

Strip whitespace at the end of all lines, or at the end of a file? Wouldn't be
a problem at the end of files, but at the end of lines might be an issue.

> To clarify the array, in your suggestion, the favorite_colors would come out
> as a string, that I would then eval or parse, correct?

Correct. A leaf/value can use any encoding. So you could have something like
this:

    
    
      function Person (note) {
        this.patch(note)
        if (this.favorite_colors)
         this.favorite_colors = JSON.parse(this.favorite_colors)
      }
      Person.prototype = new Note()
      
      var joe = new Person('favorite_colors ["blue", "red", "green"]')
      console.log(joe.favorite_colors[0])
      // prints "blue"
      console.log(joe.favorite_colors[2])
      // prints "green"

------
cynwoody
Having indentation inform syntax is a good thing, as demonstrated by the likes
of Python and YAML.

But meaningful trailing white space (see the multiline string example)? I
don't think so ...

~~~
breck
That method is optional.

You can also do:

    
    
      message This is a
       multiline string. It can
       keep going and going.
    

I just thought this looked somewhat nicer:

    
    
      message 
       This is a multiline string.
       It can keep going and going.
    

However, unless syntax highlighting is present, it can definitely be a source
of bugs.

But I understand your concern. It is one of my few nitpicks as well. However,
the slight problem almost disappears with editors that support Note.

Thanks for taking a careful look at Note!

~~~
fruchtose
Have you considered separating multiline strings with a newline above and
blow, with multiline strings indented, like so?

    
    
      from Alice
      to Bob
      subject Note formatting
      body
    
       Note is awesome! I like to use it everywhere.
       XML better watch out.
       Whitespace is great.
    
      return-path bounce@email.com
    

Or, in the case where there is no text below, a newline would have the same
visual clarity.

    
    
      from Alice
      to Bob
      subject Note formatting
      body
    
       Note is awesome! I like to use it everywhere.
       XML better watch out.
       Whitespace is great.
       Let's get rid of return paths.

~~~
breck
No, I had not. That looks pretty good, and seems like it could work...

