philm

I just calculated exact subpixel accuracy, for me it’s exactly 20.5̅9̅5̅5̅3̅3̅4̅9̅8̅7̅5̅9̅3̅0̅5̅2̅1̅0̅9̅1̅8̅1̅1̅4̅1̅4̅3̅9̅2̅0̅ % that is still missing to fill the whole comment body with rainbows, way to go!

Let’s start the sixth rainbow!

Plenty of space for me still (browser version on desktop)

yeah as nice as it is what you can achieve with trait-bounds there are definitely trade-offs, being compile time and error messages, and sometimes mental complexity, understanding what the trait-bounds exactly mean… I really hope, that this area gets improvement on at least the error-messages and compile time (incremental cached type-checking via something like salsa)

And we’re about to enter the fourth rainbow dimension in the next comment…

We’re in the third rainbow, keep building more stripes lol

I’m totally aware of the benefits of encapsulation, but the way java does it seems so unnecessarily boilerplatey (C# is better, functional programming makes encapsulation even simpler, but that’s a different paradigm…)

I like how Rust approaches this via the module system and crates (you have pub for the public interface, pub(crate) for crate/lib wide access and no modifier for being only allowed to access in the current module and submodules of that module)

The curse of OOP (java style…).

I mean why do you need to write getter and setter methods. I have wondered at the beginning of university 10 years ago, and am still wondering why you would need something like that…

misunderstanding was

I think here’s a misunderstanding too :). With quickly I mean closing without getting feedback, or without providing a good reason why the issue is closed (without being obviously resolved), not the dates (which I think are only relevant, when actually awaiting a response). I have seen this over the repo a few times, good writeups often explaining some behavior etc. and then bam closed, either as duplicate (although it’s not (example)), or “not as planned” etc. I think this is not good behavior for an open source project (I’m around the block for a few years contributing and maintaining OSS, for reference…). Especially as this is a real community project and not some random opinionated application (well depending on how you define it, could be true to lemmy, but I don’t think it is…)

I rather let an issue open than close it, “just to have fewer open issues”. I can close it anytime, and if someone searches for that issue sees it closed while it isn’t resolved, it just creates confusion…

Yeah, but unironic…

If your code needs comments, it’s either because it’s unnecessarily complex/convoluted, or because there’s more thought in it (e.g. complex mathematic operations, or edge-cases etc.). Comments just often don’t age well IME, and when people are “forced” to read the (hopefully readable) code, they will more likely understand what is really happening, and the relevant design decisions.

Good video I really recommend: https://www.youtube.com/watch?v=Bf7vDBBOBUA