Five things about me

I’ve been tagged by Peter Morris and Jesper, simultaneously. Thus, without further ado, here are five things about me you may not know.

1. I have studied art at university for two semesters. That is, looking at paintings, not painting them. I wanted to do something different after I had finished my computer science studies.

2. I have practiced Jiu-Jitsu for the past two and a half years. I am 3rd kyu (green belt).

3. According to Google, my main achievement is still - more than a decade later - that I played a game called CoreWars, in which short assembly-like programs battled in a virtual computer.

4. Around 1989-1991, I used to write so-called "demos" for the Amiga. Any traces of my activities in "the scene" have been lost to time on a rotting pile of 3′5 discs.

5. I am childishly fond of american style pancakes with maple syrup.

I tag Jens and, um, well, if I can think of anyone else that haven’t already been tagged, I’ll add it later. Otherwise, I declare this game officially over. Thank you for reading

 

Share This | Email this page to a friend

Posted by Anders Ivner archive on January 17th, 2007 under Uncategorized | Comment now »

Generic API ideas

We’ve been talking about some new ways to improve the ECO API using generics:

T IEcoServiceProvider.GetEcoService<T>()

This would allow you to retrieve e.g. the IOclService using serviceProvider.GetEcoService<IOclService>() rather than the more awkward (IOclService)serviceProvider.GetEcoService(typeof(IOclService)).

Similarly,

IList<T> IExtentService.AllInstances<T>()

allows for code like foreach (Person p in extentService.AllInstances<Person>()).

I like it. It leads to code that is easier to read and more type safe.

What do you think? Are there other uses you can think of?

Share This | Email this page to a friend

Posted by Anders Ivner archive on December 13th, 2006 under Uncategorized | 5 Comments »

Article about ECO packages

While doing a bit of summer cleaning in preparation of my vacation next week, I found an unfinished article about developing ECO applications with multiple packages. I decided to patch it up and post it here.

Share This | Email this page to a friend

Posted by Anders Ivner archive on June 27th, 2006 under Uncategorized | Comment now »

Developing ECO applications with multiple packages

This article will describe how to partition an ECO application into multiple packages in ECO 3.

 

A model may be divided into packages, still within one project. This is primarily good for your own sanity, as it can make the model easier to survey and manage. Reuse of the more generic packages can be obtained if dependencies between packages are managed carefully.

 

An application may have its model in a separate assembly, which may in turn contain multiple packages. This is considered good practice and is, in fact, if not strictly needed then at least strongly recommended to make use of ECO’s remote persistence and synchronization features.

 

Finally, the model may itself be partitioned into several assemblies, each containing one or more packages. This requires some maneuvers, which will be explained in this article. The resulting assemblies can be reused as generic model parts in several projects.

 

If your project has more than one package, you may notice that the project manager contains one “.ecopkg” file per package in your model. These files are where model information is stored in design time.

 

There is a limitation in the ECO runtime: Classes must have unique names, even if they are in different packages.

How to have multiple assemblies

Let me start by making a controversial suggestion. Do not use a project group. ECO treats the projects separately, and not having them open at the same time will help avoid some potential problems, as we shall see later.

 

First, we will create the assembly containing the base package. There are file gallery items to facilitate this. Select either File | New | Other… | C# Projects | ECO Package in DLL or File | New | Other… | Delphi for .Net Projects | ECO Package in Package. Let’s name the package RealEstate and let’s add two classes, Person and Building. We make sure that code is generated and compile the assembly. The project is then closed.

 

Next, we create another package assembly, Habitation.dll, in the same way. This package will use the classes defined previously, so we must let the new project know of RealEstate. The RealEstate.ecopkg file containing the model information for the RealEstate package should be added to ‘Referred ECO Packages’, The referred ECO Packages dialog can be found in the Project Manager’s context menu. The RealEstate.dll assembly should also be added to the project’s references. While this is not necessary for the modeling itself, the ECO code generator needs to extract namespace information from the ECO classes in the assembly. The assembly is of course also needed for subsequently compiling the project.

 

