philm
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)
Well yeah the second comment didn’t really had to be, but hey it’s certainly not really reason enough to ban someone from the repo. The first comment I think is totally ok (as well as marking it off-topic, but optimally with an answer, probably marked as off-topic as well). Just keep an issue (it’s not a PR) open, until the issue is resolved in one way or the other i.e. either solved reasonably via a third-party client (with links to it) or directly in the repo, asking the community (when it’s not obvious that the issue is resolved), whether this is resolved, wait for reactions, and close it after some time based on that. Banning someone, or quickly closing or not reopening after a carefully written argument, that the issue is not solved etc. is just childish behaviour, especially for a community focused project (I’m watching a few lemmy issues on GH).
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 why do I have to use an IDE to generate getters and setters in the first place? It just adds up to more mental overhead, because my brain has to process this boilerplate somehow, even if my IDE can generate it (I know it’s simple code, but it’s even simpler to not have that boilerplate code at all).
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)