ECON - eC Object Notation (A JSON Superset)
Fork me on GitHub

ECON

The eC Object Notation is a JSON superset with extra features.

ECON: eC Object Notation


ECON is a data interchange format defined as a superset of JSON, with extra features allowing it to map directly to the eC object instantiation syntax.

JSON is valid ECON, but in order to output the data in the distinctive ECON syntax some restrictions apply (e.g. identifier names should not contain spaces).

ECON support is available as part of the Ecere SDK since version 0.44.15 (through the ECONParser class and WriteECONObject() function).

Example showcasing ECON specific features:

/*
   This is sample eC Object Notation (ECON).
   It describes a number of graphical elements, of classes derived from 
   a base Shape class which will get loaded together in one array.
   It would also be valid eC syntax for instantiating an Array<Shape> object.
*/

Array<Shape>
{ [
   Circle
   {
      lineColor = red,
      fillColor = 0x008000;
      center = { 100, 120 } // equivalent to: center = { x = 100, y = 120 }
   },
   Text
   {
      position = Point { 200, 200 };
      string = "The quick brown fox\n"
               "jumps over the lazy dog.";
   }
] }

The distinctive ECON features are:

  • The "name" before the ':' of objects' name/value pairs can drop quotes, as long as the identifiers names are restricted to valid C/eC identifiers (e.g. no spaces).
  • The colon (':') can be replaced by an equal sign ('=').
  • Member names can be implied (e.g. position = { 10, 20 }) and omitted based on the schema (e.g the struct being serialized to ECON).
  • Both single-line comments (//) and multi-line comments (/* */) are supported (C/C++/eC style).
  • C-Style hexadecimal numbers are allowed as values.
  • Enumeration values can be unquoted.
  • Multi-line strings are supported by closing the double-quotes and reopening them on the next line.
  • As part of an object construct, an optional class name is allowed to precede the opening curly bracket, so as to allow subclasses. These could replace a 'type' member required in JSON and dictate different sets of valid name/value pairs for the object. If no class name is specified, the base class is expected.
  • Semicolons (;) are allowed as separators in addition to commas, including extra unneeded semicolons.

ECON convention follows the eC convention of identifiers beginning with a lower case and following 'camelCase', whereas classes should begin with an upper case.

At this point, name/value pairs are only being used for data members and properties.
Future versions may allow specifying methods, to allow some form of scripting to describe object behaviors.