I’ve had a BA Executive Club account for about 18 months. During that time I must have been on perhaps 15 BA flights - some UK domestic, some within Europe, some to the US. For quite a while I’ve also had a BA-sponsored American Express card, which pays miles into my Executive Club account. I’m not flying on BA all the time, because I find that pretty hard to do - basically I wouldn’t pay extra to fly with a particular airline, and usually it’s hard enough to find flights that go to the right place at the right time anyway. Overall I certainly fly more than most people I know. I’ve collected roughly 30000 miles up to now - is that much? I don’t know.

Today I thought I’d look into something that I’ve never looked into before: see whether it makes sense to upgrade a flight with those miles. I’d tried before to use the online function to do that, but every time I’d been told there was some sort of problem and I should contact my "booking agent". Flight booked online, sometimes even through BA directly, so wtf is that about the booking agent? Why no proper information about what the problem is? Hm…

So I took the time to call them and spend 20 minutes in a phone queue. Of course it was the wrong phone queue - even though I’d taken the number from that online error page, there’s a different, Executive Club specific number I should be using. Okay, got transferred. Other girl, same problem, transferring me elsewhere again. Finally somebody who knows what to do, he looks at my booking and goes "well, that’s not the right kind of ticket". What? Kind of ticket? "Yes, you should have a ‘flexible’ ticket so you can change it later. When booking online, there’s a choice between a cheap and a flexible ticket." Ah, how stupid of me.

I ask the guy if I could theoretically get anything useful for my 30000 miles on my flight to Orlando and it turns out that 25000 miles will buy me an upgrade to World Traveller Plus. Wow! Hallelujah! Just 18 months of careful airline selection and already can I afford 10 additional centimetres of leg room! So he goes, "I’m going to call our sales guys and ask them what the upgrade to a flexible ticket would cost for the trip." Comes back, and it turns out that upgrade costs about 420 quid. I say hey, that’s a bit expensive, isn’t it and he replies "no, and that’s just for one leg of the trip because <weird stuff here> - you can’t get the upgrade on the way back, but for the one leg it’s just 12500 miles".

Phew. That’s it, is it? Pay around 3 times the price for the London-Orlando leg of the trip to get a flexible ticket, and then 12500 miles to upgrade to the next, almost identical, class of travel. Frickin’ unbelievable.

Now, people tell me there’s more to frequent flyer programs - for instance, when you fly enough within one year, you get into a higher class and then you get all sorts of benefits like 150% miles on the mile (What’s the idea with "miles" anyway? The miles I get credited don’t have any similarity to the distance between the start and end of my flight.) and free upgrades to higher classes. Well, BA do 125% and 150% miles, yes. Other benefits available here (or probably not, because you have to be a privileged person with your own login in order to see this). But as far as I can tell they never give me any free upgrades, whatever I do. And most importantly, to be a better Executive Club member than I am today, I need to collect Tier Points. Now wtf are Tier Points suddenly? Check my account - I have ZERO of them. I need another 600 and 4 qualifying flights to get to Silver membership. Hm…

Looking around, I see where to get Tier Points from. Obviously I don’t get them from the kinds of flights I always use, otherwise I’d have some. But there’s a wild list stating that depending on the class and area I fly in there are 20 different fare classes (yes, really!) and all of them collect Tier Points (no further details). For some reason apparently I manage to travel outside these classes all the time - no info on that either.

Now how to figure out what fare class a ticket is in? Oh, easy: look at your boarding card. Yes, that card you get at the airport to carry around for an hour. And yes, the info is on that part of the card that gets ripped off and taken away from you when you board your plane. If you have some form of printed ticket that nobody uses anymore these days, it might also be on there. E-Tickets? Nah, not on there. Well, go figure.

Eat shit, Executive Club.

In my continuing efforts to make XPO work fully with F#, I found the next problem to deal with: the extremely linear way of thinking of the F# compiler.

Basically, the compiler seems to read each source code file from top to bottom. Generally, things that are defined below the current line can’t be referred to in the current line. Apart from the order of lines in source code files, the order of source code files in the project is equally important, since the compiler handles them in precisely that order. 

