4 ms·
>Python is extremely dynamic and while I can't remember how offhand, I would be surprised if you couldn't simply override variable access the way you can with J
by sandGorgon 4y ago
>Python is extremely dynamic and while I can't remember how offhand, I would be surprised if you couldn't simply override variable access the way you can with Javascript (eg, add a `get fieldname()` method). So you don't need "getters" the way you do in Java, which makes a distinction between field access and dynamically dispatched functions (and has performance benefits).
So this is the thing - that there is nothing in python at a language level that enables/disables this. it just doesnt give a private construct. same as in javascript. you can add getters/setters if u want. in fact ECMAScript introduced getters/setters - https://www.w3schools.com/Js/js_object_accessors.asp https://www.w3schools.com/Js/js_object_accessors.asp
But the thing is, huge huge codebases exist without private.
There's nothing that i can see in java that requires private. not to say, ur not wrong...but so it is with almost all patterns. even CQRS. There is a certain level of complexity when it makes sense. The question is - how early do u enforce this ?
- stickfigure 4y ago> that there is nothing in python at a language level that enables/disables this Yes, there is. `@property` allows you to change a vanilla field to a getter/setter without modifying client code. >> override variable access the way you can with Javascript (eg, add a `get fieldname()` method) > in fact ECMAScript introduced getters/setters That exchange was weird. > huge huge codebases exist without private I'm honestly not quite sure where you're going with that. Huge codebases exist in COBOL too. It sounds like you're trying to argue that the software world doesn't need encapsulation. I disagree. Maybe you took my comment "99% of the time it's fine" the wrong way - 99% isn't good enough. The 1% wastes a lot of time and energy, it's better to have language support for encapuslation. Java's support for encapsulation (getters) is pretty tedious. Lombok and records (too modern for this codebase, unfortunately) fix that. Thus "getters/setters are a nonissue".
- sandGorgon 4y agoi hear you - then let me ask you: what would make Java frameworks better (not the language) ? Not just for existing developers, but also people who are new to the language and are doing the old golang vs java eval.
- stickfigure 4y agoHere's what I generally use when doing greenfield development in Java: https://github.com/gwizard/gwizard https://github.com/gwizard/gwizard I wrote it, so feel free to consider me biased. That said, "wrote" is a strong word, it just glues some other projects together with Guice. Not much actual code there. Which may be the answer to your question - if you asked me what's wrong with other frameworks, "too much code" is a decent answer.
- sandGorgon 4y agothis is so so cool! thank you for sharing this. I have been wondering something - wiring different components together and building "up" something. versus take Spring Boot and create a DSL/Lombok-like layer on top which abstracts out the "too much code" and unpleasantness. Like a Nextjs that builds on top of Reactjs. Why the first and not the second ?
- stickfigure 4y agoI'll give you my complaint with Spring: It tries to hide the libraries underneath and offer the "Spring way". But it's always a leaky abstraction, so you end up having to learn both (for example) Hibernate and how Spring interacts with Hibernate. Instead of avoiding a learning curve it just adds a second one. I greet your suggestion to add another layer of abstraction on top with great skepticism.
- sandGorgon 4y agofair point! let me give it a shot.