Interface based implementation

[Matt-17]

Will there be an interface so I can create an own implementation? So for example when you create a new UI framework for Monogame, it would be pretty good to have an interface to create it compatible to the standard.

[mossyblog]

How do you mean? Can you show an example (pseudo code)

[h82258652]

Good idea, I agree with you. Button implement IButton interface, TextBlock implement ITextBlock interface.

[dotMorten]

I'm curious what would there be on that interface for say IButton, and what purpose would the interface serve? Do you have some concrete example that this solves, that ButtonBase doesn't already handle? Also what happens when we want to extend it later without getting into the IButton2, IButton3, IButton4 hell ?

[lokitoth]

To add a bit more to @dotMorten's comment: This seems like a platform implementation detail, rather than part of XAML spec. In essence, the spec itself is the interface definition, because XAML itself doesn't have bearing on what the runtime needs to be, so conceivably XAML could work with a language that doesn't even support interfaces / pure-virtual classes / whatever.

Tying the XAML spec to a particular runtime / language seems like an unnecessary constraint.

Indeed, once the spec exists, nothing stops you from creating a reference implementation precisely how you describe it. Though you'd end up having to deal with IXyz when adding new functionality.

[birbilis]

Interfaces (or UML or even VS class diagrams if you prefer) are a way to create concrete definitions in machine parsable form. Text documents isn't unless you define a formal language for them, in which case you just made a custom DSL for describing contracts.

In my opinion we should get XSD (XML Schema) for the standard if possible

[birbilis]

Note that an interface can define a PME (Property-Method-Event) model, whereas here it seems we're only focusing on P and E (since E can be treated a bit like an "Event Property") parts. So definition of standard methods (like Button.Click [or Button.DoClick if you prefer]) is missing.

Neither exists any modelling of common features between components (like say and IHasName/INamedObject/INamed, IVisual, IContainer etc.)

Maybe such a thing could be a scope of a separate effort, e.g. somebody's prototype XAML Standard implementation could use such a scheme and provide it for reuse by others too

[birbilis]

and other thing is I see no format (and machine parseable) language for describing the standard being used. Not sure if XSD could cover this need, probably together with some BNF for the special string values (e.g. the Binding syntax etc.)

[birbilis]

Just noticed W3C uses IDL (Interface Description Language, like those in DCOM/CORBA/etc.) to describe interfaces used at the DOM:

This section describes a language, Web IDL, which can be used to define interfaces for APIs in the Web platform. A specification that defines Web APIs can include one or more IDL fragments that describe the interfaces (the state and behavior that objects can exhibit) for the APIs defined by that specification. An IDL fragment is a sequence of definitions that matches the Definitions grammar symbol. The set of IDL fragments that an implementation supports is not ordered. See IDL grammar for the complete grammar and an explanation of the notation used.The different kinds of definitions that can appear in an IDL fragment are: interfaces, partial interface definitions, namespaces, partial namespace definitions, dictionaries, partial dictionary definitions, typedefs and implements statements. These are all defined in the following sections. Each definition (matching Definition) can be preceded by a list of extended attributes (matching ExtendedAttributeList), which can control how the definition will be handled in language bindings. The extended attributes defined by this specification that are language binding agnostic are discussed in §2.12 Extended attributes, while those specific to the ECMAScript language binding are discussed in §3.3 ECMAScript-specific extended attributes.

https://heycam.github.io/webidl/

used here: https://dom.spec.whatwg.org/#document (from DOM Standard document) http://w3c.github.io/html/dom.html (from HTML5.2 editor's draft)

[birbilis]

btw, one could possibly use or adapt code refactoring tools and/or use Roslyn where possible to extract class info as interfaces out of existing control hierarchies in WPF, Silverlight, UWP, Xamarin.Forms. Tool could have some rules on stuff to ignore etc. Could give some insight and maybe also allow to compare hierarchy tree structures and individual controls (interface diff).

[birbilis]

speaking of "implementation" here, would be nice if there was a XAML Standard implementation provided as a portable prototype, where all controls would be implemented in XAML (using Paths etc.) itself (that is define some basic XAML drawing primitives and use them to implement the controls)

[dersia]

I think having interfaces could also make the implementation of XAML standard much easier.

Like a lot of NuGet packages today that support .NetStandard often called *.Abstraction and then there will be the basic implementation. look at the following:

Xaml.Standard.Abstractions:

• Xaml.Standard.Abstractions.IButton
• Xaml.Standard.Abstractions.ITextBlock

Xaml.Standard.Wpf:

• Xaml.Standard.Wpf.Button : Xaml.Standard.Abstractions.IButton
• Xaml.Standard.Wpf.Button : Xaml.Standard.Abstractions.ITextBlock

Xaml.Standard.Xamarin:

• Xaml.Standard.Xamarin.Button : Xaml.Standard.Abstractions.IButton
• Xaml.Standard.Xamarin.Button : Xaml.Standard.Abstractions.ITextBlock

Xaml.Standard.Html:

• Xaml.Standard.Html.Button : Xaml.Standard.Abstractions.IButton
• Xaml.Standard.Html.Button : Xaml.Standard.Abstractions.ITextBlock

looking at this examples this would also allow for others to create Control-Packs. This way my Assembly won't need to reference the Wpf standard one, if I don't want to use it, I could just go with MyCompany.Xaml.Wpf.Button.

Thinking of the new default implementation for interfaces (maybe coming with c# 8.0) this could be even more interesting.

[birbilis]

Could call them Models (or will MVVM people bite?). Also, don't see (though I haven't thought about it much) why a separate namespace would be needed. Maybe better is to have each one in the same namespace as the current implementations. And probably not just for controls, but for everything reusable (and that could have multiple alternative implementations) should have interfaces.

Not sure about cost in deployment size. Wish there was option for inline interfaces too (compiler-time only ones like in Typescript) for those that may worry about such things