i have seen so much awful OOP code, studiously avoiding its strengths while diving headfirst into its weaknesses, that i understand why people believe this but i have seen good OOP code and it is very, very good indeed
-
-
I'm half-kidding. My experience has been similar. There are some problem domains that are neatly divided into object classes and the inheritance model is a massive efficiency gain. Functional Composition can accomplish the same thing but few languages have syntax sugar for it
2 replies 0 retweets 2 likes -
This Tweet is unavailable.
-
pattern matching is a really nice feature, as is destructuring, but they mostly just make code more concise. haven't really observed that they help avoid anti-patterns.
1 reply 0 retweets 1 like -
i admire the determination of people trying to discourage antipatterns with language design but holy shit how Sisyphean is that imo the only way to combat antipatterns is proliferating good, accessible examples shitty examples are the most destructive form of technical debt
1 reply 0 retweets 3 likes -
I don't think it's Sisyphean I think we're just, in general, bad at programming and past attempts to accomplish this have been bad because we are bad at programming. Example: public vs. private class members basically doesn't help at all but does add lots of boiler plate.
2 replies 0 retweets 2 likes -
i think visibility is good but the collision between visibility culture and testing culture generated by zero modern languages adopting friend classes, and its resolution by means of horrible fucking reflection boilerplate as you describe, is the dumbest fucking foot marksmanship
1 reply 0 retweets 1 like -
we already have a first class mechanism for managing visibility: scope. let's just use scope correctly and forget all the absurd attempts at hand-holding developers with language reserved words.
1 reply 0 retweets 1 like -
i am dubious of this but not willing to dismiss it out of hand
1 reply 0 retweets 1 like -
closures are good actually is what i'm saying
1 reply 0 retweets 2 likes
daring move testing culture gonna getcha
-
-
if you're testing implementation details you're doing it wrong. black-box testing is correct.
1 reply 0 retweets 1 like -
sure, but some people might say that when you inaccessibly embed functions in other functions you're doing the exact same thing as someone using private methods and just not testing them
1 reply 0 retweets 1 like - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.