Month: February 2010

by

Turtles are Reptiles, right?

While writing an article about co- and contravariance in .NET I stumbled over some funny C# behaviors.

Given a simple domain model of animals (Reptile is base of Snake and Turtle), will this actually work?

And if not, what will happen? Will it even compile?

Reptile[] reptiles = new[]
  {
    new Snake("Leo"), 
    new Snake("Lucy")
  };

reptiles[0] = new Turtle("Platschi");

Quite obvious, still odd. 🙂

GREAT! Thanks for the answers!

I think @thinkbeforecoding had the best answer. Justin Chase, Björn Rochel and Stefan Lieser also got it right.

Here is what happens:

  1. It compiles!
  2. The type inference will infer a Snake[] from new[] because all elements are Snake.
  3. The Snake array will then be implicitly casted to the Reptile array reptiles because C# supports covariance for Array element types.
  4. Line 7 also compiles fine. But the covariance support is unsafe, hence read-only. The Snake-Array behind the scenes can’t handle Turtles.
  5. A ArrayTypeMismatchException is thrown at runtime.

In C# 4.0 there will not be safe variance for Arrays either. There can never be safe co- and contra-variance for read-write-interfaces or types, because you need co-variance for reading (out) and contra-variance for writing (in).

Advertisement
by

What is left of Microsoft “Oslo”? What now with SQL Server Modeling? (Early 2010)

Back in October 2008 Microsoft announced “Oslo” as a new and world-changing modeling platform. While it always consisted of a language, an editor and a repository the community seemed to be mostly interested in the language “M” and it’s grammar features for creating new domain specific languages.

The feedback could be summarized to:

Great! We love model-driven. We love DSLs. But why the heck SQL?

After that they got engaged with that community. Chris hosted the DSL Dev Con. And Doug released “M” under the Open Specification Promise and founded the “M” Specification Community. Mathew Wilson implemented M in JavaScript. Hugo Brunelier elaborated on the possibilities of bridging it with Eclipse Modeling.

Many wrote, spoke and blogged about it. The fellow hope was, that Microsoft could bring model-driven development to a broader audience and by that increase both productivity and quality in software development.

For that community the renaming of “Oslo” to SQL Server Modeling was a slap in the face. Many stated that they were disappointed by Microsoft’s decisions.

Let’s look into the reasoning and the real consequences of that rename.

Even though I think it was a wise decision business-wise both the timing and the messaging was really bad.

The Repository and “Quadrant” were closely tied to SQL right from the beginnings of “Oslo”. The schema, constraints and functions part of “M” had and mostly still has only one implementation: also SQL.

But the languages part of “M” also referenced to as “MGrammar” had nothing to do with SQL at all and it still doesn’t have much to do with it today either.

“M” should have been split out from “Oslo” before the rename and everybody would have been happy.

So where is this going now?

“M” and “Quadrant” today are still code names. The only thing that has a final name is the repository part of “Oslo” which is now named SQL Server Modeling Services. And I think we agree that that is a OK name.

Most probably “M” will not become SQL Server Modeling M and neither will “Quadrant” be named SQL Server Modeling Quadrant.

I think the final “M” will be as much SQL as Entity Framework and OData are SQL today. All those are developed within the same group and I expect it to merge anyway.

“Quadrant” will probably replace the part in SQL Server Management Studio that enables browsing and editing of SQL data – which is horrible today anyway. It also has the potential of replacing Access as a platform for Information Workers.

And maybe some day we’ll see ideas from “Quadrant” in Excel.

Future of DSL Development with Microsoft Tools

Visual: There was a hope, that “Quadrant” could be a better DSL Toolkit. Those teams didn’t talk to each other, but now they do. I think MS gave up on visual DSLs with “Quadrant”. Instead we’ll see the DSL Toolkit getting more attention. In some Demos at PDC we saw diagrams in Visual Studio working together with SQL Server Modeling. That were already DSL Tools operating on “M” models.

Textual: “M” is at maximum a third of the “Oslo” vision. And the languages part again is only a subset of “M”. Maybe that helps seeing the priorities in the big context.

But still the commitment is alive. The November CTP has some great new features. For example more powerful “M” projections for grammar rules or basic debugging support.  Probably some day this will merge with the DSL Tools and we’ll have both graphical and textual DSLs support right within Visual Studio. I think and hope that the connection to SQL will not be very strong in the future.

Model-driven Development

As often when Microsoft starts (mis)using existing terms they or at least many of their employees just don’t get it. At least not in the first place.

An application that uses “M” to define the M in MVC is not automatically model-driven. It’s just a normal application that operates on data as most applications do. If you want to argue like that, then every C# file and all SQL table rows are models.

In my perception model-driven is, when models become part of the implementation. The Workflow Foundation is a good example for what model-driven means. You model something that is the source of truth for your application – instead of C# code.

If tools help building things like the workflow foundation based on either visual or textual DSLs, using interpreters or code generation, then they truly support the vision of model-driven software development.