4

Is it possible in XAML to declare an alias name for a type?

Let me explain with an example. Given these type declarations...

namespace Somewhere
{
    public class Blob { … }
    public class BlobCollection : List<Blob> {}  // "type alias" in C#
}

... the following (abbreviated) XAML should be valid:

<BlobCollection xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                xmlns="clr-namespace:Somewhere;…">
  <Blob … />
  <Blob … />
</BlobCollection>

I already know that I can define something like type aliases through inheritance (see code comment above). Suppose that wanted to do the same in XAML, how would I have to change the XAML in order to be able to refer to BlobCollection as Blobs?

<Blobs xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
       xmlns="clr-namespace:Somewhere;…">
  <Blob … />
  <Blob … />
</Blobs>
stakx - no longer contributing
  • 83,039
  • 20
  • 168
  • 268
  • Aliasing `BlobCollection` to `Blobs` sounds like a bad idea anyhow. It goes against the standard naming convention. A plural of blobs makes sense for a property or field name, but not for a type name. Readers of your code would have to read the aliasing line to understand what is going on. In programming, reducing character count to save keystrokes is a false economy, unless you are very careful to make zero impact to readability. – Merlyn Morgan-Graham Sep 04 '11 at 21:05
  • @Merlyn: I am aware of that. Let's briefly consider a SQL database, where you have a table of `Blob` records: You'd likely call the table `Blobs`, even if you had an ORM set up that maps the table to a C# `BlobCollection`. So why shouldn't the same be done with X(A)ML? -- The standard naming guidelines of .NET do not necessarily have to apply everywhere. – stakx - no longer contributing Sep 04 '11 at 21:27
  • I appreciate your challenge to my assumptions. I haven't seen any articles about naming conventions in XAML that specifically address this scenario. However, XAML is still .Net code - it is just an object tree/initialization block specified in an XML language. `Blobs` is an abstraction that makes sense in your data layer. I wouldn't propagate that naming all the way up to the UI layer, for the same reason we'd change naming when using an ORM. – Merlyn Morgan-Graham Sep 04 '11 at 21:35
  • 2
    @Merlyn, I agree that having the same names everywhere would be helpful for someone who works with both the X(A)ML side *and* the C# side. However, imagine that (a) there is a fully automated framework on the C#/code side, and the XAML author will only ever directly work with the top-level C# object; or (b) the XAML is written by someone, and consumed in code by someone else. In both cases, it could actually be beneficial to provide each side with a suitable vocabulary, which *might* differ where it makes sense. (I appreciate your input, btw.) – stakx - no longer contributing Sep 04 '11 at 21:44
  • 1
    Making a deliberate decision is the most important part here. Slaving yourself to dogma isn't. I'm happy the input has been considered and if it helped you form a more concrete opinion :) – Merlyn Morgan-Graham Sep 04 '11 at 21:49

1 Answers1

4

I'm not sure if you can do the aliasing directly in XAML, but it's easiest to use the aliased name in XAML by simply subclassing the collection in code (or heck, renaming the collection class itself if it won't adversely affect the rest of your code):

public class Blobs : BlobCollection {}

It does seem unnecessary to have to do this, but it's all I can think of right now.

BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
  • 1
    I fear that this is the only solution; but I'm hoping someone knows a XAML-only way to achieve the same thing. I've updated my question. – stakx - no longer contributing Sep 04 '11 at 20:21
  • 2
    +1; @stakx: If this is something you'll bolt on to generated or existing code (your comments on the OP seem to indicate this), then you still have an option of creating another assembly that just defines your aliases, and importing that. If this is just getting around generics support, then [it seems like such support might already exist in more recent XAML standards?](http://msdn.microsoft.com/en-us/library/ee956431.aspx). If you can't use more recent XAML standards, there's also [other questions on work-arounds for generic support](http://stackoverflow.com/questions/185349/) – Merlyn Morgan-Graham Sep 04 '11 at 21:52
  • 1
    @Merlyn: Thanks for the hint about generics support in XAML 2009.Updated my question to reflect that it's not just about generics. – stakx - no longer contributing Sep 04 '11 at 22:01