NetBeans vs UTF-8
-
@Gąska said in NetBeans vs UTF-8:
@dkf said in NetBeans vs UTF-8:
@Gąska said in NetBeans vs UTF-8:
The important part is that this event->state change->redraw pipeline is the only way the UI can ever ever ever change in any way.
How is this different from MVC and MVVM?
ViewModel has no persistent state of its own - all fields are derived straight from "business state" and nothing else. Of course nothing stops you from doing your WPF ViewModels in such way (and I highly recommend so!)
Does that mean that you have to do stuff like reload data from the DB every round trip?
-
@boomzilla if your button fetches from database directly instead of your business logic, you're doing something very, very wrong.
-
@Gąska said in NetBeans vs UTF-8:
@boomzilla if your button fetches from database directly instead of your business logic, you're doing something very, very wrong.
Kind of like if your button is a field? I'm not sure what you're trying to tell me here.
-
@boomzilla I'm not sure what you're reading in my post. It's really not that hard. There is persistent state. And there is derived state that's entirely dependent on the persistent state you've saved and nothing else. UI elements are only allowed to have the latter. And yes, it includes ViewModels. Everything that needs to change things for real lives in business logic and not UI.
-
@Gąska said in NetBeans vs UTF-8:
@boomzilla I'm not sure what you're reading in my post.
Uh...first off:
all fields are derived straight from "business state" and nothing else
vs...
button
It's really not that hard. There is persistent state. And there is derived state that's entirely dependent on the persistent state you've saved and nothing else. UI elements are only allowed to have the latter. And yes, it includes ViewModels. Everything that needs to change things for real lives in business logic and not UI.
I guess I'm wondering about the meaning of "persistence" here. This is almost certainly in part due to my lack of formal CS education, so people tossing around words like "model" and "view" always make my eyes want to gloss over.
In particular, the way you initially said it, it sounded like you weren't keeping any local state between views.
-
@boomzilla said in NetBeans vs UTF-8:
It's really not that hard. There is persistent state. And there is derived state that's entirely dependent on the persistent state you've saved and nothing else. UI elements are only allowed to have the latter. And yes, it includes ViewModels. Everything that needs to change things for real lives in business logic and not UI.
I guess I'm wondering about the meaning of "persistence" here.
Something that must be saved (temporarily in RAM for the duration of application session) because there's no way to restore it from other data. As opposed to derived data, which can always be restored from persistent data and therefore, to avoid weird bugs that take man-weeks to debug, should always be calculated in the same way - the way they were first initialized when the view was created.
Let's say you have a text field with line numbers. Adding new line in text should cause a new line number to appear. But you don't just add the new number in reaction to key press event - rather, you create an action object that describes the new user input, have it passed via events to the business logic part of your code which checks the action and decides how to update the persistent state (in this case, extend the text with newline), and the changes in persistent state trigger the updaters of the derived state, which replace the old values with new ones using a pure calculation (ie. the result depends only on the persistent state at this very moment, and nothing else) - this is where you recount the lines, and the refreshed line count is then used to draw all the line numbers from scratch.
As far as your application is concerned, the data from DB is part of persistent state, since refetching it would be expensive, so it's better to pretend it cannot be done unless absolutely necessary.
-
@ixvedeusi said in NetBeans vs UTF-8:
There's no way to return from the middle of a function and then continue execution at that point some time later, which is coroutines. Or have I missed some recent addition to the standard?
-
@levicki somehow, I totally expected that. It wasn't invented 20 years ago therefore it's bad by definition.
-
@levicki said in NetBeans vs UTF-8:
It's just that to me it seems quite easy to get
async/awaitcode wrongWelcome to asynchronous programming! No matter what your approach is and what tools you use (threads, coroutines, signals, whatever) - the basic problem is always the same: it's not synchronous. And it will cause A LOT of problems. Always. No matter what.
-
-
@levicki said in NetBeans vs UTF-8:
@Gąska I agree, though I still feel like if classic threading is an equivalent of this:
Then async/await must be something like this:
The other way around. And frankly, async/await isn't overkill at all - it's perfect for what it was designed for (and what it's most widely used for): replacing callback chains.
-
@Gąska said in NetBeans vs UTF-8:
@levicki said in NetBeans vs UTF-8:
@Gąska I agree, though I still feel like if classic threading is an equivalent of this:
Then async/await must be something like this:
The other way around. And frankly, async/await isn't overkill at all - it's perfect for what it was designed for (and what it's most widely used for): replacing callback chains.
Toby Fair some people see it in new .NET projects and think "I should use this everywhere" and do so... badly.
-
@powerlord The thing with async/await is that you can better use it "all the way down". It's when you start mixing calls of async methods in synchronous methods that the trouble starts. The most fool-proof way to support both is to duplicate all async methods you might need in synchronous methods, then make sure those duplicates do not call any async stuff.
Really, the only truly annoying gotcha is that `async void is easy to type and yet it won't work as intended...
-
Classic threading:
await/async
-
@JBert said in NetBeans vs UTF-8:
The thing with async/await is that you can better use it "all the way down". It's when you start mixing calls of async methods in synchronous methods that the trouble starts. The most fool-proof way to support both is to duplicate all async methods you might need in synchronous methods, then make sure those duplicates do not call any async stuff.
Really, the only truly annoying gotcha is that
async voidis easy to type and yet it won't work as intended...Sounds like two annoying gotchas to me...
-
@Vixen said in NetBeans vs UTF-8:
@levicki said in NetBeans vs UTF-8:
(403 response when I try to upload the image...
)https://pics.me.me/al-more-dakka-its-a-start-32523700.png
Sorry for the typo
-
@JBert said in NetBeans vs UTF-8:
@powerlord The thing with async/await is that you can better use it "all the way down". It's when you start mixing calls of async methods in synchronous methods that the trouble starts. The most fool-proof way to support both is to duplicate all async methods you might need in synchronous methods, then make sure those duplicates do not call any async stuff.
Hmm... I wonder if you could use some template magic in C++20 to avoid code duplication...
Well, certainly you could. The question is, how painful it would be to write.
-
@Gąska said in NetBeans vs UTF-8:
The question is, how painful it would be to write.
And would the resulting templated code be longer or shorter than just duplicating the code?
Filed under: just because you can doesn't mean you should
-
@dkf There would be fixed cost for each function, and the gain is equal to regular function's length. I'm pretty optimistic about it.
-
@Gąska said in NetBeans vs UTF-8:
@JBert said in NetBeans vs UTF-8:
@powerlord The thing with async/await is that you can better use it "all the way down". It's when you start mixing calls of async methods in synchronous methods that the trouble starts. The most fool-proof way to support both is to duplicate all async methods you might need in synchronous methods, then make sure those duplicates do not call any async stuff.
Hmm... I wonder if you could use some template magic in C++20 to avoid code duplication...
Well, certainly you could. The question is, how painful it would be to write.
You mean template code that does either
returnorco_return? Don't think that's possible. A template wrapper that takes an async function and makes it synchronous, yeah probably.
-
@topspin if only C++ had Rust's macros...
-
@Gąska said in NetBeans vs UTF-8:
@topspin if only C++ had Rust's macros...
Well, you could always solve it with macros, but I feel dirty just thinking about that.
