4

1) IList doesn't have an AddRange.
2) WPF bindings must be ObservableCollections
3) Comboxes using Event Notification on PropertyChange are originally developed by some dope at Microsoft who still doesn't comprehend Big-O
4) LINQ can only do so much...

It's Christmas. My gift from Santa is trying to get through an end of year crunch on a project that is made entirely out of hot sweaty year old garbage, and the garbage collector is a halfwit who comes seemingly only when they want to, regardless of when I call Dispose().

It's 12:26pm here. That means it's time for bourbon and a good bit of "F*** this, I'm done for the day."

Comments
  • 1
    WPF is honestly a pretty good trash fire. Don't envy you.

    Ignore two-way data binding and replace the sequences with a combination of RX and custom Markup extensions. Even intercepting INotifyPropertyChanged event and propagating them through subjects make a world of difference. Immutable data and reactive programming will solve most of the memory issues.
  • 0
    Extra points for not giving up on wpf though 👍

    It is workable, but you gotto know when to use what patterns or components. I think wpf front end designers, good ones, are severely underrated

    Given that after opensourcing it, nobody from Microsoft has dared to touch it does not tell us great fortune for it.

    I kinda love it though.
  • 0
    The only thing I liked about wpf was data binding and easy customization, though that was my first entry to that world haven't used wpf for few years 🤔
  • 1
    @jkommeren One of the worst things I've come to notice with WPF is just it's extreme learning curve. It's a completely different beast compared to winforms (which probably a lot of developers come from).

    And writing XAML makes me want to shoot my brains out, god that's a chore.
  • 1
    One reason AddRange is not included in the IList interface is because since IList can be implemented by a readonly class or fixed size with IList, every time you want to add tomit you need to check if its readonly or full and AddRange can take an IEnumeral which can be unbounded.

    Allowing addrange would open up for cases when the code cannot complete.

    In many cases, especially when your only reading from it, IList makes the rest of the code more flexible since you could switch implementation freely.

    But being able to switch also have its own costs so its all about learning which costs you want to take snd which to avoid.
  • 2
    @SortOfTested I slept on it. It's time to implement Strangler Pattern. I'm going to give this thing an API (because nothing exists today) and start migrating this entire dumpster fire to a web application. Since it is MVVM, the customer facing frontend can still be WPF while I migrate. Otherwise, the technical debt [rent] is [too damn high] not worth kicking this can down the road. It's time to make future developers a priority here. A year from now, I'll be gone and this will be someone else's problem. Hopefully they won't hate me as much as I hate the last guy.
  • 0
    @bulletsponge
    Good call. Single OS applications' days are numbered.
Add Comment