51–60 of 69 posts
Earlier quoted context omitted.
I don't think .NET Framework is a supper set of all other implementions of .NET. For example, Mono's SIMD types are not in .NET Framework. It is even possible for types to exist in .NET Core that don't exist in .NET Framework. I think you could say the following: .NET ECMA Spec ⊆ .NET Standard .NET Standard ⊆ .NET Core .NET Standard ⊆ Mono .NET Standard ⊆ Xamarin .NET Standard ⊆ .NET Framework
You're confusing intersection and union.
Earlier quoted context omitted.
Not quite. See this comment for the relationships of the specs: https://news.ycombinator.com/item?id=14971769 .NET Framework, .NET Core, Mono, Xamarin, and Unity are all implementing all the .NET specs. They are share many aspects, but each also bring specific capabilities that the others don't have, so its not very useful to think of these having a superset/subset relationship.
Hence the intersection symbols.
Earlier quoted context omitted.
I can totally share the sentiment around complexity. We're working hard towards reducing it though and .NET Standard is one piece of the puzzle. Let me try to explain: If you're a typical .NET customer, then you're used to the .NET Framework, which also means you're probably only used to doing development on Windows. That was no longer a viable strategy for .NET, so we're now pursing a cross-platform strategy. A good…
If you are at it maybe you can also rename it so that its name doesn't start with a point and you don't need to put points in the middle of the sentences.
Earlier quoted context omitted.
I can totally share the sentiment around complexity. We're working hard towards reducing it though and .NET Standard is one piece of the puzzle. Let me try to explain: If you're a typical .NET customer, then you're used to the .NET Framework, which also means you're probably only used to doing development on Windows. That was no longer a viable strategy for .NET, so we're now pursing a cross-platform strategy. A good…
I am not sure if you are going about this the right way. Instead of doing .NET standard, .NET Core and .NET full framework with overlapping functionality, I think it would better to have .NET Core as the underlining cross-platform standard. Then add WPF, WCF and whatever as separate packages that may be cross-platform or not. The whole thing reminds me a little of the UI situation. Start with Winforms, don't improve…
For newer .NET implementations we push folks to start with .NET Core and adding their specific technologies on top. That is, for instance, what Samsung has been doing with Tizen. So if the open source community innovates in .NET Core, Samsung can just move to a later build of .NET Core in order to benefit from it. They are a pure superset of .NET Core, by construction. However, for all other cases someone needs to port the changes from .NET Core to Mono which makes it consumable by Xamarin and Unity. .NET Framework is in a similar boat, although porting is somewhat easier as the .NET Core code base originated from .NET Framework.
Since we can't (easily) move Mono/Xamarin/Unity/.NET Framework on top of .NET Core, we need a way to standardize the API set so that it's not all chaos. And that's where .NET Standard comes in.
Earlier quoted context omitted.
Will the new XAML version (the first one in 10+ years!) finally solve the problems of excessively verbose syntax, excessive XML namespace imports, excessive binding syntax options, and excessive-needing-to-search-stackoverflow-to-do-the-simple-things? :) Any news on allowing JSON or another syntax as an alternative to XML-based XAML?
JSON is no where near expressive enough to replace XAML, it would look a lot worse than what we have right now. The XML-like syntax of XAML isn't the problem, it separates object properties from child content well due to it's nature - the bigger issue is how difficult binding syntax is to grok by anyone who hasn't been working with it for quite some time.
This is only the case for trivial properties - there is also the expanded form of properties and that's where it muddies XAML very quickly.
For example, in a WPF project of mine I have a DataGrid with a Templated column parenting an ItemsControl with HyperLink children (it displays a list of Phone numbers for each Customer row).
This is my current XAML - I understand this is the minimum I need to achieve that effect: https://pastebin.com/cRjT2PG5
It could be simplified drastically in two ways, for example:
* Eliminate `` and `` elements, they're implicit in 90% of cases and yet add another element and indent level without conveying significant information. They could be expressed as attributes of the `` and `` property elements.
* Allow C# expressions and the composition of child-binding to be used in property bindings, not just `String.Format` strings. In my example I have to populate `` with a full `` and `` element - why can't I just do ``? That alone would 10 lines of my 42 line example.
Another issue with XAML is that the creators of XAML failed to learn from HTML+CSS: while it succeeds at separating programming code from view-level concerns, it fails at separating presentation from content - it's like we're back in HTML3/4 days when and were all around and it was nearly impossible to tweak and standardise a UI. XAML does have and elements but they're more used for setting Template properties - the end result is a horrid mess.
Earlier quoted context omitted.
Wait... first I've heard of this. Not that I'm reading every single post letter for letter but have been following the .NET Standard move quite a bit. Is there a list somewhere that specifies what is not implemented per target, though it's in the standard?
There's multiple releases of .Net Standard, different releases of .Net Core target different releases of Standard. .Net Core 1.2 will be the first version to support the full .Net Standard 2.0 API surface.
Compatibility mode sounds like a godsend for those of us who have had to hold back due to compatibility issues with third party code/libraries. It's a risk, to be sure, but awesome that it's an option now. Side note: very much looking forward to UWP targeting .NET standard. Not long now before you'll be able to develop UWP apps for Ubuntu and Mac OS :)
Microsoft's Xamarin Forms 3.0 (stable release later this year) allows you to target Linux and Mac[1] and is very similar to UWP conceptually - UI written once, run anywhere. It's just that Xamarin's "anywhere" is much larger :) Disclosure: I work on Xamarin team at Microsoft [1] https://forums.xamarin.com/discussion/85747/xamarin-forms-fe...
I have looked for xamarin.forms to be ready for years now, but still is very limited/inmutare. I'm building the most simplistic crud app with zero-care for good looks and good UI, yet every step requiere a workaround (for example, you can't have a Password EntryCell, you need to create it from code using a ViewCell).
Exist a lot of functionality available in the base controls not exposed in forms.
Now, with regret I'm thinking in use react native (that destroy the ability to use F#) or use HTML.
How much better will 3 be? Some place where I can talk about this?
Earlier quoted context omitted.
Will the new XAML version (the first one in 10+ years!) finally solve the problems of excessively verbose syntax, excessive XML namespace imports, excessive binding syntax options, and excessive-needing-to-search-stackoverflow-to-do-the-simple-things? :) Any news on allowing JSON or another syntax as an alternative to XML-based XAML?
I fail to see anything good about JSON. Many of us do enjoy XML based tooling.
Could be represented in strict JSON as:
{ "Type": "Foo", "Trivial": "trivial", "Complex": { "Type": "Bar", "Bound": { "Type": "Binding", "Path": "qux" } } }
A more succint JSON-derivative would allow for the "Type" property to be specified anonymously, object keys as identifiers, not strings, allow comments, and use object constructors directly instead of object literals:
{ Foo, Trivial: "trivial", Complex: { Bar, Bound: new Binding( "qux" ) }
}
Earlier quoted context omitted.
Microsoft's Xamarin Forms 3.0 (stable release later this year) allows you to target Linux and Mac[1] and is very similar to UWP conceptually - UI written once, run anywhere. It's just that Xamarin's "anywhere" is much larger :) Disclosure: I work on Xamarin team at Microsoft [1] https://forums.xamarin.com/discussion/85747/xamarin-forms-fe...
Question for you - I have created a few (okay, two) UWP apps, but the limited success of the store has made me look to using Xamarin. Only thing is, Xamarin's XAML is sufficiently different from UWP's XAML that I got disoriented and gave up. If I want to target cross platform apps (including Linux and Mac), should I wait for Xamarin Forms 3 or will UWP eventually expand to cover Mac & Linux? I'm only a hobby programm…
It even does iOS and Android without any recajiggering. You can just compile your desktop app straight to your cell phone if you want.
It's amazing.
Does anybody have any idea what is the total number of APIs available in .NET Framework? I am interested how big of a subset .NET Standard is.
The .NET Framework has approximately 250k APIs. The majority are from the application models stacks (WinForms, WPF, and ASP.NET). .NET Standard has about 32k APIs that set is pretty close to all the APIs that are part of .NET Framework that aren't specific to any application models. However, we still have a few things we need to bring to .NET Standard.