Finalise Permissions Model

# What features do we need, and how should they work?

Here are some features we've discussed as being potentially useful / necessary, along with a discussion of open questions about how they should be implemented.

## Object-Level Attributes
The two main attributes we've discussed for objects are fertility and readability, equivalent to [LambdaMoo Object's `f` and `r` properties](https://www.hayseed.net/MOO/manuals/ProgrammersManual.html#SEC6).

### Object Fertility
Do we want objects to have a 'fertile' attribute that, if false, prevents them from being made the prototype of another object without sufficient authorisation?

* An important use-case is the `$.user` hierarchy. Are there others?
* I note that [Moo Canada special-cased this in `#101:bf_chparent`](https://neil.fraser.name/scripts/moowebbrowser.py?db=MooCanada.db&obj=101&verbnum=10).
* Should new objects be fertile by default?
* Non-fertile by default probably breaks most libraries.
* Maybe automatic `.prototype` objects should be fertile, but ones created from object literals or by `Object.create()` are not?
* What about RegExps created from literals?
* Fertile by default is going to make hierarchy-based permissions checks (`proto.isPrototypeOf(instance)`) risky: it would be pretty easy to accidentally create a fertile offspring.
* Maybe objects should inherit their fertility from their initial prototype?
* Naming:
* `Object.getFertilityOf` / `Object.setFertilityOf`?
* By analogy with `isExtensible`: `Object.isFertile`?
* By analogy with `preventExtensions`: `Object.preventOffspring`?

### Object Readability
Do we want objects to have a 'readable' attribute that, if false, prevents obtaining or iterating over the list of property names without sufficient authorisation?

* ~~Main use cases at the moment is `$.userDatabase`, which is keyed by login cookie. We could work around this with a closure (at the expense of needing to implement dumping closures in `Dumper`), and making it rather harder to change the database implementation).~~ Do we have other uses, long-term?
* If property readability also hides the name of the property, do we need this?
* Should non-readability also prevent unauthorised users from obtaining [[Prototype]], [[Owner]], or other internal slot info (esp. `Date` value, `RegExp` source)?
* Naming: `Object.isReadable` / `Object.setReadability`?
* Or should readability and fertility both be properties on an object descriptor (by analogy with property descriptors) passed to `Object.setAttributes` and returned by `Object.getAttributes`?

## Property-level attributes
The three main features we've discussed are:

* having some way to hide the value (and possibly the name) of a property,
* having some way of allowing (super)classes to write to properties on instances owned by other users, and
* having some way to prevent certain methods from being overridden—akin to [LambadMOO properties' `r`, `!c` attributes and verb's `!o` attributes, respectively](https://www.hayseed.net/MOO/manuals/ProgrammersManual.html#SEC6).

### Cross-cutting concerns

* One overarching question is: to what extent should these attributes (e.g. property readability) be settable per-object (in a prototype chain) vs. being set once and that setting automatically and unavoidably being inherited by all descendants? LambdaMOO server takes the former approach—so, for example, an child object would own a property that was `+c` when it was created, even if the prototype property was subsequently made `-c`—while [Moo Canada overrode `#101:bf_set_property_info` to try to ensure that child objects' properties would always be consistent with the initial definition](https://neil.fraser.name/scripts/moowebbrowser.py?db=MooCanada.db&obj=101&verbnum=12).
* The former approach is more in line with how the existing attributes (writable/enumerable/configurable) work.
* The latter approach is conceptually less complicated, but creates challenges deciding what should happen prototype chains are mutated.

### Property readability
Do we want properties to have a 'readable' attribute that, if false, prevents obtaining or iterating over the list of property names without sufficient authorisation?

* Should non-readable properties still show up in the output of `Object.getOwnPropertyNames` for unauthorised users? Making non-readable properties *completely* hidden might obviate the need for object-level readability. (DOS hidden files vs. UNIX non-readable directories…)
* Not sure we have any immediate use-case, but if we're going to have any kind of in-DB message storage service we probably want this for privacy reasons.
* If non-readability is not forcibly inherited, do we want the attribute to be inherited per-descendant when overriding?
* When creating a new property by assignment?
* When creating using `Object.defineProperty`, if not specified explicitly?
* Again: closures could be used instead.
* But whether we use non-readable properties or closures, there is a potential problematic Interaction with the ability to obtain a list of all the children (or owned objects, or references to ) of an object.

### Property heritability/reservedness/finality

#### Private fields

Should we just implement [the private class fields proposal](https://github.com/tc39/proposal-class-fields) and be done with it?

* Equivalent to internal slots like [[Prototype]], [[PrimitiveValue]] (Date) or [[Match]] (RegExp).

Pros:

* This is going to be standard JS very soon.
* Already available in V8 / node v12 (not that we would use it when implementing it.)
* No issues with inheriting invalid values, since prototype chain never examined when doing private field lookups.

Cons:

* Requires either class syntax or some equivalent mechanism to specify private fields and control access to them.
* In any case requires a constructor call to create objects with such fields.
* No way to change structure of object after creation.
* No way to change which methods can access after the fact (if using class syntax).
* Can't be made immutable (like the internal slot of a Date object!)
* Not useful as a kind of 'final' attribute for methods.
* Less "dynamic" than properties.
* Doesn't provide anything like `final` method—private fields not accessible outside class, so not useful even as a non-final method!

#### WeakMaps

Alternatively, what if we use WeakMaps, which are equivalent?

* We could have a convention that any WeakMap used to implement what would otherwise be e.g. `.bar` on `$.foo` be accessible as `$.foo.__map_bar`; the object browser could then surface the value returned by `$.foo.__map_bar.get(x)` as if it were `x.bar` when browsing `x`.

Pros:

* No changes to server required.
* Pretty much functionally equivalent to private fields, but
* No need for special syntax to create private fields, and
* No need for special introspection facilities for IDE.
* Changing object 'structure' at after creation is trivial.

Cons:

* As with private fields, setting prototype of an object outside the hierarchy of a prototype that defines a 'private field' doesn't cause associated WeakMap entries to be cleared (so gc does not clean them up).
* Cleanup could be done manually if using an IterableWeakMap—or, for physicals, a regular Map.
* Using WeakMaps cries out for getters and setters to encapsulate map access.
* It's so ugly.

#### Permissive access

What if we allow write (and maybe read-of-non-readable) property access based on the prototype chain?

1. Simple approach: if `u` owns prototype `p` of object `o`, then functions controlled by `u` have full access to `o` as if `u` owned `o`.
2. Fancier: if function `f` is specially tagged as being a method on prototype `p` of object `o`, then `f` has full access to `o` as if `f{owner}` controlled `o`.
* This special tagging would be equivalent to [the [[HomeObject]] slot of ES6 function objects](https://www.ecma-international.org/ecma-262/6.0/index.html#table-27). It would be set automatically for ES6 `class` methods, if we implement them.

Pros:

* No problems defining a clear set of semantics in the face of mutating prototype chains: access would be granted/revoked automatically.
* Minimal changes to implementation of properties in the server.
* The tagging implementation (option 2, above) would also enable us to implement the `super` keyword, letting methods 'pass' without knowing what their superclass is by doing `super.method.apply(this, arguments)` (rather than `$.specificClass.method.apply(this, arguments) as they must at the moment).
* Tagging implementation could also be used as the basis of a semi-automatic `isPrototypeOf` type checking—e.g., if function body begins with `"use autoTypeCheck"`, it would verify that `this` has [[HomeObject]] in its prototype chain.

Cons:

* This gives pretty wide-open opportunities for abuse. A programmer would have full access to every object that inherits from one of their own.
* Provides none of the protection from meddling by subclasses/instances afforded by private fields in JS or `!c` properties in LambadaMoo.
* So offers none of benefits of being able to declare a method `final`, either.
* Tagging implementation is possibly confusing for novices; we'd need to make sure IDE took care of the details fairly reliably.

#### Restrictive access: `reserved`, with full hierarchy survey on-demand

What about implementing something like a `c` bit (call it `reserved` attribute, or maybe `heritable`), following the LambdaMOO implementation as closely as possible?

We'd need to examine all the descendants of an object when using `Object.defineProperty` to create a `reserved` property (or reserve an existing one), or when using `Object.setPrototypeOf` to change its prototype.

Pros:

* Conceptual model is not too complex, and LambdaMOO refugees will already grok it.
* Gives (with `readable` attribute) something as good as private fields, but more dynamic, since it can be added (e.g. to descendants) after object creation.
* Get `final` methods for free.

Cons:

* Will need `IterableWeakSet` of all children of every object (but we were planning to do that anyway).
* Certain operations will become very expensive.
* Certain `defineProperty` or `setPrototypeOf` operations will fail for (to normie JS programmer) very mysterious reasons.
* Remedying such will require a tool equivalent to LambdaCore / mceh-core's `@disinherit`—even absent fertile bit on objects.
* Not completely clear how `reserved` properties will interact with arrays.
* Owner of prototype could (probably) use this to test for existence of hidden properties (properties on non-readable objects) on descendants.
* Could make it harder to do this by auto-disinheriting.
* Could prevent this by making it illegal to reserve properties if object has any descendants.

#### Holy grail: `reserved`, without need for to full hierarchy surveys

Could there be some way to get the semantics of the previous option, without the cost of having certain operations be very slow and/or inconvenient?

* Would reserving a property effectively hide any existing properties of the same name on descendants?
* If so, would there be some way (e.g., via `defineProperty` / `getOwnPropertyDescriptor` to access the hidden values?
* Alternatively, would reserving a property effectively blow away properties of the same name on children—albeit perhaps only detected and implemented when the child property is accessed?
* This could create a weird situation where reserving a property temporarily would result in some descendants having it deleted, but not others which happened not to be accessed…

#### Idea: private fields without special syntax

Here we would implement private fields, except:
* Rather than being created permanently at construction time, they could be added and removed like regular properties.
* They would be accessed, _by methods on the prototype which declares them_, as `.foo` instead of `.#foo`.
* Outside those methods, they could be shadowed by any normal properties of the same name, (or by `reserved` properties of the same name declared on subclasses)—but if no such properties existed, then the `reserved` property would "show through" as if it were a regular property.
* This would mean that a `reserved` property would be approximately like having a #private field plus automatically-created getters and setters with matching names (and suitable security checks)—i.e.,
```JS
Object.defineProperty(C.proto, 'foo', {reserved: true});
```
would be approximately equivalent to
```JS
class C {
#foo;
get foo() {return this.#foo;}
set foo(value) {/* security check */; this.#foo = value;}
}
```
Except that, *in methods tagged as belonging to `C`*, accessing `this.foo` would always _really_ access `this.#foo`, even if `.foo` were overridden on the actual `this` object.

Pros:

* Most of the benefits of private fields, but without the disadvantages of static allocation and special syntax.
* Probably implementable.

Cons:

* Doesn't provide `final` methods.
* Kind of confusing that, if object `o` derives from `p2` which derives from `p1`, and `p1` and `p2` both declare `.foo` reserved, then `o` could _itself_ have three separate values for `.foo` simultaneously.
* Though that's not _much_ worse than in ES6, where `o` could have `P1`'s `#foo`, `P2`'s `#foo`, and a regular `.foo` too)