n-able-devel team mailing list archive

["Arlo Belshee" <a+launchpad@xxxxxxxxx>]

I want N-Able to free devs from the tyranny of files. Basically, they should edit in language-relevant structures (functions, classes, and call graphs), not in annoying file things. But, there are several common language facilities that basically transform state for the rest of the file. I’ll have to eliminate all of these in N-Able.

For example, I can’t be using imports (using, require, include, whatever). Those pull stuff into the file’s context. But I don’t want files. I want to pull stuff into the context of a construct. So, I’m thinking to use attributes for usings. This does mean that I’ll probably have to reduce the number of necessary usings, with something like C# namespaces, rather than Python modules and sub-module imports.

So, you’d write code like:

@using(orm.declarative)
storage_model PrimaryDb:
  table Foo:
    FooId int64
    Name nvarchar(128)

  selectable Bar:
    Foo.join(Baz, (foo, baz) => foo.FooId = baz.FooId)
      .Select(t => t.Foo.Name, baz_name=t.Baz.Name, Baz.Field)
  ...

@using(orm.declarative)
mapping ClassFoo to PrimaryDb.Bar:
  ClassFoo.name = Bar.Name
  ClassFoo.baz = Bar.baz_name
  ClassFoo.field = Bar.Field

Of course, both of the decorated constructs use specialized syntax, which is defined within orm.declarative. But they are basic nested scopes, so as long as we delay scope parsing until we’ve handled the attributes, we should be OK.

This does result in more boilerplate (eww). However, it also allows the above declarations to be in arbitrary files. This allows me to keep the physical model for the language encapsulated, as it should be.

I can probably automate the boilerplate a fair bit, then have it not display by default in the code view. I am going to have better-than-R# level tool integration, after all.

Arlo