You wouldn’t get it

Sjmarf@sh.itjust.works to Programmer Humor@programming.dev – 391 points –
45

Ha. Cause there's no getter. I get it. I think?

They don't call me AbstractJokerAdapterFactoryProxy for nothin'

Where are your gods now?

public static Joke getTheJoke(Meme yourMeme) {
  Field jokeField = Meme.class.getDeclaredField("joke");
  jokeField.setAccessible(true);
  return (Joke) jokeField.get(yourMeme);
}

Is it Java? It looked like Microsoft Java C# to me...

    public static void Main(string[] args)
    {
        var meme = new Meme();
        var joke = GetTheJoke(meme);
    }
    
    public static Joke GetTheJoke(Meme theMeme)
    {
        var memeType = typeof(Meme);
        var jokeField = memeType.GetField("Joke", BindingFlags.NonPublic | BindingFlags.Instance);
        return (Joke)jokeField.GetValue(theMeme);
    }

There isn't an unnecessary level of capitalization; seems to be regular Java with Allman braces.

Frankly it's been a while since I wrote either one. I just assumed Java because of the naming convention, and I didn't see anything I took as obviously un-Java in the class definition

Is it Java?

Wait a minute, that's an actual thing in java!? What the fuck Java I already didn't like you and now you start pulling this shit? What even is the point of creating standards if you design backdoors to them

If you want to be able to eg. (de)serialize non-public fields of a type for any reason, you'll need some way to get around the access restriction. Mocking is another use case – although it's a philosophical discussion whether you should be mocking non-public fields.

And this isn't just a Java thing, the comment you're responding to has an example in C#, and you can do something similar in a lot of languages that support runtime reflection. Barring runtime reflection support you can do pointer math if the language supports it. Access restrictions on fields are there to stop casual misuse of private fields, but sometimes you actually may want to be able to step over those restrictions if you really know what you're doing.

Yea, what @hydroptic@sopuli.xyz posted is actually Java

What even is the point of creating standards if you design backdoors to them

If you're building in a backdoor anyways, why would the backdoor require 5 lines of weird reflection to get the type, type info, fieldinfo with the correct binding flags, and then invoking the method?

I think it's kinda neat compared to C#, just being able to say "Ignore private/protected/internal keywords"

Reflection is sometimes a necessary evil. At least it makes it harder to abuse the class and if you do, then you are responsible if something goes wrong.

i hate this programming pattern with a passion.

Setters and Getters?

yes.

So what is a better paradigm in your opinion?

Immutable members. Set in constructor then read only. The Builder pattern is acceptable if you're language is an obstacle.

So do you create new objects every time you need to change state?

You avoid having mutable state as much as possible. This is a pretty standard concept these days.

Can you please give me an example - let's say I have a big list of numbers and I need to find how many times each number is there.

I would expect a mutable dictionary/map and a single pass through. How would you do that without mutable datastructure?

Very standard use case for a fold or reduce function with an immutable Map as the accumulator

val ints = List(1, 2, 2, 3, 3, 3)
val sum = ints.foldLeft(0)(_ + _) // 14
val counts = ints.foldLeft(Map.empty[Int, Int])((c, x) => c.updated(x , c.getOrElse(x, 0) + 1))

foldLeft is a classic higher order function. Every functional programming language will have this plus multiple variants of it in their standard library. Newer non-functional programing languages will have it too. Writing implementations of foldLeft and foldRight is standard for learning recursive functions.

The lambda is applied to the initial value (0 or Map.empty[Int, Int]) and the first item in the list. The return type of the lambda must be the same type as the initial value. It then repeats the processes on the second value in the list, but using the previous result, and so on until theres no more items.

In the example above, c will change like you'd expect a mutable solution would but its a new Map each time. This might sound inefficient but its not really. Because each Map is immutable it can be optimized to share memory of the past Maps it was constructed from. Thats something you absolutely cannot do if your structures are mutable.

So you have memory space which is reused... Which essentially makes it a mutable memory structure, where you update or add with new data keys... No?

No. Persistent Data Structures are not mutable. The memory space of an older version is not rewritten, it is referenced by the newer version as a part of its definition. ie via composition. It can only safely do this if the data it references is guaranteed to not change.

x = 2 :: 1 :: Nil -- [2, 1]
y = 3 :: x -- [3, 2, 1]

In this example both x and y are single linked lists. y is a node with value 3 and a pointer to x. If x was mutable then changing x would change y. That's bad™ so its not allowed.

If you want to learn more about functional programming I suggest reading Structures and Interpretation of Computer Programs or Learn You a Haskell for Great Good