Evolution of a method

My understanding of the difference between getter method and getter property is the latter is the attribute of given type, something that you can just read. The former on the other hand is something you (painfully or not) compute.

It really annoyes me that in C# you have for example the method Count for IEnumerable (granted, as an extension) and you have Count property for such collection as List.

Let’s think in terms of refinement — when you have a method in your base type you can refine it in any derived type, but if at some stage you could guarantee no actual computation takes place you would be sending the wrong signal. Internally you have just a fetch operation, for the outer world you are still struggling with some number crunching. That is why Skila allows to refine a method as a property.

Dead simple:

interface Sequence<out T>
  // here we compute
  base def count() Int •••
end

class !Array<T> extends Sequence<T>
  // here we just read
  extends def count Int •••
end

And to make using properties as pleasant as possible Skila goes the opposite way than Scala — it is possible to call a property like a function but not the other way around:

let seq ~Int = [ 1, 2, 3 ];
_ = seq.count();
// invalid in Skila, valid in Scala
_ = seq.count; 

let coll [Int] = [ 1, 2, 3 ];
// both target the property
_ = coll.count(); // invalid in Scala
_ = coll.count; 

Advertisement

Properties — enough with monkey typing

The more I use properties in C# the more annoyed I am with repetitions. Consider such code:

private SomeType field;
public SomeType Field
{
  get { return this.field; }
  set 
  {
     // some logic with previous value
     this.field = value;
     // some logic with new value
  }
}

Triggering events, logging data in a database, you name it — this pattern occurs over and over again. And the best you can come up is writing Wrapper class and using it like here (still C#):

private Wrapper<SomeType> field = new Wrapper<SomeType>();
public SomeType Field
{
  get { return this.field.value; }
  set { this.field.value = value; }
}

Some advise the solution to this is using snippets which is hilarious idea — it is like saying that you can reduce the amount of code by typing faster. Besides I am not a monkey, so I look for the solution elsewhere.

Somewhere along AOP or Scala-like traits — I am thinking of property specialized overlays:

overlay Wrapper // implicit first generic parameter: T
  def set(value T)
    // some logic with previous value
    inner.set(value);
    // some logic with new value
  end
end

Since overlay will be mixed with property we have to connect it somehow to the already existing setter or getter — all we need is inner reference. And the usage could be reduced to this:

def field SomeType with Wrapper; 

The type of the field would be SomeType, keyword with does not change a type, it just indicates what wiring compiler should do behind the scenes.

It is just a vague idea, but it has to be done, yesterday my inner monkey wrote:

private SomeType field;
public SomeType Field
{
  get { return this.field; }
  set 
  {
     // some logic with new value
     this.field = value;
     // some logic with previous value
  }
}

So it is about time to make properties right.

Mind your own data — take two

Thanks to aliases implementing single field per property was not hard, but there were still limitations:

def first Int
  var _first Int; 
  get: return field; // `field` is a local alias to `_first`
  set: field = value;
end
def second Int
  var _second Int; 
  get: return field;
  set: field = value;
end

Because constructor has to reach each of those internal fields, their names have to be unique within entire class. On the other hand with uniform aliasing inside property only single internal field is supported.

I might not borrow from Ada a lot, but after reading Programming in Ada 2012 by John Barnes one idea made its way to Skila. I cannot write such constructor:

def init()
  first._first = 0;
end

Because Int type does not have _first member. But I could write:

def init()
  first'fields._first = 0;
end

Apostrophe instead of regular dot means I ask for an attribute (or meta information, or compile time information). The terminology currently is not so important, the important fact is this extra syntax allows properties to have truly internal fields, and since I always wanted to name all the fields just field (easier copy&paste) I can finally do it:

def first Int
  var field Int; 
  get: return field; 
  set: field = value;
end
def second Int
  var field Int; // same field name
  get: return field;
  set: field = value;
end
def init()
  first'fields.field = 0;
  second'fields.field = 0;
end

Did I just introduce new syntax to solve a corner case? Yes, I am aware of that — but reflection in other languages shows it should survive.