Back to Questions
1.4k
views4
comments
TemplateBinding incompatible with F#
f#

The "TemplateBinding" in XAML requires that the bound DependencyProperty is a public static field. It cannot be a private field, and it cannot be a property. But F# requires that all static 'val' fields must be private (unlike in C#, where static fields can be public). So it seems that TemplateBinding is simply incompatible with F#.

I would like to see this fixed. After all, it's a feature of XAML, why should I be confined to C# or VB? The question I have is where should it be fixed... in F#, or in XAML?

I would hesitate to choose either, so I would like to hear any feedback you guys have on this. I personally lean toward the side that F# is "good" in that it discourages the use of public fields, while XAML is overly restrictive. But they both are inconsistent in their role in this problem:

  • In F#, static val fields must be private, but instance val fields can be public. I don't quite understand the inconsistency here.
  • In XAML, a Binding may be used on a static DependencyProperty property or field. A TemplateBinding may only be used on a static field. Again, inconsistent.

I am using the F# 2.0 release. By the way, there is a workaround. Use a binding with "RelativeSource={RelativeSource TemplatedParent}". It works, but requires more typing and, according to some articles, results in slightly slower code than using a TemplateBinding.

.

I don't know Xaml at all (want to learn it with F#) but I know Brian McNamara posted an example of using F# with Silverlight. Doesn't Silverlight use Xaml? Maybe you want to look at his sample app?

Actually now that I think of it, he also posted a primitive RSS reader built with Xaml too.

If this is not what you're asking about--sorry. Perhaps you've already seen these samples and they don't answer your question.

Anyway, hope this helps.

By on 5/12/2010 12:50 PM ()

OnorioCatenacci,

Thanks for the links. Although they don't dive into using TemplateBinding (or, from what I noticed, Binding at all), they are quite interesting nonetheless.

By on 5/12/2010 1:39 PM ()

Wasn't sure that his examples included binding or not. Brian is often here so he may have some comment to help you.

By on 5/12/2010 3:19 PM ()

>The "TemplateBinding" in XAML requires that the bound DependencyProperty is a public static field. It cannot be a private field, and it cannot be a property.

If true, it sounds like the fix should be in the binding engine, not F# - bindings should reflect into more .net constructs than public static fields.

I suppose you could write some lightweight code-generation stuff to dynamically build static proxies that delegate to whatever objects you want, but that certainly seems like overkill.

I think I haven't run into this because I think the natural choice is to define objects that interact with the GUI (ViewModel objects) in C#, and access them from F# as needed.

Although, I do think that the F# lightweight class syntax is good for one-off, simple classes, I prefer the C# syntax when things get more complex - val's, [DefVals], do's, the restrictions you mention, lack of auto-properties, implicit field capture, etc., make even run-of-the-mill class definintions in F# look less attrictive, harder to document, and more verbose than necessary, which is a shame given how in the rest of the language the opposite seems to be true.

By on 5/12/2010 3:37 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper