Comments on: C#: Extension methods != Open classes

By: brad

brad — Thu, 19 Feb 2009 16:51:38 +0000

There is a very important reason they didnt allow you to muck w/ private/internal stuff in a class (w/o using full trust + reflection that is): the internals of a class should be free to change from release to release without fear of mucking up something in the clients code. That is why so many things inside the .net framework used to implement the exposed API are marked internal. Every public class/method they add makes it harder to change in the future and a larger testing burden.

By: Steve

Steve — Thu, 19 Feb 2009 08:23:55 +0000

That’s what you get for using a static language instead of a dynamic language like ruby

By: Pat

Pat — Thu, 19 Feb 2009 08:23:49 +0000

Treat them as synatic sugar (over calling some *Util class with static methods). They were definitely not intended to be the same thing as open classes.

By: Mark Needham

Mark Needham — Thu, 19 Feb 2009 07:39:45 +0000

Good point, didn’t think of that. In which case I guess we’ll need truly open classes in order to do that

By: Reflective Perspective - Chris Alcock » The Morning Brew #290

Reflective Perspective - Chris Alcock » The Morning Brew #290 — Thu, 19 Feb 2009 07:26:34 +0000

[...] C#: Extensions methods != Open classes – Mark Needham reminds us that extension methods do not mean our classes all instantly become Open Classes (in the sense of the Open Closed principle). One of the key missing features is the ability to override using extension methods. [...]

By: Robin Clowers

Robin Clowers — Wed, 18 Feb 2009 22:45:53 +0000

Since extension methods compile down to a static method, they cannot have any instance level state. Hence, no properties.