Strongly Typed Primitives

discount furniture » Strongly Typed Primitives

discount furniture » Strongly Typed Primitives — Fri, 15 Aug 2008 16:38:52 GMT

PingBack from http://informationsfunnywallpaper.cn/?p=740

re: Strongly Typed Primitives

Josh — Fri, 15 Aug 2008 16:40:43 GMT

Thanks Simon,

“I can’t really think of a convincing reason why one of these would be better over the other to be honest – I guess Josh’s approach means you could have different collections of commands (WebCommands, WindowsCommands, SomeOtherCommands), but I’ve never needed to do that. Any other reasons you can think of?”

Imagine you write a logging component (generic example again) for use throughout your enterprise and you want to use stongly typed primitives (nice turn of phrase btw). You can’t know now all the possible entries that people would want to use. So the primitive itself lives next to the logging component itself but the instances of the primitives would live in a separate assembly per application that uses the component.

re: Strongly Typed Primitives

simonince — Fri, 15 Aug 2008 16:47:13 GMT

@ Josh;

I like it. In fact, come to think of it there are similarities to when I was building a navigation framework targeting both web and windows. I made a vague reference to this with my "Screen" class here;

http://blogs.msdn.com/simonince/archive/2008/06/16/wcsf-application-architecture-4-environment-abstraction.aspx

I forget exactly how it worked but I had to create different instances of the class because I wanted to use it to encapsulate information about how to actually navigate to a screen too - which obviously is very different in the web and windows worlds.

Hmm.

OK, so I think my approach is the version for beginners, yours is the posh one :-)

Strongly Typed Primitives

DotNetKicks.com — Fri, 15 Aug 2008 17:15:09 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: Strongly Typed Primitives

MichaelGG — Fri, 15 Aug 2008 22:45:28 GMT

You can also make it generic so everything can fit in a small static class:

public static class Command

{

public static readonly Id<Command> Profile = (Id<Command>)"Profile";

public static readonly Id<Command> WebExecute = new (Id<Command>"WebExecute";

}

Now the type name is just a marker so you can do everything with a single class, and just pick the best name (Command versus CommandName). I posted the code I use here:

http://www.atrevido.net/blog/2008/08/15/Typing+String+IDs.aspx

(Although, if you don't care about performance and nullability issues, a class-based inheritance system may provide more benefits.)

re: Strongly Typed Primitives

simonince — Mon, 18 Aug 2008 11:13:38 GMT

@ Michael;

nice post, and good point. I think the only thing about using generics is that you can't use the class to store more information. So although Josh's example is for strings, I've used this approach to store a string name and a string URL together - which makes defining a generic to cover all situations difficult.

Having said that, I totally agree in a lot of cases it would work.

One minor point - I'm not sure I like casting to an Id<Command> - I'd always prefer the 'new Id<Command>("WebExecute")' syntax, as it seems more explicit. Just personal taste, perhaps!

Simon

re: Strongly Typed Primitives

MichaelGG — Mon, 18 Aug 2008 19:33:35 GMT

Ah, yes, keeping multiple items would be a pain right now. More reason to lean on the .NET teams to add tuples as first class citizens :).