Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET Standard 2.0 is final

github.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: .NET Standard 2.0 is final

#61

Post by snuxoll »

maxxxxx wrote: post #45
snuxoll wrote: post #40

Earlier quoted context omitted.

.Net Standard isn't an implementation, it's a specification. Code that targets .Net Standard is guaranteed to run on any compatible runtime that supports it. .Net Core has API's that aren't applicable to the Windows full-fat Framework, Mono or Xamarin - you don't need or want them there.

This sounds all good but now we are in the typical Microsoft dilemma when you start something. Core or full? Winforms, UWP or WPF? All very similar but different enough to make a move between them difficult.

You're never going to remove this choice entirely, the goal is to allow you to keep your libraries when moving between target frameworks.

Re: .NET Standard 2.0 is final

#62

Post by snuxoll »

Rusky wrote: post #42
snuxoll wrote: post #40

Earlier quoted context omitted.

.Net Standard isn't an implementation, it's a specification. Code that targets .Net Standard is guaranteed to run on any compatible runtime that supports it. .Net Core has API's that aren't applicable to the Windows full-fat Framework, Mono or Xamarin - you don't need or want them there.

All of these API surfaces are pretty large- what is a good way to get a feel for what they do/don't offer? In particular, what are you referring to in .NET Core that you wouldn't want in Framework?

.Net Core supports P/Invoke on Linux and macOS, you aren't going to be using a library that provides bindings for libsystemd.so or whatever on Windows - this is probably one of the most prominent examples. I know there's a handful of others, but I'm having a hard time finding a good article or any relevant documentation on it.

Re: .NET Standard 2.0 is final

#63

Post by snuxoll »

DaiPlusPlus wrote: post #55
snuxoll wrote: post #39

Earlier quoted context omitted.

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.

> it separates object properties from child content well due to it's nature 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 cu…

> * 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.

XAML ultimately compiles to an object tree, if you're putting more than a reference, string, int, etc. into a property you need to construct it as a child element - if you want you are free to define the DataTemplate elsewhere in your XAML or in a resource dictionary and use the binding syntax.

> * 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.

Use a converter? I know they're cumbersome to write, but that's what they exist for.

> 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.

Again, resource dictionaries, bind reusable styles to your elements. Syntax again sucks, ``, and there IS the nagging issue that the styles are decided by the UI - but it's not too much worse than CSS classes.

Don't take any of this to mean your concerns aren't valid, but it's really not AS bad as you make it out to be. There's always room for improvement though!

Re: .NET Standard 2.0 is final

#64

Post by terrajobst »

flukus wrote: post #60
terrajobst wrote: post #31

Earlier quoted context omitted.

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.

Are we calling public classes API's now?

APIs are a long standing name for the set of all .NET constructs (classes, structs, delegates, interfaces, methods, properties, events, fields).

In total, the .NET Framework has about 15k types.

Re: .NET Standard 2.0 is final

#65

Post by pjmlp »

DaiPlusPlus wrote: post #58
pjmlp wrote: post #46

Earlier quoted context omitted.

I fail to see anything good about JSON. Many of us do enjoy XML based tooling.

I don't mean the current verbose JSON standard (e.g. string keys, no comments) but something derived from it - because XML's capabilities are a subset of what JS/JSON is capable of, and because the same syntax for complex properties can be used for trivial properties it simplifies the syntax, for example: Could be represented in strict JSON as: { "Type": "Foo", "Trivial": "trivial", "Complex": { "Type": "Bar", "Bound…

> because XML's capabilities are a subset of what JS/JSON is capable of,

It is the other way around, JSON is a subset of XML features.

XML is a very expressive language/file format.

Re: .NET Standard 2.0 is final

#66

Post by pjmlp »

porkbelly wrote: post #59
randomf1fan wrote: post #19

Earlier quoted context omitted.

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…

Oh heck, don't waste your time waiting for MS. Qt works cross platform Windows, OSX and Linux right now. 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.

> It even does iOS and Android without any recajiggering

Not really, it is a pain to use versus Xamarin.

All you get is QML and the freedom to implement all your bindings to Android and iOS APIs.

Re: .NET Standard 2.0 is final

#67

Post by pjmlp »

flukus wrote: post #60
terrajobst wrote: post #31

Earlier quoted context omitted.

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.

Are we calling public classes API's now?

They always were, somehow the hipster web crowd decided network interfaces should be named API as well.

Re: .NET Standard 2.0 is final

#68

Post by jasallen »

mamcx wrote: post #57
jasallen wrote: post #16

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...

Also, another question. 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 fo…

I find it weird that you consider it a workaround to put a Password Entry field inside a cell rather than using a "PasswordEntryCell", that's just simply nesting a control, in what platform don't we have have to do that? Might this platform or that one _have_ "passwordEntryCell" sure, but I fail to understand why such would be a first class citizen in your mind.

I also can't imagine jumping ship to React Native. If you're going to jump off Xamarin Forms and already like f# / .net then native Xamarin.IOS and Xamarin.Android are more easy, powerful and expressive than React Native.

Re: .NET Standard 2.0 is final

#69

Post by DaiPlusPlus »

pjmlp wrote: post #65
DaiPlusPlus wrote: post #58

Earlier quoted context omitted.

I don't mean the current verbose JSON standard (e.g. string keys, no comments) but something derived from it - because XML's capabilities are a subset of what JS/JSON is capable of, and because the same syntax for complex properties can be used for trivial properties it simplifies the syntax, for example: Could be represented in strict JSON as: { "Type": "Foo", "Trivial": "trivial", "Complex": { "Type": "Bar", "Bound…

> because XML's capabilities are a subset of what JS/JSON is capable of, It is the other way around, JSON is a subset of XML features. XML is a very expressive language/file format.

If you widen JSON to be strictly pure JavaScript object and value literals (e.g. allow comments, non-string keys, use of constructor calls, etc) then JSON is more expressive because each child of a JSON object itself is a JSON object - whereas an XML element has two distinct types of children: child-elements and child-attributes, and the expressiveness of attributes is considerably limited compared to child-elements. Granted, JSON provides no inherent way to denote an attribute compared to a child element, but remember that XML restricts you to a single complex child element collection, whereas with JSON you can have multiple properties containing children (unless you want to argue that named element children could correspond with named complex properties in JSON - then it's just a matter of syntax).
Post reply on HN