softlogger Latest Articles ::Object-Oriented-Concepts

What's wrong with one of GetNumberFormat's callers? And what's wrong with GetNumberFormat?

Sorting It All Out — 2008-03-10T00:00:00

Please read the disclaimer; content of Michael Kaplan's blog not approved by Microsoft!

Some of you may recall Igor Levicki, the guy who had 64-bit keyboards working before MSKLC 1.4 was released who I mentioned in If you just don't think you can hold it (64-bit style!).

The other day he sent me mail about a bug (actually a small bundle of bugs, but the bug he found was a crash bug) in a third party application (name withheld to protect the guilty, and also the embarrassed!).

Igor looked at crash via the disassembly, which I'll put here just for the sake of completeness. If you are the same kind of person you can work along here and try to find the problems within the disassembly:

; Exported entry 592. ?GetDoubleFormat@CAppUtils@@SAPB_WNH@Z

; wchar_t* __cdecl CAppUtils__GetDoubleFormat(double, int)

        public ?GetDoubleFormat@CAppUtils@@SAPB_WNH@Z

?GetDoubleFormat@CAppUtils@@SAPB_WNH@Z proc near

var_108        = qword    ptr -108h
LCData         = word ptr -0D4h
Value          = word ptr -0D0h
var_4          = dword    ptr -4
arg_0          = qword    ptr 8
arg_8          = dword    ptr 10h

        push    ebp
        mov    ebp, esp
        and    esp, 0FFFFFFC0h
        sub    esp, 0FCh
        mov    eax, dword_1007E01C
        xor    eax, esp
        mov    [esp+0FCh+var_4], eax

        fld    [ebp+arg_0]
        push    esi
        sub    esp, 8
        fstp    [esp+108h+var_108]
        lea    eax, [esp+108h+Value]
        push    offset aF    ; "%f"
        push    eax        ; String
        call    ds:_swprintf
        add    esp, 10h

        push    0FFh        ; cchNumber
        push    offset word_100873B0 ; lpNumberStr
        push    0        ; lpFormat
        lea    ecx, [esp+10Ch+Value]
        push    ecx        ; lpValue
        push    0        ; dwFlags
        push    400h        ; Locale
        call    ds:GetNumberFormatW

        push    2        ; cchData
        lea    edx, [esp+104h+LCData]
        push    edx        ; lpLCData
        push    0Eh        ; LCType
        push    400h        ; Locale
        call    ds:GetLocaleInfoW

        mov    esi, [ebp+arg_8]
        cmp    esi, 0FFFFFFFFh
        jz    short loc_10008344
        mov    eax, dword ptr [esp+100h+LCData]
        push    eax        ; Ch
        push    offset word_100873B0 ; Str
        call    ds:wcsrchr
        add    esp, 8

        test    eax, eax
        jz    short loc_1000833F
        lea    eax, [eax+esi*2+2]

loc_1000833F:
        mov    word ptr [eax],    0

loc_10008344:
        mov    ecx, [esp+100h+var_4]
        pop    esi
        xor    ecx, esp

        mov    eax, offset word_100873B0

        call    sub_10059B35
        mov    esp, ebp
        pop    ebp
        retn

?GetDoubleFormat@CAppUtils@@SAPB_WNH@Z endp

From assembly it is pretty hard to know whose application it is, but what is happening in this one function is not too hard to figure out.

Now for those who really aren't as comfortable working this way where you have watch parameters get placed on the stack an such (though it should be fairly straightforward to work with in this case for those so inclined!), here is some essentially equivalent C code:

wchar_t Formatted[256];

wchar_t *GetDoubleFormat(double Value, int DecimalPlaces) {
        wchar_t Buffer[MAX_PATH];
        int     DecimalChar;

        _swprintf(Buffer, "%f", Value);

        GetNumberFormatW(LOCALE_USER_DEFAULT, LOCALE_NOUSEROVERRIDE, Buffer, NULL, Formatted, 255);

        GetLocaleInfoW(LOCALE_USER_DEFAULT, LOCALE_SDECIMAL, &DecimalChar, 2);

        if (DecimalPlaces != -1) {
                wchar_t *Point = wcsrchr(Formatted, DecimalChar);

                if (Point != NULL) {
                        Point = Point + DecimalPlaces + 1;
                }

                *Point = 0x0000;
        }

        return Formatted;
}

Now this bit of code is as veritable bug farm of how to misuse the NLS API.

What it is trying to do, with many of the bugs embedded in the descriptive language for easy retrieval:

Format a passed in double with the current user default locale and allowing no user overrides.
Retrieve the numeric decimal separator, allowing user overrides.
Search backward through the formatted string looking for that decimal separator.
Increment the pointer to be the passed in number of places after the decimal separator plus one.
Stick a NULL there, effectively truncated the formatted string there.

