Yaml like object writer for rubyx objects
Go to file
Torsten Ruger f2aad98ff9 upped version in step 2015-10-07 15:08:16 +03:00
lib same fix again 2015-06-19 20:16:40 +03:00
test bundler is back, instructions must ahve been for rspec 2015-07-18 12:59:32 +03:00
.gitignore Initial commit 2015-05-03 20:12:49 +03:00
.travis.yml another config test. tests all green at home 2015-07-18 12:46:56 +03:00
Gemfile remove climate id, stored in travis 2015-07-18 12:44:02 +03:00
Gemfile.lock upped version in step 2015-10-07 15:08:16 +03:00
LICENSE Initial commit 2015-05-03 20:12:49 +03:00
README.md code climate and badges 2015-07-18 12:33:00 +03:00
Rakefile add raketasks and release 2015-05-03 22:50:06 +03:00
salama-object-file.gemspec upped version in step 2015-10-07 15:08:16 +03:00

README.md

Build Status Gem Version Code Climate Test Coverage

Reading the code

Knowing what's going on while coding salama is not so easy: Hence the need to look at code dumps

Hence the need for a code/object file format (remember an oo program is just objects, some data, some code, all objects)

I started with yaml, which is nice in that it has a solid implementation, reads and writes, handles arbitrary objects, handles graphs and is a sort of readable text format.

But the "sort of" started to get to me, because

    1. it's way to verbose (long files, object groups over many pages) and
    1. does not allow for (easy) ordering.
    1. has no concept of dumping only parts of an object

To fix this i started on Sof, with an eye to expand it.

The main starting goal was quite like yaml, but with

  • more text per line, specifically objects with simple attributes to have a constructor like syntax
  • also short versions of arrays and hashes
  • Shorter class names (no ruby/object or even ruby/struct stuff)
  • references at the most shallow level
  • a way specify attributes that should not be serialized

Usage

The module's main useful api is

Sof::Writer.write(object_to_derialize)

Salama Object File

Ok, so we all heard about object files, it's the things compilers create so we don't have to have huge compiles and can link them later.

Much fewer know what they include, and that is not because they are not very useful, but rather very complicated.

An object machine must off course have it's own object files, because:

  • otherwise we'd have to express the object machine in c formats (nischt gut)
  • we would be forced to read the source every time (slow)
  • we would have no language independent format

And i was going to get there, just not now. I mean i think it's a great idea to have many languages compile and run on the same object machine. Not necessarily my idea, but i haven't seen it pulled off. Not that i will.

I just want to be able to read my compiled code!!

And so this is a little start, just some outputter.

Direction

The way this is meant to go (planned for 2020+) was a salama core with only a sof parser (as that is soo much simpler).

Then to_ruby for all the ast classes to be able to roundtrip ruby code.

Then go to storing sof in git, rather than ruby.

Then write a python/java parser and respective runtime conversion. Extracting common features. With the respective to_python on the ast's to roundtrip that too. Have to since by now we work on sof's. Etc . ..