Inheriting methods — almost there

The last two weeks were dominated by upgrading to LALR(k) parser — I did very little from Skila TODO list, but something anyway. I almost finished dealing with methods inheritance – so far Skila supports the same model as in C#. I have one bug to hunt and one optimization to make (skipping creating empty virtual table). I don’t allow multiple class inheritance, however in general I would like to add it but without much expense. So this feature is on hold.

I rewrote generating classes and methods in the backend — now classes are pure structures (fields only) and methods are functions with extra argument this passed. Of course I had to write custom dispatcher for virtual methods — it was easier than I thought, one step less for porting the backend to JS and R.

It was great opportunity to refresh my knowledge about C# — I didn’t know that interface method declaration is implemented as a method with empty body — and while doing so my patience for two C# books I have ran out. Each time I try to get definitive answer all I find is either the story from the same as me author who feels the urge to patronize me, or mumbling over 8 pages about the given concept. Polish editions of C# in Depth by Jon Skeet and Pro C# 2010 and the .NET 4 Platform by Andrew Troelsen are for sale sold.

The incoming features are standalone functions and finding new angle for handling the data — something between C++, C# and Go. I am thinking of automatic de-/referencing the objects (this would mean no overloading based on pointer depth) with struct defaulting to data and class defaulting to non-null pointer to data — each default could be explicitly overridden though. We’ll see…

Advertisement

Heavy lifting with interfaces

Once I touched the interfaces subject it seems the time it was sufficient to change a syntax a bit to make some progress passed away — this weekend I finished overloading, next time I plan to tackle overriding.

I barely had time to make minor adjustments:

• interface name has to start with capital letter “I” (it is a requirement, not a convention),
• the root type in Skila is “IObject”,
• there is multiple type inheritance (one class + multiple interfaces),
• I reversed and shortened Ruby syntax for mutators — “x!ChangeMe()” instead “x.ChangeMe!()”,
• and I made “Void” result type optional when declaring or defining a function — so it is more like Pascal procedure.

Once I deal with interfaces I have to redo almost entire backend — so far I relied on PHP classes but I think this won’t pay off. First of all PHP has only virtual methods, so it is a dead end for me no matter how I look at it. The second reason is JavaScript — its object model is so different, that sooner or later I would have to find common denominator among backend languages to save my time. I think I should be safe with using just structures, standalone functions and custom dispatcher.