Originally Igor was thinking this might have even made a great entry for The Daily WTF, and I'm not gonna disagree with him on that.

The crash bug Igor had run into initially was based on the fact that he had Serbian locale settings with a customized decimal separator -- thus the user override mismatch in #1 and #2 above quickly led to a problem searching for a "." in a string such as "44,90" -- then after properly detecting that wcsrchr returning NULL for failure, a somewhat catastrophic situation arises when it tries to dereference that NULL in order to assign to it.

Basically what they (apparently) wanted to do was format a number with the user's preferences but overriding the user's choice of the number of decimal places. The resulting string is put in their user interface, returning the result to the user in a property sheet.

Worse ways of achieving that goal have been reported in code reviews, but not by reliable witnesses.

(There are other silly/problematic issues here, such as:

LOCALE_SDECIMAL can be up to two characters; this code assumes it is always one (note that this is a problem most code tends to have)
The retrieved LOCALE_SDECIMAL value is stored in an &int, presumably to facilitate the later wcsrchr call, but which is less than ideal always (and in the case of #1 will guarantee incorrect detection behavior);
GetNumberFormatW assumes that space for the NULL is included in the buffer -- why allocate a wchar_t array of 256 if you are only going to pass 255 for the length? If the function cannot fit the NULL it will fail;
No return value checking for _swprintf, GetNumberFormatW or GetLocaleInfoW -- despite the fact that they can all return errors and some of the errors would have negative side effects on the intended operation of their GetDoubleFormat function.

Now in fairness to the people who wrote this code (whoever they are and whenever they wrote it), GetNumberFormat has some specific limitations that make it less useful and that make it more difficult to write the idealized version of this function.

I am going to enumerate the three big problems here as I see them, and Igor might have some additional thoughts on this matter either for comments here or on his own site. :-)

But the NLS team could think of this next bit as feedback to them on ways to make functions like GetNumberFormat better, faster, easier to use, and more generally useful.

First of all, since GetNumberFormat can only take a string rather than a number due to the lack of a LOCALE_SPECIFY_NUMBER flag (as I mentioned in Pass the string please, three years ago), the caller must format their number as a string via a function like _swprintf so that it can then format the number within the string as yet another a string -- and perhaps this is proof that I have changed my mind a bit since tha tblog; the NLS code really ought to help out more with the more common obvious cases when it can, such as this one.

Second of all (and perhaps most importantly), the longstanding behavior of GetNumberFormat that requires either a fully filled in NUMBERFMT in lpFormat or a NULL lpFormat means that the only way to specify an lpFormat->NumDigits value is to also fill in the lpFormat->LeadingZero, lpFormat->Grouping, lpFormat->lpDecimalSep, lpFormat->ThousandSep, and lpFormat->NegativeOrder values as well -- thus requiring up to five calls to GetLocaleInfo for information entirely derivable from the passed-in locale (assuming one value being overridden).

There are any number of alternate possible ways it could have been done -- like establish the NULL case for the struct as being the default which means "take the locale's data", or specify values that mean the same thing, or even define flags to specify which values to pay attention to in the structure (there is room in the dwFlags for this both this function and GetCurrencyFormat!).

Third of all, where GetNumberFormat always requires either a fully filled in NUMBERFMT in lpFormat or a NULL lpFormat, if you don't pass in that filled-in NUMBERFMT then the code behind the function always grabs all of the information even if it does not need it -- meaning for example that it will grab the user overridable lpFormat->ThousandSep even if the number is not big enough to need it according to the number itself. The upshot of this is that the performance of the function is much better if you pass in the lpFormat yourself if you have the data handy -- because the function is not smart about how it does its work.

Now one may argue against that type of optimization due to potential thread safety issues caused by SetLocaleInfo calls happening while number formatting is happening, but given that this is already really a bit of a problem in the code terms of consistent number formatting in such situations (and also how uncommon SetLocaleInfo calls or user-specific Regional Options changes that amount to SetLocaleInfo calls actually are), there are much better solutions for this problem that are possible. Much moreso than the current solution (trying to front-load all of the data loading calls to minimize the number of possible SetLocaleInfo calls that could happen). And many of those better solutions would be more performant, too!

On top of all that, this front-loading in the case of the NULL lpFormat happens when LOCAL:E_NOUSEROVERRIDE is specified, too -- meaning there is no thread safety issue all but the code is happy to fill a structure with six separate data items without ever returning the data it loaded to the caller (in case they were going to call the function repeatedly). If one has to pay the price, one would like a bit more for one's money, in my opinion....

If those issues did not exist, then all of the work done by the third party GetDoubleFormat could happen in a single very fast function call, rather than a whole bunch of code, such as the buggy code Igor pointed out in the version of the third party application he was looking at.

Now none of this excuses the bugs in the third party application -- that code screws up the usage of NLS functions with multiple bugs including some that crash? They have no good reason to have those.

But if the NLS function did a bit more of the work here, perhaps the kind of developers who were going to make those mistakes when left to their own devices would have one less opportunity to do so?

Now for the interactive bit of this blog (and incidentally of this Blog):

Any developers want to take a stab at implementing the

wchar_t *GetDoubleFormat(double Value, int DecimalPlaces)

function without any of the numerous aforementioned bugs? :-)

