[Discussion] How tightly is this coupled to IL?
See original GitHub issueHey @kekekeks, I’m looking through the architecture of this and wondering how tightly coupled to generating IL this is? As you know, I’m trying to get an effort started around unifying xaml tooling across all platforms. Both PresentationBuildTasks (WPF) and the UWP markup compiler have tight dependencies on the platforms, so what you’ve done here is incredibly interesting to me 😃.
With WinUI, we have c++ customers to support, so we can’t depend on IL. I also have a feeling we’d need a way to switch out backends so we could continue to generate BAML for WPF and XBF for UWP, IL for Avalonia, etc.
Also, and this might just be me, but all the IXamlIL*
types are hard to read, mostly because of the lIL
letters in succession. It also makes me think that the whole thing is tightly coupled to IL, which I’m sure is not true, but it’s also hard to get out of my head 😃
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:14 (7 by maintainers)
@worldbeater just to be clear, I want to keep this conversation going, but I’m not able to make any guarantees at the moment because we really need to focus on WinUI3.
I am personally a big fan of this idea, but there is still some work that needs to be done in order to integrate ~XamlIl~ XamlX into those platforms, such as
x:Bind
,x:Load
, andx:Phase
for WinUI. With WinUI3, we just don’t have the time or resources to dedicate to this, as we have other higher priorities, like making sure we have parity with existing experiences.@maxkatz6 WinUI should hopefully be able to replace WPF. But that doesn’t mean we won’t make the proper investments in WPF if they have the proper cost/benefit. Primarily, anything that makes the migration from WPF->WinUI easier is an area of interest. If sharing the same core compiler tech is able to provide value in that regards, then that would make the case for moving to XamlX even more compelling.
There are some other considerations for WinUI as well since we use WinRT (based on COM). There shouldn’t be a problem using XamlX for our .NET customers, but we would have to think about what to do for C++. In general, I think the two things we need to do are:
XamlDirect
would just go through the regular code path.This should be doable, so these aren’t major blockers or anything.
The compilation process is basically split into two steps:
{x:Null}
while others have separate “emitters” like PropertyAssignmentEmitter since the IL generation logic was too huge to fit into rather small AST node itself .I’m not really familiar with type metadata that’s available for C++, but if it has types, properties, methods and enums in a form that is easily accessible from C# code, we could make a type system backend based on said metadata and convert the resulting AST into C++ code which could be feed to C++ compiler and won’t require any runtime parser support.
Not sure how compatible it would be with BAML. XamlIl essentially takes a XAML document and converts it into AST that consists of imperative commands like “create an instance of type Foo”, “set the property of created type to X”, etc. Some AST nodes represent local variables.