The RealEstate package will now be showing in the model view tree (if it isn’t, close and reopen the project). We open the diagram for Package_1 (which we rename to Habitation), and add shortcuts to the classes Person and Building. This is done by right-clicking in the design surface and selecting “Add | Shortcuts…”. We expand the tree and add the two classes, Person and Building. (If we were using a project group we would find the RealEstate package under both the RealEstate.dll node and the Habitation.dll node. Contrary to what one may believe, we should use the one under Habitation.dll. Using the other one will lead to errors, and, in all honesty, should not show there at all!)

 

We add a new class, ResidentialBuilding to the Habitation package, as a subclass of Building. We also add an association between Person and ResidentialBuilding. Dependencies are in the same direction as between the assemblies, thus classes in Habitation can inherit from classes in RealEstate but not vice versa, and associations must be unidirectional, navigable from Habitaion to RealEstate but not from RealEstate to Habitation. These constraints are automatically maintained by the modeling surface. You’ll notice how the added association arrow points from ResidentialBuilding to Person.

Managing cross-package relationships

With each package being stored in its own .ecopkg file, and allowing references from elements in one file to elements in another, there is the opportunity for inconsistencies. You may end up with one file containing references to a class that cannot be found. If this happens, ECO will not be able to generate code for the model. After update 2, the code generator will display the message ‘Model error|  "": Possible missing class. Are all necessary ecopkg files included in the project?’ in the message pane. Before update 2, the message is a less informative “object reference not set to an instance of an object” exception. I will show you what to avoid, by way of example.

 

We have an application containing two packages, RealEstate and Habitation. A class is added to each and an association drawn between them. RealEstate.ecopkg is saved by opening it in the project manager and pressing ctrl-s. Then, the project is closed without saving Habitation.ecopkg. RealEstate.ecopkg now contains a reference to a class in Habitation that does not exist.

 

We have the model in two assemblies, RealEstate.dll and Habitation.dll, with Habitation.dll referencing RealEstate.dll. The class ResidentialBuilding in Habitation is a subclass of the class Building in RealEstate. The class Building is deleted from RealEstate. The next time Habitation is opened, ResidentialBuilding’s superclass can not be found. (Unfortunately, using a project group would not have helped. Because the projects are treated separately, a change in the RealEstate.dll project is not automatically detected in the Habitation.dll project)

 

We have an existing project with two packages, RealEstate and Habitation. We now want to create a new project that reuses the existing model. We add Habitation to the new project, but forget to add RealEstate. Any references from classes in Habitation to classes in RealEstate will now be broken.

 

But what if we, despite our best efforts, find ourselves with missing classes? Is our model irrevocably lost? Of course not!

You will find the source of a small utility here, ECO Cross package resolver. It will find broken references and let you repair them.

 

Share This | Email this page to a friend

Posted by Anders Ivner archive on June 27th, 2006 under Uncategorized | 1 Comment »

Bye, bye WinFS…

You have probably heard by now: WinFS is dead. Finally.

Good riddance. It was vague, complex, and offered no clear value.

I have been keeping half an eye on it since ObjectSpaces was killed^H^H^H^H^H^Hmerged into it. It now appears that the jinx has moved on to the Entity Data Model, a new ADO.Net feature.

Share This | Email this page to a friend

Posted by Anders Ivner archive on June 26th, 2006 under Uncategorized | 5 Comments »

DRY

I came upon this article about the DRY (Don’t Repeat Yourself) principle, which is a nice piece of advice about how software should be developed. It’s a bit old, but I wanted to forward it nonetheless. I find myself in violent agreement; it rather accurately describes what has always been one of the major design goals of ECO, although we’ve never had a catchy acronym for it :-).

Share This | Email this page to a friend

Posted by Anders Ivner archive on March 13th, 2006 under Uncategorized | Comment now »

Not-so-obvious code generator behaviour collected…

I have collected various pieces of not-so-obvious behaviour of the ECO code generator into a document. You can find it here.

Share This | Email this page to a friend

Posted by Anders Ivner archive on March 1st, 2006 under Uncategorized | 1 Comment »

Not-so-obvious code generator behaviour collected…

This article lists various issues, tips, and advanced uses regarding the code generation in ECO 3. I had collected them, originally thinking I would edit the document into something with more literary qualities than a grocery list. But now I’ve decided (after a friendly nudge from Jesper) to just dump them out pretty much unedited. Enjoy.

—

In Delphi, the following class names cannot be used:

Add
Contains
Create
IndexOf
Insert
Item
Remove

—