This blog brought to you by . (U+002e, aka FULL STOP)

Testing TempData in ASP.NET MVC

Ben Scheirman — 2008-01-30T00:00:00

Eventually when testing your controllers you will come across an action that sets TempData.

If you didn’t know, TempData is a session-backed temporary storage dictionary that is available for one single request. It’s great to pass messages between controllers.

Our Controller classes that we derive from have this as a member property. However, when testing the controller, this always came up as null.

Reflector is our friend here, so I fired it up and loaded the Controller class. Then I located the TempData member, and looked at the setter. It’s marked as internal, so somebody inside this assembly is responsible for creating it. By using the Reflector Analyze feature, I was able to find exactly where the setter is called. It’s in the Execute() method. (this is the general “pipeline” method that all IController implementations must override)

Think about that for a second. At runtime, the TempData dictionary is set because all requests flow through Execute(). But in my test, I am specifically calling my action method. There is no Execute() in my test.

To top it off, I can’t set this guy to a new TempDataDictionary because the setter is marked as internal.

Phil Haack tells me they’re working on this issue so we’ll likely see an improvement soon. In the meantime you can get around the issue by using reflection to set the value. But first, can we create one?

TempData is stored in session, so it needs a reference to IHttpContext. Thankfully, we can mock this, however we have to make sure and mock the right parts.

First, create a mock for IHttpContext, create the return values for mocked IHttpRequest & IHttpResponse. Finally setup return values for IHttpSession as well. I’ve done all of this in a helper method of my test (though it could be an extention method on the MockRepository ala Phil, but whatever you like).

private IHttpContext GetHttpContext(string requestUrl)
{            
	IHttpRequest request = _mocks.DynamicMock<IHttpRequest>();
	SetupResult.For(request.Url).Return(new Uri(requestUrl));


	IHttpResponse response = _mocks.DynamicMock<IHttpResponse>();
	IHttpSessionState session = _mocks.DynamicMock<IHttpSessionState>();
        IHttpContext httpContext = _mocks.DynamicMock<IHttpContext>();

        _tempData = new TempDataDictionary(httpContext);
        SetupResult.For(session[null]).IgnoreArguments().Return(tempData);			

	SetupResult.For(httpContext.Session).Return(session);
	SetupResult.For(httpContext.Request).Return(request);
	SetupResult.For(httpContext.Response).Return(response);
        _mocks.Replay(session);
        _mocks.Replay(request);
        _mocks.Replay(response);
        _mocks.Replay(httpContext);
        return httpContext;

}

This code is a little verbose, but this is something you write once and use in all of your tests. You should notice that the _tempData property is a local field on my test class. I can then take this _tempData variable and inject it (via reflection) onto the controller under test. Here's how:

typeof(FooController).GetProperty("TempData").SetValue(controller, _tempData, null);

And now we can easily test that messages are set in TempData before redirecting or rendering a view.

Using Inheritance in JavaScript Behaviors

Aspects of AJAX — 2008-01-05T00:00:00

While working on some samples using (different) menubar, I found it helpful to inherit a JavaScript Behavior from a more general JavaScript Behavior. This would give me the chance to implement the common general Javascript methods only once and leave specific functionality in the derived Behavior.

Here is the sample:

// this is a basic behavior definition for menubars
var MenubarBehavior = {
  init: function () {
    // activate the hover effect on all menu items
    var allitems = this.getElementsByTagName("*");
    for (var o in allitems)
      if (allitems[o].className == "VEMenu") {
        allitems[o].hover = true;
      }
  },
 
  onkeypress: function(evt) {
    evt = evt || window.event;
    var kc = String.fromCharCode(evt.keyCode);
    if ((this._attachedBehaviour.onclick != null)
      && (evt != null) && ((kc == " ") || (kc == "\r"))) {
      this._attachedBehaviour.onclick.call(this, evt);
    } // if
  } // onkeypressed
} // MenubarBehavior

This is a basic implemenation that enables the hover effect for all VEMenu items found inside the menubar and to simulate a click event if the spacebar or return key is used while the focus is on a menuitem.

