Was going thru the Overview.htm, no reflector yet [:)]

Let's take this sample

[Export("ButtonCaption")]
public String providedCaption {

get { return "MEF Hello World!!"; }
}

How about this?

[Export]
public String ButtonCaption{
get { return "MEF Hello World!!"; }
}

In which case either the compiler steps in to export the property as "ButtonCaption" or maybe, even better, yourexport discovery engine somehow finds this and showsButtonCaption as an export.

IMHO, this will be the scenarios developers will be doing 9/10 times. I mean why do you need a different export name than the property in greenfield projects

Updated:
Well just found out, trying this in MefHelloWorld results in a ugly exception

---

::Rajiv

Thanks Rajiv. Frankly in your example above I'm not sure where it would make sense to export these properties individually. Could you clarify the scenario (what does it mean for an importer to just import Address? I mean why not just export the whole Person type then?
W.r.t. refactoring - if someone goes and changes public string FlickrName to FName, all importers have to go and change Import("FlicrName")] to Import("FName")?

Thanks,
Alex

---

Alex Bulankou, Microsoft Corporation. This posting is provided "AS IS".

Thanks Rajiv! This isinteresting. Currently the path that we took for unnamed exports is to derive the contract name from the type, not from member name, so for something like this:

[Export]
public String ButtonCaption{
get { return "MEF Hello World!!"; }
}

the contract name would be "System.String", which makes little sense in a real application.

However it may make sense for my custom type

[Export]
public ButtonCaption MyButtonCaption{
get { return new ButtonCaption("MEF Hello World!!"); }
}

now the contract becomes "MyNamespace.ButtonCaption" - something that an importer clearly can make use of.

So I guess the question I have it - what would you prefer - former (deriving the contract from themembername)or the latter (member type)? Or some hybrid of both - depending on whether it's 'primitive' type or a custom type?

---

Alex Bulankou, Microsoft Corporation. This posting is provided "AS IS".

Sorry for the late reply. Looks like the alert on the new forums is not working.

I see your point which is - the string in Export("ButtonCaption") is just a moniker for the return type?

This sort of makes sense, because we are aiming for type safety here, as I understand.

However, I think we really don't program/ model our exports apps in terms of type, but rather in terms of the property that has a type
This will allow scenarios like the following which are very intuitive to use.

Class Foo
{

[Export]
public String ButtonCaption1{
get { return "MEF Hello World1!!"; }
}

[Export]
public String ButtonCaption1{
get { return "MEF Hello World2!!"; }
}

}

The resolved exports being Namespace.Foo.ButtonCaption1 and Namespace.Foo.ButtonCaption2.

In this case the importer can look for the specific export as well as try to use any export of the same type?

Sorry I can't see how you would allow this scenario, using the resolution scheme you point out. Do you allow 'overloading' to resolve the collision?

---

::Rajiv

>>The resolved exports being Namespace.Foo.ButtonCaption1 and Namespace.Foo.ButtonCaption2.
>>In this case the importer can look for the specific export as well as try to use any export of the same type?
>>Sorry I can't see how you would allow this scenario, using the resolution scheme you point out. Do you allow 'overloading' to resolve the collision?


Currently for something like that you'd just have to be explcit (Export("ButtonCaption1"), since [Export] without specifier would just produce the name based on the return type and thus the contract would be the same. Metadata could be used to further describe components with the same contract but in this example it would just be simpler to specify a different contract explicitly.

So, based on your reply I understand you would actually prefer that [Export] without specifier would result into a contract derived from member name, right? It's interesting to see feedback like this because I've always thought unnamed [Export]-s are already ambiguous and you're offering a different intepretation of what [Export] without a name might/should mean.

---

Alex Bulankou, Microsoft Corporation. This posting is provided "AS IS".

Yes exactly, I would prefer resolving unnamed [Export]s (standard syntax :)] to the member name because:
1. That's more intuitive and compact syntax. Convention over configuration is what I would do. I can actually write code as
Class Person
{
[Export] public string Name{get;}
[Export] public string Surname{get;}
[Export] public string Address{get;}
[Export] public string City{get;}
[Export] public string Country{get;}
[Export] public string FlickrName{get;}
[Export] publicfloat Salary{get;}
...
}
2. Note in the above example multiple properties with different underlyying types are exported.
3. Refactoring for renaming properties will be much simpler without tool support. I can swiftly change the non-export name and not have to change the export name string that comes with it. In fact this is the scenario I dread most.Assuming people will mostly use the default [Export] rather than [Export("External Name")]
4. I look at the [Serializable] usage pattern as the inspiration where the default is as good a choice in 90% cases for me.

Thanks

---

::Rajiv

Thanks Rajiv. Frankly in your example above I'm not sure where it would make sense to export these properties individually. Could you clarify the scenario (what does it mean for an importer to just import Address? I mean why not just export the whole Person type then?
W.r.t. refactoring - if someone goes and changes public string FlickrName to FName, all importers have to go and change Import("FlicrName")] to Import("FName")?

Thanks,
Alex

---

Alex Bulankou, Microsoft Corporation. This posting is provided "AS IS".

I know it's a pathological example. But it makes a perfect case for demonstarting the compact syntax possible when I don't want to export the entire class but a bunch of say 10 properties.

For the second case, having a importer already is like game over. But not having one/thinking about one is when the ease of refactor will show up with the resolution scheme I am trying to make a case for.

---

::Rajiv