Property tweaks

[jackfirth]

In working on collections, there are two more things with properties that I've run into: read-only properties and implementing properties directly with fields.

Say I've got this code:

interface Collection:
  property size

fun mess_with_size(collection :: Collection):
  collection.size := 42

The size property is supposed to be read-only. Collections might have a mutable size field they keep track of internally, but clients aren't supposed to be able to mutate the property directly. How would I specify this in the Collection interface? Perhaps by writing readonly property size instead of just property size? Ideally, that would turn attempts to mutate the property into an error.

The other thing I ran into is that the size property is backed by a field for many collections. That requires doing this:

class SomeCollection():
  implements Collection
  private field currentSize = 0
  override property size: currentSize

It's weird to have two separate names - and thus, two separate APIs - for accessing the size field. The collection can read or write either currentSize or size; it doesn't matter. Could we have a shorthand so that the property name is the only name involved? Something like this:

class SomeCollection():
  implements Collection
  // the "as field" bit means that `size` will automatically be backed by a private mutable field
  override property size as field

[mflatt]

but clients aren't supposed to be able to mutate the property directly. How would I specify this in the Collection interface?

I can see adding a way to constrain static resolution of property uses. An analogous and similarly useful capability would be to constrain statically resolved method calls to have the right number of arguments. To be consistent with allowing covariant extension of methods in overriding, though, and with the flexibility that goes with that for dynamic method calls, I imagine the constraint would be restricted to property uses in static mode. That is, it would be a mechanism to help programmers know when they've written an assignment that they shouldn't, but it wouldn't be an enforcement mechanism. I'm not sure whether that's what you had in mind.

If static checking is what you had in mind, there's a general issue in where to draw the line on static checking. Currently, there are not even checks on function calls when arity (in)consistency with the function definition could be statically apparent, although that seems like it could be a good idea. Going even further, there's the possibility to trying to do something statically with annotations on arguments. Unless the language is really statically typed, though, there's going to be a line somewhere. I think we'd want to consider that more generally before dong something specific for properties.

The other thing I ran into is that the size property is backed by a field for many collections.

Having a form that declares both a property and a backing field seems like a good candidate for a macro.

[benknoble]

Not having totally followed the classes discussion, properties with shorthands for creating accessors and mutators backed by fields (possibly with custom logic) remind me of C#'s properties. This page contains a good overview.

[mflatt]

I can see adding a way to constrain static resolution of property uses. An analogous and similarly useful capability would be to constrain statically resolved method calls to have the right number of arguments.

Rhombus now tracks function, method, and property arities through static information. So, in static mode (more precisely, when #%call is bound to the static variant of the function-call form), a function call with the wrong number of arguments or with missing/extra keywords is flagged as a syntax error.

When a function call is flagged, then it would certainly be an error at run time. When a method call or property assignment is flagged, it might succeed at run time if the target is an instance of a subclass that overrides the method or property. A case could be made for always flagging function-arity errors, but that's currently constrained to static mode so that a programmer opts into understand the static-information system.

To declare a property as read-only, instead of adding a new keyword like readonly or repurposing mutable, the current syntax is to use a single-arm |, analogous to a property implementation without a := case:

interface Collection:
  property | size -: NonnegativeInteger

With that declaration,

> use_static
> fun (c -: Collection): c.size := 0                         
size: property does not support assignment (based on static information)

[jackfirth]

How would that look for classes with properties where the getter is public but the setter is supposed to be private?

[mflatt]

So far, you'd use a public accessor-only property plus a separate private method or property.