Hint for Visual Studio users: While the order of source code files in the project is represented correctly in the Visual Studio Solution Explorer, it can’t be changed from there. Instead, it is necessary to edit the project file and swap source code files around manually. Right-click the project in Visual Studio and select "Unload Project" from the context menu. Right-click the project again and select "Edit <projectname>.fsharpp". When you’re done making your changes, use the context menu a third time to select "Reload Project". You will see that the order of files in Solution Explorer has changed according to the changes you made in the project file.

In some schools of though on programming, this linear view of things might seem quite normal, but in .NET it is not. In main-stream .NET programming, it was widely regarded a great innovation when C# took care of the old problems that C and C++ had in that regard (no more header files!!!). Pascal wasn’t any better, and many other languages - most of them had some sort of "pre-declaration" feature that had to be used when, for instance, a reference to a certain type needed to be created before the type itself was declared. Nothing like that in C# — the compiler looks at all the types and namespaces declared somewhere in my current project and figures things out for me. Great, that’s how it should be.

In all fairness, in F# there’s at least one very obvious reason why the compiler takes that linear approach: type augmentations. They basically mean that depending on the position in code, a class might have a certain member or not. If you’re not familiar with the feature, look at this example:

type MyClass() =
    let answer = 42
	
let mc1 = new MyClass()
	
// At this point Output can't be found on mc1
//mc1.Output()
	
let output x = printfn "%d" x
	
type MyClass with
    member x.Output() = output 52
	
let mc2 = new MyClass()
mc2.Output()
	
// Now Output is part of MyClass, so I can even call
// it on my "old" instance
mc1.Output()

The particular case I’m dealing with is that of persistent business class hierarchies. These hierarchies are typically interrelated to the point where one or more networks of classes are formed. As an example, consider modelling a hospital. You’d have a whole bunch of different types of people to store, so you’d have classes for People and Addresses, Employees, which might be Nurses, Doctors and cleaning and housekeeping personnel, Patients with relationships to the Nurses and Doctors, Rooms, Floors and OperatingTheatres which are assigned to Doctors or Teams of Doctors. Visitors, CarParks, the whole Accounting and Booking business… the list is endless. It is quite clear that many of these types have references to many other types, and typically a one-to-many relationship is modelled with a collection property on one end and a simple reference on the other end, so as soon as there’s a relationship there, it will result in two classes interrelating.

Sure, not all classes interrelate, so it might be possible, taking a lot of time and great care, to separate the classes into groups that are hopelessly tangled, but have only unidirectional references outside the group. Of course it might make sense in the example above for almost all classes to have a reference to the Hospital type, since that is important if there’s ever more than one hospital being handled at once. There might be other such "special", high-level objects that make the grouping approach really complicated. In any case the task of sorting the classes into such groups is extremely tedious and the grouping breaks easily, as soon as any class is changed to include or exclude a property that refers to another class. You might wonder why I’m going on about the grouping thing at all — well, read on, that’s what F# wants me to do.

Have I mentioned that persistent business class hierarchies can be large? Apart from having private fields and public members for each and every piece of data that is associated with the various entities, the classes will typically also contain certain parts of business logic functionality. Depending on the architectural approach that is used, validation logic might live in these classes, as well as a lot of the state handling that many entities need. To mention some numbers, a C# project I’ve worked on myself — really just a medium size application — has 75 persistent classes and a total of 11263 lines of code in these classes.

type ClassA() =
    let foo = new ClassB()
	
and
 ClassB() =
    let foo = new ClassA()

As you can see, this uses the "and" keyword to concatenate the two type declarations. This doesn’t hold true for classes only, but for all types. One of my first thoughts about this was that it shouldn’t be that much of a problem if my application made use of lots of interfaces and dependency injection throughout to remove the need for direct references from one class to another. But in the end this approach only shifts the problem to the interfaces - at a rough count, that class hierarchy from my old project would require me to declare 75 interfaces with 520 properties and around 300 other members. For those declarations, the problem is still the same, and while the volume may be smaller, it’s still significant. Plus, of course, it requires my application architecture to work in a very specific way, I need to create all those interfaces for no real reason whatsoever, … doesn’t sound like a very good idea.