// this is a basic behavior definition for menubars
var EditMenubarBehavior = {
  inheritFrom: MenubarBehavior,
 
  init: function() {
    MenubarBehavior.init.call(this);
  },
 
  onclick: function(evt) {
    evt = evt || window.event;
    var src = evt.srcElement;
    var cmd = src.name;
    if (cmd != null) {
      cmd = cmd.split(';');
      HtmlEditBehaviour.Command(cmd[0], cmd[1]);
    }
  } // onclick
} // EditMenubarBehavior

This is the implementation of the derived Behavior definition.

If you ask why I do not use the JavaScript inheritance mechanism, then you have a good question - i tried.

Using the new operator and the prototype mechanism does not work here because we attach methods to HTML elements and some other problems came up too.

The article of Nicholas C. Zakas at: http://www.sitepoint.com/article/javascript-objects also describes the topic.

You can find the state of the current implementation here:

http://www.mathertel.de/AJAXEngine/S04_VisualEffects/InlineEditDemo.aspx

(see the page source by using the view link in the upper right corner)

The only code I had to add to the LoadBehaviour method (that does something very similar to the extends method of Zakas) are these 3 lines of code to recursively bind the Behaviors starting with the base class.

if (behaviour.inheritFrom != null) {
  this.LoadBehaviour(obj, behaviour.inheritFrom);
  this.List.pop();
}

See controls/jcl.js (view source)

(I'll publish a new version of the framework as a zip here file when this sample is finished).

Data Layer Testing: Test Inheritance Patterns

ISerializable - Roy Osheroves Blog — 2007-11-29T00:00:00

I'm preparing for my tutorial on Database and Data Layer unit testing that I will be giving at the Agile Practices Conference next week. It's always nice to have a full 3 hours to get pretty deep into something. 75 minutes just isn't enough to grasp a concept deeply enough, just to graze it around the edges.

When writing data layer tests, there are several patterns I've noticed, especially around the notion of inheritance within the test classes (Abstract test class pattern). I've observed at least three different patterns emerging from inheritance that I've personally used, all relating to data layer testing, but could be used elsewhere:

Abstract Utility Class

This class will usually be a base class for tests written for data layer objects. it would contain "facilities" such as database helper classes, setup and teardown methods that would automatically rollback any test and anything else a derived base class that was testing a data layer object would need (helper methods for asserting complex stuff, for example).

This is a classic "Abstract test class" pattern, and the next two are built on top of it.

Template Test Class

The template test class will contain abstract methods as unit tests, which any derived class would have to override and perform. That means that if you are always testing the same things against a data layer object (insert returns different IDs, update works etc...) test authors on new data layer classes who derive from this class will never forget to implement at least these basic tests.

they would also get the facilities for doing assertions and other things from the base class, as depicted in the previous pattern. makes sure you don't forget tests, saves some time on the infrastructure.

Abstract Driver Test Class

This class will have non abstract test case methods inside it that will always run the same way. these test methods will call (using abstract methods) to the derived class' implementation of type specific actions (insert specific for a category, or update specific to person) .

That leaves the derived class to only implement very basic things such as insert (and return the ID), update, or delete (by ID). the test methods in the base class will do the rest of the work. derived classes don't need to implement any tests unless they want to add type specific tests which don't belong on the base class.

in the image to the left the green methods are tests that the base class runs, and the yellow ones are type specific helpers that the derived class has to implement.

this makes writing tests for a new data layer object (as long as its interface is the same) very simple by inheriting a test class and implementing a few methods. all the test permutations in the base class will then run on the data layer object. saves lots of time and forgetting tests.

What patterns have you come across?

Visual Basic 2008 - Introducing Extension Methods

mike mcintyres — 2007-09-21T00:00:00

Note: This article is based on Orcas Beta 2 (Visual Studio 2008).

Extension Methods

Visual Basic 2008 extension methods enable you to "add" functionality to existing types without creating a new derived type.

Types That Can Be Extended

· Classes (reference types)

· Structures (value types)

· Interfaces

· Delegates

· ByRef and ByVal arguments

· Generic method parameters

· Arrays

Extension methods make it possible to create a method in a Visual Basic module that can be called as if it were an instance method of another type.

An extension method can be a Sub procedure or a Function procedure. You cannot define an extension property, field, or event. All extension methods must be marked with the extension attribute from the System.Runtime.CompilerServices namespace.

The first parameter in an extension method definition specifies which data type the method extends. When the method is run, the first parameter is bound to the instance of the data type that invokes the method.

In the following example an extension method is defined for the .NET String type.

Example – Add ‘Display’ extension method to .NET String type

The following code defines a Display extension method for the .NET String data type. The method uses MessageBox.Display to display a string. The type of the aString parameter of the Display method, establishes that the method extends the String class.

' You must define type extensions in a Visual Basic module.

Module ExampleTypeExtensions

'All extension methods must be marked with the extension attribute

' from the System.Runtime.CompilerServices namespace.

Public Sub Display(ByVal aString As String)

MessageBox.Show(aString)

End Sub

End Module

The following code, in a button click handler in a Windows form, calls the String ‘Display’ extension method defined above.

Public Class Form1

Private Sub DisplayStringButton_Click _

(ByVal sender As System.Object, ByVal e As System.EventArgs) _

Handles DisplayStringButton.Click

Dim name As String = "John Doe"

name.Display()

End Sub

End Class

Result

The name 'John Doe' is displayed in a message box.

Notes

You can use extension methods to extend a type’s methods, but not to override them.

All that is required to be able to run extension methods is that they be in scope. If an extension method is in scope, it is visible in IntelliSense and can be called as if it were an ordinary instance method.

Notice that when the ‘Display’ extension method is invoked in example, no argument is sent in for the first parameter. Parameter aString in the extension method definition is automatically bound to the instance of String that calls them.

Because the first parameter specifies the data type that the extension method extends, it is required and cannot be optional. For that reason, Optional parameters and ParamArray parameters are excluded.

When an extension method has the same name as an existing method but a different signature, both methods are allowed as long as the signatures do not conflict.

When an extension method has the same name and signature as an existing method in the type being extended, resolve ambiguity by using the fully qualified name to specify the extension method you are calling. In the example the Display extension method is defined in a module named ExampleTypeExtensions, the fully qualified name is ExampleTypeExtensions.Display.

In general, it is recommended that you implement extension methods sparingly. When possible, client code that extends an existing type should do so by creating a new type derived from the existing type.

When using an extension method to extend a type whose source code you cannot change, you run the risk that a change in the implementation of the type will cause your extension method to break.

Mike McIntyre

http://www.getdotnetcode.com

Entity Framework - Post 1 of "Many", providing some links

Mike Taultys Blog — 2007-08-09T00:00:00

Note: Some of the posts referenced in this post (!) are likely to be more out of date than others but I still feel that they are very much worth reading.

Whilst waiting for new Entity Framework bits to experiment with :-) I thought I'd start to write something about the Entity Framework and expand it over the coming weeks or months. This is mainly a "link" post to pull a few things together.

The Entity Framework is a new technology from the ADO.NET team.

The last time we had goodies from ADO.NET, it was in ADO.NET V2.0 where we (just like in V1.0) had the abstracted DataSet, DataTable and the provider-specific Connection, Reader, Adapter, Command classes that interact with a specific store.

You get a level of abstraction from ADO.NET 2.0 because you can program through generic interfaces rather than get involved with the particulars of (say) a SqlCommand or an OracleCommand but, ultimately, you still end up writing code that is store specific because you have to use T-SQL or PL/SQL with those commands in the end and differences in the underlying stores (such as what happens with stored procedures) ultimately bubble up through the abstraction.

There are also some factory bits in ADO.NET V2.0 to make it easier to create one or another provider's Commands (etc) by hiding the creation behind a factory wall.

So that's where we've been for quite a few years now but when ADO.NET 3.0 comes along it brings with it a whole new level of abstraction with the Entity Framework which has the potential to have a huge impact on the way in which we access data.

The big new idea of the Entity Framework is to stop querying the data store directly altogether and to start querying a conceptual model (an ER model) instead with a mapping technology that can translate your queries to the specifics of a store.

The Entity Framework calls this conceptual model the "Entity Data Model" or EDM.

This has a bunch of advantages such as;

The logical model of the relational store often isn't what an application developer wants to program against and writing explicit code to map it isn't productive.
The logical model of the relational store often isn't what a report writer wants to write a report against (and we've already seen a similar mapping approach in today's Reporting Services).
It's not always desirable to tie the application to the specific SQL dialect of one store (but it's very difficult to avoid it with ADO.NET 2.0).
It would be nice to make modifications to the store without altering the app but, instead, just altering the mapping.
It would be nice to potentially move to a different store without modifying the app but, instead, just altering the mapping.

You can get a lot more background information on the Entity Framework by;

And you can learn more about the Entity Data Model by;

Reading the whitepaper here
Reading this post and then following it with this post
Possibly adding in some of this post

In order to make all this work the Entity Framework has to be capable of offering query capabilities against the EDM whilst translating those to the logical model of the store.

It does this by providing a new ADO.NET provider, the EntityClient provider which slots into the existing ADO.NET extensibility model by providing a Command, Reader, Adapter, Connection.

In order to learn a little more about EntityClient check out;