There are situations when you risk losing code you have placed in the generated classes if you make changes to the model.

Method bodies will be lost when:
setting abstract = true
setting Body <> ""
setting Is trigger = true

property getters/setters will be lost when:
setting HasUserCode = false

DeriveAndSubscribe methods will be lost when:
setting DerivationOCL <> ""
setting Derived = false

—

In Delphi, if you add code to the constructor it will not be automatically maintained. This means that if you change the superclass, the call to inherited Create may get the wrong signature (inherited Create; vs inherited Create(ecoServiceProvider);). You need to adjust this manually. If you have not modified the constructor body, the code generation will manage this for you.

—

A namespace containing ECO classes cannot have the same name as one of the classes.

—

If you want a different file structure to your code than the default provided to you by ECO it is possible to modify it yourself.

In c#, you can change the namespace(s) that the ECO classes are contained in as you see fit. Pressing "regenerate" will ensure that all references that use fully qualified names are updated.

You can rename the files as you see fit. If you do, ECO will no longer maintain the file names when you rename classes and packages.

You can cut-and-paste the classes to change how they are divided into files. The only requirement is that the I<classname>List declaration is in the same file as the class.

—

In delphi, unit names will not be automatically removed from the uses list (because we don’t know if there is a reason you may have added it manually). This means that there is a risk of getting units that recursively uses each other. Just remove the offending uses manually. Regenerate will re-add the necessary units if you accidentally removed too many.

—

There is one known bug: If you generate with one-file-per-class in delphi.net and have a unidirectional association with 0..* multiplicity the name of the referred class will be added to the uses list, which will cause a compilation error. You can remove the faulty unit name from the uses list manually. A nicer workaround, which will ensure that the code generator does not add the faulty unit name again, is to enclose it in an ifdef, like this:

{$IFDEF WORKAROUND}
   SomeClassUnit.SomeClass,
{$ENDIF}

where the WORKAROUND symbol is undefined. This will fool the code generator into thinking that SomeClassUnit.SomeClass is already in the uses list, whereas the compiler will ignore it.

—

 

Share This | Email this page to a friend

Posted by Anders Ivner archive on March 1st, 2006 under Uncategorized | 1 Comment »

How (not) to delete ECO objects

I thought I’d share the following little bit of obscure ECO knowledge that I discovered "the hard way" just recently.

Let’s say we have a 0..* association end. Let’s call it, with an ECO team member’s usual lack of imagination, OwnedBuildings. Now, we want to delete all the objects therein, i.e. we want to delete all the buildings owned by a specific person. How do we do that?

Knowing that we can’t use a normal foreach (C#) or for … in (Delphi) loop, we might try something like:

for i := OwnedBuildings.Count-1 downto 0 do
  OwnedBuildings[i].AsIObject().Delete();

And that is going to work in 99% of all cases. In fact, it’s probably more than that, as code like this has existed in ECO itself and its predecessor for at least five years without disturbing anyone. That is, until a couple of days ago.

So, what could cause this code to break? The answer is Cascading Delete. If, when you delete an Order you want the Orderlines of that order to be deleted as well, that’s what Cascading Delete does. Now, in the above loop this means that when the Building with index 17 is deleted it is possible that other buildings that are in the list will also be deleted, so that when owned building number 16 is subsequently accessed we get an index out of bounds exception. Ouch.

A better way to write the loop would be:

while OwnedBuildings.Count > 0 do
  OwnedBuildings[OwnedBuildings.Count-1].AsIObject().Delete();

Can you figure out how to provoke this bug in ECO 2? The first correct answer wins a cookie!

/Anders

 

Share This | Email this page to a friend

Posted by Anders Ivner archive on September 12th, 2005 under Uncategorized | 7 Comments »

Metadata musings…

Steve Cook, one of Microsoft’s guys behind Software Factories and Domain Specific Languages, wrote briefly about his view on metadata. I was reminded of the striking similarities between the underlying philosophies of ECO and SF. Modeling languages and runtime frameworks is a powerful combination and I expect that style of development to become increasingly popular in the next couple of years.

Is ECO a Software Factory, I wonder?

Share This | Email this page to a friend

Posted by Anders Ivner archive on February 23rd, 2005 under Uncategorized | 2 Comments »

Server Response from: dnrh2.codegear.com