In the end I don’t think that this problem is entirely particular to my use case. In other class hierarchies, dependencies might typically be somewhat more linear than they are in those hierarchies I’ve described, but interrelations are still rather common. So here are the important points I want to make:

The next problem I found in my efforts to make XPO work with F# is documented here: Null values for F# classes - basically, I can’t just set a variable that has a reference to another object to null in F#.

The general assumption in F# is that null values are a threat and so the languages discourages their use. I totally see the point and if all I wanted to do was create classes (or perhaps not even those) for use in F# itself, I wouldn’t have a problem with it - but interop is an important thing for F#, as I see it, and all the rest of the .NET world makes elaborate use of null values. Null values are the (rather more dangerous) alternative to F# Options to most .NET developers - exactly the same purpose, just a less elegant implementation.

I haven’t given up on the Hub yet, although I have to say I haven’t received any useful replies from there yet… and the people who do reply are rather those that like to write forum posts than those who really know what they’re talking about Anyway, perhaps I’ll get lucky with a blog post again - Brian, are you still reading?

UPDATE: I found the solution to this problem in the release notes for F# 1.9.4: use the Unchecked.defaultof<T> function. I guess that’s the new functionality that was referred to earlier. Great!

Something I just stumbled upon. I was configuring Shorewall 4, and there’s a flag called DISABLE_IPV6 in shorewall.conf. Oh yeah, I thought, that makes sense - I don’t yes IPV6, so I’ll set that to Yes. Did so, and when I ran Shorewall it showed my lots of error messages like this:

FATAL: Module ip6_tables not found.
ip6tables v1.3.8: can't initialize ip6tables table `filter': iptables who? (do you need to insmod?)
Perhaps ip6tables or your kernel needs to be upgraded.

Well, I don’t have ip6_tables compiled, which is just the reason I liked that flag when I saw it. Read the source, and I found that the flag doesn’t mean "don’t use IPV6", but rather it means "use ip6tables to take some special action to disable IPV6". Well.

I searched for the piece of documentation I was missing (because I wasn’t assuming there’d be anything to misinterpret about the meaning of that flag), but I still can’t find anything… apart from this forum post where somebody states "… this is because in a perversely twisted form of logic the configuration file requires you to have IPV6 support to be able to disable it …" Well put.

I have been working on getting a sample for using XPO from F#. My first sample was easily created back in January this year:

#light
open DevExpress.Xpo
type Person = class
  inherit XPObject as base
  public new(session : Session) = { inherit XPObject(session);
    name = string.Empty
  }
	
  val mutable private name : string
	
  member public x.Name
    with get() = x.name
    and set(v) = x.name <- v
end
	
let person = new Person(XpoDefault.Session)
person.Name <- "Wally"
person.Save()

This works just fine - great. Now I wanted to create a slightly more evolved sample using more of the standard XPO features, and use that to develop some best practices. I also had the idea to create some CodeRush templates similar to those we have for C# and VB.

All this turned out much more complicated than I thought, for a variety of different reasons. The first issue I stumbled upon was that I can’t call our standard helper method SetPropertyValue correctly from F#. It looks like a bug to me, since I did a lot of very similar tests, and only with the precise combination of parameters and return type that this method has does the F# call to it fail. If it’s confirmed to be a bug, it’ll get fixed - but so far I haven’t heard anything, and I want a workable solution now.

I started working on one - see below -, but first I had to decide which type of mutable fields I was going to use for my persistent classes. F# allows class fields to be declared "mutable", which means they can be changed (if this sounds like an ordinary thing to you, I recommend you read up on your functional programming theory <g>). It also allows to declare values as "ref cells", which wraps the actual values in an additional class internally.