This post on EntityClient
And this post which explains what this means for provider writers to plug-in to Entity Framework (i.e. it's not free :-))

Queries written against the EntityClient are written in Entity SQL (eSQL) which looks like SQL languages that we already know and love but also has some pretty snazzy capabilities.

To learn more about Entity SQL;

Check out this post (warning - this post requires caffeine as it's really good but quite long and fairly complex in places).

In order to translate those queries for the specific store, the EntityClient provider has to perform a translation which it does by consulting 3 metadata models (typically, but not necessarily (AFAIK), provided as XML documents);

Your EDM - this is described in "Conceptual Schema Definition Language" (CSDL).
Your store - this is described in "Store Schema Definition Language" (SSDL).
The translation between the two - this is described in "Mapping Schema Language" (MSL).

Of these, the SSDL is perhaps the most likely one that you can just have generated for you by pointing a tool (and there is one - edmgen.exe) at an existing store and saying "get me the SSDL from that store".

As it happens, you can also get CSDL and MSL generated but that's only really going to work for the scenario where you have a 1:1 mapping between your EDM and your store.

To learn more about Mapping;

So, with those necessary bits and pieces in place you can now do the "ADO.NET thing" and query this EDM model through the EntityClient provider in order to execute eSQL against that conceptual data model. So, you can write code like;

EntityCommand cmd = conn.CreateCommand();
cmd.CommandText = "SELECT p.ProductName, p.UnitPrice FROM NorthwindEntities.Product AS p";

And if you go ahead and execute that command and get yourself a reader and that reader will come back with 2 "columns" in it and it's the same old procedure that we're used to to enumerate and get those values out (i.e. while (reader.Read()) { reader["ProductName"], reader["UnitPrice"] }

To learn more about querying;

Read this post.

Something important to point out here - as far as I'm aware, you can only query the EDM model via eSQL. You can't update it that way - from looking at the current eSQL command reference there is no INSERT, UPDATE, DELETE right now and so you have to rely on other services of the EntityClient provider to do the CUD parts of your CRUD operations.

At that point you might be thinking - "Huh? What other services?" because the provider is already doing quite a bit of work to offer up this new SQL-like language and translate it into the underlying logical schema but it does a lot more than that. It also offers something that goes by the name of "Object Services" which essentially takes the EntityClient and its EDM and offers Object Relational Mapping on top of that.

As far as I know, the mapping between the .NET Type layer and the EDM layer is 1:1 right now but I think that's just a default rather than a limitation. So, you can get direct access to the EDM by pulling collections of .NET types (e.g. the Customer type for the Customer entity defined in the EDM) out of the store and programming against them. The "Object Services" layer includes things that we've seen before in ORM layers including things like identity management, change tracking, transaction integration/management, automatic generation of insert/update/delete operations, concurrency management, integration of stored procedures and/or functions, easy navigation of relationships and so on

To follow up (a little - it's not a very long post) on Object Services check out;

This post

and there's some specifics around;

Also, there's quite a lot in that post I referenced on eSQL about how results are projected that plays into these object capabilities as well.

Now, it really wouldn't be very good if all of these capabilities didn't tie in to the "new kid on the block" - i.e. LINQ coming with Visual Studio 2008 so, depending on your needs, you can choose to write eSQL yourself or you can go ahead and use LINQ to Entities and define the queries using your language syntax (against the .NET types generated from your EDM) and get all the benefits of compile time checking, IntelliSense and so on that LINQ gives you.

That's pretty much all the references I wanted to share except that there's also an MSDN Magazine article to take a look at as well - provides a very good overview.

If you've managed to read all of this stuff then (like me) you're probably chomping at the bit for new Entity Framework bits to go with Visual Studio 2008. Maybe it's time to check back and see if they came out yet! :-)

Operator Overloading Considered Insanely Useful

Software As Shes Developed — 2007-08-03T00:00:00

Programming, SelfDocumenting, Sugar, Syntax

I am amazed that for all the talk about future Java features, there is hardly any mention of operator overloading. Certainly syntactic sugar is high on the priority list, with the Java world starting to realise the benefits of powerful literals and closures. (Good thing too. Steve Yegge: "Java's biggest failing, I've decided, is its lack of syntax for literal data objects. It's an umbrella failing that accounts for most of the issues I have with the language."). Yet operator overloading is another feature that no real-world language should be without, and hardly anyone gives a second thought to the fact that time has moved on since the concept was rejected in 1995.

In Java:

earnings2007.greaterThan(earnings2008)

In Ruby/Python/C++/C#/anyOtherDynamicOrNonDynamicLanguage:

earnings2007 > earnings2008

Of course, many a Java destractor has noted the irony that is String."+" overloading, which is to say that Java's creators broke the rule and did something you can't do, by making "a"+"b" a legal operation, even though String in theory is just a run-of-the-mill Java class. This is a subtle way of saying maybe there are cases where operator overloading makes sense; at least, the people who prohibited it thought so. I think it's called "do as I say...".

The arguments against operator overloading are pretty much the same as those against dynamic classing and make a trade-off in favour of robustness over productivity which is rarely warranted. The reality is that production errors are hardly ever caused by typing confusion, as long as you make the operator definitions meaningful. I can trust you to do that because you're a professional, right? Even if your testing regime consists of nothing more than dipping your web server into your bowl of Corn Flakes every weekend, I challenge you to come up with a production error caused by confusing String.+() with Integer.+(). If you can grok earnings2007.greaterThan(earnings2008), I'm sure you'll do just fine with earnings2007 > earning2008. The only problem with operator overloading comes when people do stoopid things with operators, and you can just as equally do stoopid things with method names (or booleans if you want to get really sad ), so why victimise the operator?

People will say "can't have operator overloading - it leads to weird code that doesn't make sense", which would be like banning electric guitars because someone might use it to make weird music.

I would take overloading further than what we do today. e.g. how about multiple operands:

assert(x < y < z)

You could do that with today's terminology by having < return some kind of state object instead of just a boolean. So what I'm talking here is as much about patterns as new language features.

How about more visual representations:

∫_Ω v Δ u dx = ∫_Ω ∑_i v_x_i u_x_i dx + ∫_∂Ω v

----

Yes, that's right, a formula that looks like a formula. Surely this is the natural extrapolation from current trends - (a) domain-specific languages, where the code looks like the requirement; (b) smart IDEs. I discussed this a while back with reference to the (now-defunct?) Jackpot project. Operator overloading is one piece of that puzzle.

BCL Refresher: Converting the Non-Generic Collections [Inbar Gazit]

BCLTeams WebLog — 2007-06-25T00:00:00

As you know generics were only introduced to the .NET Framework in version 2.0. Originally we had a lot of collections in the System.Collections namespace that can store objects. In version 2.0 we added the System.Collections.Generic namespace to support generic collections that can store any specific type.

If you have legacy code or even if you kept using the old non-generic collections for other reasons you may want to consider converting your code to use the generic collections instead. Here are a few reasons why:

Readability and simplicity of your code. Let’s take the case of getting the first string in a list of strings. With generics you would declare List<T> myList = new List<T>(); and then say string firstString = myList[0] just like working with arrays. This syntax is much more simple and readable than what you used to have to write which was ArrayList myList = new ArrayList(); and then string firstString = myList[0] as string;
Performance. Every time you add a value type to a non-generic collection you have to box it to make it an object and every time you retrieve a value type from a non-generic collection you have to unbox it back from object. Even with reference type you still need to cast back to the correct type when retrieving items.
Working against new smaller Framework SKUs. In Silverlight we decided to remove all the concrete non-generic collections completely from the codebase. This is mostly because the Silverlight core managed libraries is set to be the smallest useful set of classes. It’s also possible that other future small frameworks will not have the non-generic collections in store. If you ever plan to write code for those frameworks — you should convert it to use the generic collections.
Better type-safe libraries. If you are developing libraries to be consumed by 3^rd parties you should most definitely use generic collections when possible. This would allow consumer of your libraries to quickly figure out what’s expected to be stored in the collections instead of having to guess or figure out from documentation.

OK, so now I convinced you that you should go back and revise your existing code (not to mention any new code you’re writing) to use generic collection but how exactly should you go about it?

Luckily, most of the non-generic collections (with the exception of BitArray) have very good generic counterparts. The following table illustrates what type to replace for what:

Non-generic	Generic replacement
ArrayList	List<T>
BitArray	List<Boolean> [note that this isn’t stored as compactly as BitArray but represents the same information]
CaseInsensitiveComparer	Comparer<T>
CaseInsensitiveHashCodeProvider	Comparer<T>
CollectionBase	Collection<T>
Comparer	Comparer<T>
CompatibleComparer	Comparer<T>
DictionaryBase	KeyedCollection<K,V>
DictionaryEntry	KeyValuePair<K,V>
Hashtable	Dictionary<K,V>
KeyValuePairs	KeyValuePair<K,V>
Queue	Queue<T>
ReadOnlyCollectionBase	ReadOnlyCollection<T>
SortedList	List<T>
Stack	Stack<T>

Notice that in most of these cases you would have to figure out what the T is in the generic class. This assumes you used to store just one type of elements in your collection. If you are storing more than one type you should find the common base-class. In the worse case you can use Object but that would lose most of the benefits of generics.

Let’s look at an example:

This is the old code using non-generic Stack:

using System;
using System.Collections;
 
Stack MRUFiles = new Stack();
MRUFiles.Push("first");
MRUFiles.Push("second");
MRUFiles.Push("third");
Console.WriteLine(MRUFiles.Pop() as string);
Console.WriteLine(MRUFiles.Peek() as string);
Console.WriteLine(MRUFiles.Pop() as string);
Console.WriteLine(MRUFiles.Count.ToString());

Same code would look like this using generic Stack<String>:

using System;
using System.Collections.Generic;
 
Stack<string> MRUFiles = new Stack<string>();
MRUFiles.Push("first");
MRUFiles.Push("second");
MRUFiles.Push("third");
Console.WriteLine(MRUFiles.Pop());
Console.WriteLine(MRUFiles.Peek());
Console.WriteLine(MRUFiles.Pop());
Console.WriteLine(MRUFiles.Count.ToString());

Additional considerations when making the change:

List<Boolean> is not a good enough replacement for BitArray when it comes to the use of memory. If you have a list of millions of bits, using a BitArray would have a much smaller memory footprint than List<Boolean> since it’s actually manipulating bits instead of storing each bit as a Boolean that takes 8 bits each. In addition methods such as And, Xor, Not, Or and SetAll will not exist and you’d have to implement them yourself
Dictionary<K,V> indexer behaves differently than Hashtable did when the key is not found. With Hashtable you would get a null whereas with Dictionary you would get a KeyNotFoundException. So, you would probably have to alter your code a bit to catch this exception and add code to handle this case. Note that you can add a null element to the dictionary and still get null but in the case of Hashtable you would not know when you get a null if it’s a case of a missing key or a case of a null element. You can also call the TryGetValue method instead of using a try/catch block and check its return value.
ArrayList.Add() returns the index whereas List.Add returns void. If your legacy code used to rely on the return value you would have to slightly change it to get the index from Count — 1 since you know it’s always inserted last.
ArrayList.ToArray() calls required not only providing the type but also casting the result to the appropriate array. For example: (String[]) m_list.ToArray(typeof(String)); with List<T> you don’t need to worry about this as it’s already in the correct type so you would have to change this to simply be m_list.ToArray();
If you are enumerating over a Hashtable you’ll have to change your code, here is an example:
BEFORE

IDictionaryEnumerator de = m_Datastore.GetEnumerator();

while (de.MoveNext()) {

ilcc.Datastore[(String)de.Key] = de.Value;

}

AFTER

IEnumerator<KeyValuePair<String, Object>> de = m_Datastore.GetEnumerator();

while (de.MoveNext()) {

ilcc.Datastore[de.Current.Key] = de.Current.Value;

}
Threading/Synchronization issues:
1. Hashtable.Item property is multiple-reader/single-writer thread safe, but Dictionary’s getters are not. If your application has a dependency on the thread-safety guarantee of this Hashtable property, but you want to convert Hashtable to Dictionary, then you’ll need to handle this case explicitly
2. Whereas the non-generic collections offered a synchronized wrappers through their APIs — e.g. Hashtable.Synchronized—the generic collections don’t.
If you want the quick “golden hammer” workaround to the thread safety issues, you can just lock on the SyncRoot of the Dictionary (after casting to ICollection), but this is most likely unnecessarily expensive for your app. But first we’ll first show the golden hammer technique. Note that wrapping every calls to Dictionary this way will perform the equivalent of Hashtable’s #7b behavior but is stronger than Hashtable’s #7a.

BEFORE

String myKey = "key";

String myValue = "value";

Hashtable myHashtable = new Hashtable();

Hashtable mySynchronizedHashtable = Hashtable.Synchronized(myHashtable);

myHashtable.Add(myKey, myValue);

AFTER

String myKey = "key";

String myValue = "value";

Dictionary<String, String> myDictionary = new Dictionary<String, String>();

lock (((ICollection)myDictionary).SyncRoot) {

myDictionary.Add(myKey, myValue);

}

The decision to remove the synchronized wrapped from generics was based on the observation that you often want to perform synchronization at a higher level in your application, and that our synchronized wrappers led to a false sense of security (and flawed code). This puts developers in the position of thinking more heavily about synchronization, but we decided this was the right call. This decision is discussed more thoroughly here: http://blogs.msdn.com/bclteam/archive/2005/03/15/396399.aspx.

As mentioned above, the golden hammer workaround (used with all calls to Dictionary, including reads) is stronger than #7a. If you lock before every call, then you can have at most one reader or writer at a time. However, the Hashtable.Item property is single reader/multiple writer threadsafe. If you want this same behavior, you can use a ReaderWriterLock or, if you have Orcas installed, ReaderWriterLockSlim.

In general, the best decision for the #7 conversion will depend on the needs of your app: do you want multiple reader/single writer thread safety? Do you want to lock on the Dictionary SyncRoot or a different object, to coordinate accesses among the Dictionary and another collection (discussed in above-mentioned blog)? You can use our suggestions as starting points and customize depending on the needs of your app.