Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery
-
@boomzilla said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
As far as I'm concerned, it's a Xamarin issue if it fucks up when I'm trying to use the Xamarin framework.
Hi, Blakey!
y
-
@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
And when it is NOT visible, it can either retain control of the space [so layout does not change as visibility is toggled] or it can release the space [so that things can be repositioned to make use of the space....
So they looked at CSS's "display:block / display:none" and "visibility:visible / visibility: hidden", and said "Let's make that more confusing!"
?!?
-
@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
NotifyPropertyChanged... what a terrible idea. Simplest view models become a mile long planes of reapeated get, set, notify.
a) Use Dependency Properties [enables lots of power]
Which is even more repeated useless boilerplate.
b) Use a common base class and encapsulate
Which changes exactly nothing.
If you think Dependency Properties are "useless"
Wow, that's some serious reading comprehension fail.
Where?
If one accepts "[Dependency Properties] is even more repeated useless boilerplate.", then there are two possible conclusions I can see...
a) That simple boilerplate is a "useless" way to achieve useful functionality...
b) That DependencyProperties are themselves useless, therefore the boilerplate is useless.So lets look at "a".... For this to be true, there needs to be some better way of creating (useful) DependencyProperties other than simple boilerplate code, which has significant enough benefit to render the boilerplate useless across the board.
Other than hypothetical magic..... I am curious as to what you see that would meet this criteria...
-
@thecpuwizard said in [Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery]
So lets look at "a".... For this to be true, there needs to be some better way of creating (useful) DependencyProperties other than simple boilerplate code
That's the whole point, there is no better way of creating dependencies in XAML than endless boilerplate, repeating the same stuff countless times, only with property name changing.
I'm not saying 'Gee, Dependency Properties is so inefficient way of doing things, when so much better alternatives exist'. And I'm not saying 'Those silly Dependency Properties do nothing useful'. I'm saying XAML is shit.
-
@anonymous234 said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
It can't help Windows Phone anymore
There is only one thing that can help Windows Phone
-
@carnage said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
"Lets take all the best parts of every other language…"
There were probably important bits that they missed. There's a tremendous amount of subtlety to language design, and many bits that look like they're totally ignorable to start with turn out to be actually critical. (I've no specific knowledge of anything missing, of course — I've not studied Kotlin in any depth — but I really doubt that the best bits can all work together because I understand the deeper end of some of the tradeoffs…)
-
@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@thecpuwizard said in [Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery]
So lets look at "a".... For this to be true, there needs to be some better way of creating (useful) DependencyProperties other than simple boilerplate code
That's the whole point, there is no better way of creating dependencies in XAML than endless boilerplate, repeating the same stuff countless times, only with property name changing.
I'm not saying 'Gee, Dependency Properties is so inefficient way of doing things, when so much better alternatives exist'. And I'm not saying 'Those silly Dependency Properties do nothing useful'. I'm saying XAML is shit.
DependencyProperty is quite independent of XAML (even independent of having a "human UI" at all). So I don't see any value in conflating the two in terms of discussions.
-
@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
I tend to use lots of "generated code" so that the human developer expresses one "source of truth" about something, and all of the necessary semantic elements are consistently implemented by the machine.
Developers keep doing this (I've done it in the past a few times), and it never seems to totally stick; odd bits of hair seem to sprout in the system as it approaches production. There's just to much odd fuckery in interfaces to make the pure declarative approach widely applicable enough. :( It's a bit easier with backend systems, but UIs are awful for this stuff and it's fundamentally because they're interfacing with people whose expectations frequently don't match standard templates well…
-
@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
So I don't see any value in conflating the two in terms of discussions.
Yeah, it's a shame someone did that.
-
@dkf said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
I tend to use lots of "generated code" so that the human developer expresses one "source of truth" about something, and all of the necessary semantic elements are consistently implemented by the machine.
Developers keep doing this (I've done it in the past a few times), and it never seems to totally stick; odd bits of hair seem to sprout in the system as it approaches production. There's just to much odd fuckery in interfaces to make the pure declarative approach widely applicable enough. :( It's a bit easier with backend systems, but UIs are awful for this stuff and it's fundamentally because they're interfacing with people whose expectations frequently don't match standard templates well…
I agree with much of your post [limits of pure declarative, "odd bits of hair"], but have also found that with diligence (including automatic enforcement by check-in policies, builds, DRC automated tests, more) much can be achieved.
-
@bulb said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
Basically what I understand is that it brings all the good from Java 8 and some more
And add some
-
@timebandit Depends on the insertion rule. If it is “put in a semicolon at a newline unless explicitly escaped to prevent it” then that works as it is very predictable. Putting one in based on a guess the way Javascript does it? Please, no…
-
@dkf I prefer "Insert a semicolon at the place the programmer did". No confusion possible
-
@timebandit said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@dkf I prefer "Insert a semicolon at the place the programmer did". No confusion possible
That's just shifting responsibility for inserting semicolons to the least reliable element of the process.
-
@timebandit I prefer "semicolons are optional." Which does not mean "semicolons are required but they get inserted if you leave them out;" it means "we actually don't need them but if you put one in we won't complain."
-
@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
That's just shifting responsibility for inserting semicolons to the least reliable element of the process.
I type the whole line of code, so when I get to the end I don't just
-
@timebandit said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@anonymous234 said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
It can't help Windows Phone anymore
There is only one thing that can help Windows Phone
Actually, I have found that the following works quite well....
-
@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
It isn't so much confusion between the two, but more of a "huh, given how close the syntaxes are, and given how much Microsoft has put into obtaining this platform, and given how much Microsoft loves changing shit, and given how ABSOLUTELY FUCKING USEFUL RAZOR IS, I would have thought they'd have merged them together somehow".
I'm pretty sure XAML's older than Razor. Yeah, quick Googling shows Razor's from 2010 and XAML's from either 2007 or 2008.
Also Microsoft created XAML, not Xamarin. They just borrowed it.
I have no idea why you think the two templating languages should have been "merged together somehow".
-
@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
Actually, I have found that the following works quite well....
It seems like the wheelbase would be too short and it would tip over a lot.
-
@blakeyrat said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
I have no idea why you think the two templating languages should have been "merged together somehow".
Because XAML sucks fuck and .Net's templating language doesn't?
-
@timebandit said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
There is only one thing that can help Windows Phone
https://www.youtube.com/watch?v=MakV9CKx0U4
Not mentioned in the video title: Shooting a Windows Phone with a PROPANE POWERED POTATO CANNON!
-
@blakeyrat said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
XAML's from either 2007 or 2008.
Close November 2006 for the RELEASE of XAML.... Pre-release goes back to late 2004.
-
@lorne-kates Ignore things that say template unless you want to completely redesign the entire area and replace it with something else. It's one of the nicer things about XAML - assuming they kept it consistent - but maybe not obvious?
Overall, from reading this thread, I can tell you are very annoyed by this whole thing. It requires a very different way of looking at things than web stuff, and some of it probably seems really weird. Not to mention the likelihood that things are randomly different for Xamarin's XAML than the other platforms'.
I personally really like working with XAML, and can get a lot done with it quickly, and enjoy the fact that things are really easy to position and get bound up and working in no time. Every time I work with web stuff, I have to deal with the fact that nothing will ever be where I want it, and everything will always mess up everything else.
All this is to say, these two ways of working are probably very much equivalent. I just prefer XAML's idiosyncrasies, whereas you seem to prefer web things. Which is fair. I'd just give it some more time, honestly. WPF is so far the best implementation, followed by UWP, and I highly doubt Xamarin comes close - still, working in a UI system where everything is essentially vector based has its advantages.
-
@thecpuwizard said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
Close November 2006 for the RELEASE of XAML.... Pre-release goes back to late 2004.
Thank you for pedantry.
Point is, that's plenty time for Razor to have learned from XAML's mistakes and be better than XAML, so it's not surprising that Razor is better than XAML.
-
@magus said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
some of it probably seems really weird
Because it is! XAML is awful.
-
@masonwheeler Yeah, no. You're wrong, as usual.
-
@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
Only backdoor stuff you, huh?
The men don't know
But the little girls understand
-
@magus I think XAML's pretty awful myself. I solve this problem by not using it.
-
Compared to the other UI-building technologies I've used (especially Swift-based Storyboards in XCode ( )), XAML is heavier but much more sane and powerful. Takes more writing, but actually does what you want, not what Apple decided to allow in its great and wonderful mercy toward lesser mortals.
-
@blakeyrat There are some downsides for sure, but I'd say the upsides beat them out:
- It's all vector
- It works just as well for desktop, mobile, and VR
- You can change stuff
- You can center stuff
- You can bind stuff pretty easily (normally, though Xamarin seems weird)
Vs
- It's sometimes complex to look at
- Very verbose
- Some stuff takes some hefty boilerplate
- Stuff like converters can be annoying. It sometimes makes sense to just make a generic one you can bind static data to, or else use a trigger.
The thing is though, you can get crazy amounts of reuse out of code once you've learned to deal with it a bit, which isn't something you normally get for a desktop UI system. It took me a long time to get it all figured out - I'll freely admit that. But it really is quite good.
-
@benjamin-hall I don't know what Apple uses, but my frame of reference is WinForms. WinForms may be ancient, but it was really, really well-designed, has a visual designer with WYSIWYG, doesn't require knowledge of XML (or anything except the C# code you're using literally everywhere else in the project), and the layout tools make a hell of a lot more rational sense to a mere mortal like me than all that CSS "reflow" layout shit (just "anchor" the elements to an edge! Simple!)
Anyway.
This goes, of course, with my common refrain that technology is getting more complicated, less usable, and more buggy over time. WinForms was great
-
@blakeyrat Unfortunately, it's strongly tied to the Windows API and can't be used cross-platform. :(
-
@masonwheeler said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@blakeyrat Unfortunately, it's strongly tied to the Windows API and can't be used cross-platform.
IIRC Mono had created a version of it that worked cross-platform, but I'm not sure how good it was or even if it still exists.
There's no inherent reason WinForms is tied to Windows. In fact, if anything, the fact that it's based on "forms" (which aren't necessarily windows at all) makes it flexible enough to work in a lot of environments it was never ported to. So it's not cross-platform due to laziness.
-
@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@boomzilla said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
As far as I'm concerned, it's a Xamarin issue if it fucks up when I'm trying to use the Xamarin framework.
Hi, Blakey!
y
Because @blakeyrat is known for not caring who's at fault for a particular problem and just blaming whatever layer he finds it in.
-
@dkf said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@carnage said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
"Lets take all the best parts of every other language…"
There were probably important bits that they missed. There's a tremendous amount of subtlety to language design, and many bits that look like they're totally ignorable to start with turn out to be actually critical. (I've no specific knowledge of anything missing, of course — I've not studied Kotlin in any depth — but I really doubt that the best bits can all work together because I understand the deeper end of some of the tradeoffs…)
Java getters and setters are accessed via properties, automatic type inference, nullability/non-nullability is compiler guaranteed and checked, the collections interfaces compile to the Java equivalents instead of actually being reimplemented, operator overloading is done via recognizable Java patterns like
compareTo
so regular Java libraries work with custom operators, POJOs can be made in one line withdata class
, you can use inline functions with reified generics or inline closures, etc etc.
Basically, there's almost no reason to be using Java instead of Kotlin.
-
@magus said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
It took me a long time to get it all figured out - I'll freely admit that.
That's the main thing. It takes ages to learn all of its weirdness and you really don't learn while working on something, as it is undiscoverable - you learn fighting with problems you never imagined exist and googling angrily for solutions.
I set out to learn XAML and UWP some time ago. I chose something very simple as first project, on purpose, to learn just the basics first. It was just simple CRUD, which saved data in json txt files (and sent them to OneDrive).
Those things happened repeatedly from the very start and continued to happen till the end:
- This basic thing I did 1000 times in other environments, how do this here? No idea. Google, try, fail, repeat.
- Why this control displays this way? Doesn't make sense. Google, google some more, oh I have to change 50% of the view, great.
- Compile, no error, run, no error, click, cryptic exception from deep bowels of the framework. Binding is wrong. Maybe.
- Run, everything displays correctly, except this thing. Binding is wrong. How to bind it correctly? No idea, google for half an hour.
- Run, 30 seconds of splash screen, silent crash. Nothing in logs. Huh. Let's change this. Nope. Let's move this code there. Nope. Let's add async somewhere, like... here? It works. No idea why.
- This part is almost finished, I just need to change this little thing on the view... [wall of xml]... where the fuck is that button?
- List of items displayed this way... seems straightforward - how to do this? Google... oh, it is as simple as I expected: item template with custom style and two converters, inside stack panel, inside grid, inside grid, inside grid, inside stack panel.
[edit]
Oh, I forgot one of my favorites.
- Change one small property in some view model. Intellisense stops working, 90% of views is colored red as errors, solutions stops compiling. Search for mistake, find nothing. Restart VS, everything is fine again.
-
@lorne-kates said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@blakeyrat said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
I have no idea why you think the two templating languages should have been "merged together somehow".
Because XAML sucks fuck and .Net's templating language doesn't?
But this isn't a templating engine. Writing an app UI is not the same as writing HTML - you're still building an object model, whether it's represented in XML or not. You're coming into this with the expectation that it'll be like the thing you used, and getting annoyed that it's a special snowflake, when actually it is ASP.NET which is the special one and everything else which uses XAML.
If you don't like it, write the app in HTML and JS.
-
@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
Change one small property in some view model. Intellisense stops working, 90% of views is colored red as errors, solutions stops compiling. Search for mistake, find nothing. Restart VS, everything is fine again.
I know this one at least has a chance of working better now, since they rewrote some of that stuff early on in vs2017's lifetime.
@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
This basic thing I did 1000 times in other environments, how do this here? No idea. Google, try, fail, repeat.
This, I can see being true, but it's still like the easiest thing ever. But probably the guides you got were dumb.
@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
Compile, no error, run, no error, click, cryptic exception from deep bowels of the framework. Binding is wrong. Maybe.
Run, everything displays correctly, except this thing. Binding is wrong. How to bind it correctly? No idea, google for half an hour.This stuff basically stops happening when you start doing MVVM the way that thing I posted here a while back does.
@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
Run, 30 seconds of splash screen, silent crash. Nothing in logs. Huh. Let's change this. Nope. Let's move this code there. Nope. Let's add async somewhere, like... here? It works. No idea why.
Ah, UWP.
@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
This part is almost finished, I just need to change this little thing on the view... [wall of xml]... where the fuck is that button?
Sounds like you aren't splitting things very well.
@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
List of items displayed this way... seems straightforward - how to do this? Google... oh, it is as simple as I expected: item template with custom style and two converters, inside stack panel, inside grid, inside grid, inside grid, inside stack panel.
This shouldn't be an average case. For WPF at least, you'd write two data templates and be good.It's probably harder in UWP. I don't think they ever got
DataTemplate
s.But yeah, I do feel your pain. It seems less than what I feel when I look at an Angular app.
-
@pie_flavor said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@dkf said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@carnage said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
"Lets take all the best parts of every other language…"
There were probably important bits that they missed. There's a tremendous amount of subtlety to language design, and many bits that look like they're totally ignorable to start with turn out to be actually critical. (I've no specific knowledge of anything missing, of course — I've not studied Kotlin in any depth — but I really doubt that the best bits can all work together because I understand the deeper end of some of the tradeoffs…)
Java getters and setters are accessed via properties, automatic type inference, nullability/non-nullability is compiler guaranteed and checked, the collections interfaces compile to the Java equivalents instead of actually being reimplemented, operator overloading is done via recognizable Java patterns like
compareTo
so regular Java libraries work with custom operators, POJOs can be made in one line withdata class
, you can use inline functions with reified generics or inline closures, etc etc.
Basically, there's almost no reason to be using Java instead of Kotlin.Of course, since the conversation here isn't about Java, you've now opened it up for comparison against other languages. For instance, C# (which Xamarin uses) does literally everything on this list save the nullability/non-nullability thing (at least on non-value types).
Also, generics are still type erased in Kotlin.
-
@powerlord said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@pie_flavor said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@dkf said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@carnage said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
"Lets take all the best parts of every other language…"
There were probably important bits that they missed. There's a tremendous amount of subtlety to language design, and many bits that look like they're totally ignorable to start with turn out to be actually critical. (I've no specific knowledge of anything missing, of course — I've not studied Kotlin in any depth — but I really doubt that the best bits can all work together because I understand the deeper end of some of the tradeoffs…)
Java getters and setters are accessed via properties, automatic type inference, nullability/non-nullability is compiler guaranteed and checked, the collections interfaces compile to the Java equivalents instead of actually being reimplemented, operator overloading is done via recognizable Java patterns like
compareTo
so regular Java libraries work with custom operators, POJOs can be made in one line withdata class
, you can use inline functions with reified generics or inline closures, etc etc.
Basically, there's almost no reason to be using Java instead of Kotlin.Of course, since the conversation here isn't about Java, you've now opened it up for comparison against other languages. For instance, C# (which Xamarin uses) does literally everything on this list save the nullability/non-nullability thing (at least on non-value types).
Really? C# doesn't have a data class equivalent, or compiler checked and guaranteed nullability, or inlined closures (I could be wrong on that last one). But the point of it is to have an extremely good language that integrates with Java APIs.
Also, generics are still type erased in Kotlin.
Comes with the platform. I don't know how Ceylon does it, but I'm pretty sure it's not performant.
-
@pie_flavor said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
inlined closures (I could be wrong on that last one)
What do you mean by "inlined closures"?
-
@masonwheeler said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
@pie_flavor said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
inlined closures (I could be wrong on that last one)
What do you mean by "inlined closures"?
I mean that they're not stored as an object. If an inline method takes a closure, then the closure is inlined to the method the same way the method is inlined to the caller. So you can be extremely expressive with zero run-time cost.
-
@pie_flavor said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
I mean that they're not stored as an object. If an inline method takes a closure, then the closure is inlined to the method the same way the method is inlined to the caller. So you can be extremely expressive with zero run-time cost.
Interesting.
I don't think C# actually has a concept of "inline methods;" it leaves that to the CLR JIT. Is method inlining explicit in Kotlin?
-
@masonwheeler The JVM JIT does inline methods where it can, but Kotlin also allows you to explicitly inline a method. This is good for the aforementioned free closures, but you can also use reified generic parameters in inline methods, which is really nice. Heck, you can even inline operator overloads.
-
@magus said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
I know this one at least has a chance of working better now, since they rewrote some of that stuff early on in vs2017's lifetime.
Nope, VS2017 Enterprise.
This, I can see being true, but it's still like the easiest thing ever. But probably the guides you got were dumb.
Maybe. Where can I find good ones?
This stuff basically stops happening when you start doing MVVM the way that thing I posted here a while back does.
Then I do MVVM wrong*. Where did you post it?
Ah, UWP.
Yep.
Sounds like you aren't splitting things very well.
4 buttons, list of scrollable items below. Items have 4 properties displayed (square of correct color (bool), name (string), category (enum), checkbox (bool)). Clicking on item shows 5th property. Right click opens edit view.
Seems pretty basic, but in XAML it's a wall of text. How to split this?
This shouldn't be an average case. For WPF at least, you'd write two data templates and be good.It's probably harder in UWP. I don't think they ever got
DataTemplate
s.It starts simple, list of items. Then I want something lined up to the right edge. Oh, I remember that attribute from hour ago, it's the obvious Container.TextDisplayAlignText=TextAlignessNotLeft. Oh, it doesn't work in this container. Google... must be in grid. Now that other thing is not stretched. No problem, just width=*. Oh, it's ignored, nothing stretches in this control. Google... must be in grid. Ok, now everything takes a lot of space... TextStretching=NotStretching? No. ShiftThingsToLeft=True. No. Google... only stack panel does that.
And so on**.But yeah, I do feel your pain. It seems less than what I feel when I look at an Angular app.
Funny (not) thing is, I still want to learn it. Got any pointers?
* I hate MVVM and still can't see it's merits. Probably my fault. Or not.
** Made that up, of course. Can't remember the details.
-
@masonwheeler said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
I don't think C# actually has a concept of "inline methods;" it leaves that to the CLR JIT.
You can say 'inline if you can' with MethodImplOptions.AggressiveInlining.
Yes, I googled it.
-
@mrl Yes, I'm aware of
MethodImplOptions
but I'm pretty sure that that's still done by the JIT and not by CSC. It just tells the JIT to pay extra attention to this one.
-
@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
Got any pointers?
null
-
@pie_flavor said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
I mean that they're not stored as an object. If an inline method takes a closure, then the closure is inlined to the method the same way the method is inlined to the caller. So you can be extremely expressive with zero run-time cost.
Inlining is the compiler's job. There's no manual control of it at all in C#, AFAIK.
-
@mrl said in Xamarin's contiuing barrel of cross-platform, XML-encoding fut the wuckery:
You can say 'inline if you can' with MethodImplOptions.AggressiveInlining.
Hm. Live and learn.
It's still just a suggestion though.