Our standard SetPropertyValue method uses a "ref" parameter in its C# implementation. Of course that method isn’t working anyway, so I was considering writing my own helper method for the time being. C# ref parameters are not something F# deals with extremely gracefully in my opinion, the main reasons for which are probably that changeable values are not foremost in peoples’ minds in that language, and there’s support for multiple return values using tuples, so the use cases from ref parameters are much reduced anyway. The only way (afaik - a topic I’m still a little unsure about) that F# ever passes a parameter by reference is if the value I’m using is a ref cell in F#.

The problem with using multiple return values instead of the by-reference type method, whether we’re talking about the standard helper method or a new one, is that it changes the requirements of the syntax at the call site. Optimally, I would like the helper API to be very easy to use. I also want to perform change notification from within the helper method. Using multiple return values, the pattern could look like this:

let setValue oldVal newVal =
    ((oldVal <> newVal), newVal)
let testSetValue1 newVal =
    let mutable testval = 10
    // This is the line I'd need in my property setters
    match (setValue testval newVal) with | true, __n -> testval <- __n | _ -> ()
	
    printfn "testval: %d" testval
	
testSetValue1 10
testSetValue1 42

There are several things wrong with this. First, the line I need to use in each property setter is rather complicated. I’d integrate it in a template, but there are people who don’t use templates, and anyway it just looks wrong to reproduce that sort of thing in every single property. Second, the naming of the helper function is really no longer correct - it doesn’t actually set the value of the property anymore, it just finds out whether setting the value is required at all. Of course if that’s all I want to do, I should change the function’s name and I don’t need multiple return values after all… the real problem is that the actual setting of the value happens in the property setter code. And that brings me to third: if I was to integrate change notification in the helper function, this would now happen before the property change actually takes place (and that’s still assuming that it takes place at all, which is not under the control of the helper function anymore).

So all this looked bad to me and I decided to go with the by-reference type helper function after all. This works only if the value I’m actually setting from inside the helper function is a ref cell. In C#, it’s possible to take any given variable and pass a reference to it into a method that requires such a reference. Not so in F#, apparently. Unless a value is declared to be a ref cell, it can’t be used in this way. Declaring as a ref cell in turn means that there’s an extra wrapper class created for the value - quite a bit of unnecessary overhead it seems, particularly when dealing with large numbers of fields such as there are typically in persistent classes. But since ref cells are the only way to make the F# compiler pass something by reference, there’s no way around that. I did some additional tests with temporary ref cells and other things, but this only made the overhead worse, not better. So I decided to accept things as they are and move on.

One other thing I should mention about ref cells: they require special syntax when used in code, basically they need to be dereferenced in order to access the actual value. So instead of writing "foo" to access the value foo, I now have to write "!foo" (yeah, looks like "not foo", but it’s not, if you know what I mean <g>). Quite inconvenient as well, if you write a lot of business logic in your class and prefer to use the private field directly. Probably better to use the public properties where possible, then you don’t have that problem.

My next step was to try and pull the helper functions which can’t be called in their original C# implementation into F# as a workaround. That looked pretty simple to begin with - our C# implementation is actually quite a bit more complex because we have to jump through some hoops to get the equality comparison right (that’s the reason for having the conflicting overloads I mentioned earlier). I created a base class that I was going to use for further objects:

type FSharpBaseClass =
    inherit XPObject as base
    public new(session: Session) = { inherit XPObject(session) }
    member public x.SetPropertyValueFS propertyName oldVal newVal =
        let needsSetting = !oldVal <> newVal
        if needsSetting then
             oldVal := newVal
        x.OnChanged(propertyName, !oldVal, newVal)
        needsSetting

And lo and behold, here’s the next inexplicable F# issue: I can’t call the OnChanged method! Again, no idea why that is - I did a bunch of tests with very similar setups and all of these work. OnChanged can’t be called though, I get a compiler error: Error 5 A protected member is called or a base variable is being used. This is currently only allowed in the direct implementation of members since they could escape their object scope.

Of course there’s not a single page that Google can find about this problem, that would have been boring. Ah well. That’s it for today in any case. To be continued.