Teaching the interfaces new tricks

Probably I am the worst person when it comes to shipping the product — once I’ve got a clever idea, I simply cannot wait to implement it. Around 2 weeks ago I found out how object initialization should be done in Skila, and from that moment new ideas couldn’t stop flowing into my mind. Reading books and blogs only worsens the situation.

Skila can already have an internal field for a property:

def myProperty Int
  var field Int; // visible only inside the property
  get return field;
  set field = value;

because the lack of such feature was bugging me for a long time in C#. But why stop here when you can bring even more control — defects allowed by imprecise access modifiers.

You can implement interface methods as in Java 8, but after browsing “The D Programming Language” I found out extreme version of Non-Virtual Interface pattern. Private, overridable, yet not accessible to outer world methods of the interface (example is taken from the book and translated to Skila):

interface Transmogrifier
  private def transmogrify();
  private def untransmogrify();

  final def thereAndBack()

You have to implement the two first methods when deriving this interface, however you even cannot call your own implementation. I hope you feel how it all clicks together — I don’t have the entire picture of the solution yet, but no worries, I am a patient man.

CLR via C#” brought its own ideas — I used mainly suggestions related to inheritance, classes are final in Skila by default, even if you unseal the class, its methods are still final by default. You really have to make some effort and bring a bigger hammer to turn on virtual gear. I even found a good name to denote unsealing a class (around one week of munching on just a single term — I know, I know) — it’s… “base class”! As you can see no keyword was harmed.

All that work was great opportunity to make some polishing on my own — for example instead of forcing constructor to call only some previous one (as in Scala) I detect recursive loops. Another safety belt — either you call the base method or you state breaking the chain of the override calls:

class SomeInheritance : BaseType
  override def breakChains()
    super break;
  override def callBase()

There are more such minor improvements, but those are nothing compared to the object initialization I devised — I will describe it next time, I have to fine tune some details. I will leave you today with nicely refreshing thought from “Framework Design Guidelines” (yes, I am reading non-stop):

I’ve never been a big fan of choosing performance over ease of use (performance gets better over time; ease of use doesn’t).

— Brian Pepin
Tagged , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: