You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first is decoupling XML literals from XLinq. So, for example, allowing XML literals to construct WinRT Windows.Data.Xml objects.
The second is basically XAML literals. We use XML literals all throughout the Roslyn test base to describe all kinds of testing scenarios but it's all parsed and created at runtime. What if we could use target typing to actually have that expression create an object graph. Lucian had been thinking about way of doing this involving methods declaring that they Handles a particular element or attribute appearing in source. Could be worthwhile.
Powerful, but maybe too much complexity? We need a more thought out design.
There are two uses I have in mind.
The first is decoupling XML literals from XLinq. So, for example, allowing XML literals to construct WinRT Windows.Data.Xml objects.
The second is basically XAML literals. We use XML literals all throughout the Roslyn test base to describe all kinds of testing scenarios but it's all parsed and created at runtime. What if we could use target typing to actually have that expression create an object graph. Lucian had been thinking about way of doing this involving methods declaring that they
Handles
a particular element or attribute appearing in source. Could be worthwhile.Powerful, but maybe too much complexity? We need a more thought out design.
Could also cheat and do this with #107 I suppose.
The text was updated successfully, but these errors were encountered: