That's one option. Quasar was configured to run as a runtime agent while the Lombok compiler runs at compile-time, but the Lombok compiler could perhaps indeed be implemented as a Java agent of javac's. This, however, would also require a special configuration of javac, just like all other alternatives. A simpler option is to offer a separate launcher for that compiler (and/or a special build-tool plugin, which is also what Quasar did in its AOT mode).
No matter what, code that wishes to break the guarantees that JDK programs want to make needs to configure that program in some special way so that there's some record, auditable by the application author, saying "this program has been modified in a way that may make it behave not in accordance with its specification".
You could do a lot of the lombok things as a runtime agent. I think @ToString, @EqualsAndHashCode, @Synchronized, @Getter(lazy=true), @UtilityClass, @Delegate, and @Cleanup could all be implemented in a runtime agent. Most of the rest could work as a runtime agent too as long as you were willing to type out the method signature (plus maybe a native keyword) for the things you actually want to link against at build time.
I think this would end up being way more difficult to use though and I think it would be perceived to have way more risk compared to lombok as it is now. What do you think?
Also is something wrong with paralleluniverse.co? The root domain seems to go to a gambling site?
Isn't how you pass things into a function separate from whether you are hiding information? If your state parameter was an opaque pointer then you wouldn't necessarily be able to do anything with it. Also if your class internals were public you would be able to change anything you wanted.
Exactly! You don't need classes to obtain information hiding. In general treating the state as an opaque pointer is a good thing. But the state is part of the public API whether you want it to be or not. Even if you try to "hide" it in the OOP sense, the result of the methods depends on the internal state so it is leaked through the behavior of those methods.
However, when it is hidden in the OOP sense it makes it much harder to reason about the behavior of a function without reading the source code. Because there is this internal "hidden" state that you do not know exists.
But a referentially transparent function is much easier to understand. For a given input, you get an exact output.
You're talking yourself in circles. Your final sentence contradicts the remainder of your point.
Testing is limited when you do not have the ability to fully control state, and understanding can be limited when information is hidden. The impacts of this are determined by the information being hidden, its relationship to the function's behavior, and the documentation of that behavior relative to the calling context.
Limitations on the ability to fully control state are orthogonal to the method of information hiding (opaque function parameters, internal object state, etc).
This is not an OOP/functional discussion, this is a discussion about the tradeoffs inherent in information hiding. And let's be perfectly clear here: These are tradeoffs, not black and white clear wins in either direction.
I think information hiding is the wrong term. It should be hidden for modification, open for inspection. Functional programming naturally promotes this. OO does not. That's my opinion.
It's been a useful discussion though so I appreciate everyone's input.
So are you saying you no longer think OO inherently makes things harder to test?
I feel like it's difficult to talk about this without examples.
The library I like thinking about when I think of passing around in a state variable is the lua C api.
This is pretty object oriented except that it's not using C++'s syntax sugar. You can't really do much with L except pass it into other lua "methods". The discussion up until your comment seems to be about the difference between using the syntax sugar and passing around a state variable yourself.
Information hiding and these other implementation details are kind of seperate. In my example you can't just configure L exactly how you want by messing around with it or inspecting its state directly. You have to go through accessor "methods".
I think if the argument is that OO promotes information hiding I can agree with that. I'm not sure about the point about the internal state becoming a part of the API though. APIs are contracts that can be met with different implementations right? If your implementation details are public then your contract is huge and inflexible.
Not exactly, I'm saying OO still makes it hard to test because it is an opaque blob of state. It would be really hard to use/test the LUA API for example without knowing it is using a stack underneath the hood. That detail leaks through the API whether you want it to or not. If it was switched to a FIFO queue that would completely change the behavior.
Since using this API makes an implicit constraint that it is using a stack underneath the hood, why not just expose the stack for inspection? What advantage does keeping it an opaque blob have? I agree you don't want code manipulating this stack (although if it is immutable as in FP this isn't an issue), but since the external code already knows it is a stack and relies on that fact then it is part of the public API already.
The term information hiding used in this thread is very confusing (to me, at least).
I believe David Parnas introduced it in 1971 to mean that a program's design was sliced along shared units of concerns (things that vary together) rather than "steps in a flowchart".
I think that's been quote mined.
Here is a link to a comment by a moderator on /r/interestingasfuck that includes the context. Followed by more discussion about why he was banned from more subreddits.
I think these five moderators share power with the other moderators on each subreddit and each subreddit's mods can see each other's actions. Does this put this into the former category?
As far as what happened here the moderator for /r/interestingasfuck has been talking about it. He seems pretty open to answer questions. Maybe he could be asked if he gets paid to moderate?
In C, braces on a new line is the prevailing style? I've been doing the opposite because that's what K&R C does (except for braces that define functions).
