Scrap Your Boilerplate

12 lines of Agda code is verified red-black tree insertion.
12 lines of Java code would be a class declaration with some getters/setters

getters/setters

non needed. just make your attributes public

>>2
Violates the encapsulation of data principle.

12 lines of Agda code is unreadable crap
12 lines of Java code would be unreadable crap too
Just use C

>>4
C is less readable than both of them.

*(* (*) *(*) **(*)___zinit___*(* (* *) void) * size_t*(*);

>>3
Why is that even important? What's the difference between setting the attribute using setter vs. setting it directly? Setter just introduces unnecessary boiler plate. It makes the code harder to read. That usually also means more bugs. Your encapsulation principle is just bullshit.

>>6
Holy fuck you are an idiot ignorant of the OOP principles.

The point of encapsulation is that if in the future you change the underlying implementation of your class, code will still work. You want to allow your client to directly access your fields? In the future your class might not even have those fields, good luck having code like foo.x += 1; work when foo doesn't even have a field named "x".

>>7

In the future your class might not even have those fields

Thank G-d I used getField then. HIBT?

>>8
You'll be able to redefine getField() to anything else then, like y + z.length, and code will still work.

>>9
Which is pointless if the underlying field no longer exists.

>>7
Fuck OOP and fuck ENTERPRISE ENCAPSULATED REUSABLE CLASSES. Begone, evil witch, and tale your fucking UML with you. If the programmer can't be trusted to operate with the data structure himself, then he shouldn't be a programmer. And anyway, 99.999% of the time, the shitcode is going to be rewritten anyway, because it doesn't matter how fucking great that class is, no one in going to want to undertake the task of turning that CD burning app into a golf simulator server.

>>10
No, it's not pointless, because when the client used .getField() in his code, he didn't want just a number, he wanted a particular piece of functionality. .getField() is a signal sent to your object, and if your object responds in the way expected of it, everything's fine. As for the underlying representation, it doesn't matter. You can change it over time, add functionality, make your class more flexible and adapt it to changing user requirements - the code will still work. You just have to change your coding style from numbers and bits to black boxes that exchange messages. It doesn't matter what's in the box if it can respond to messages and send messages with the functionality that you or your client code wants.

Thanks for taking Object Orientation 101.

>>11
Of course the coder can't be trusted to operate with the data structure. Mediocrity is the key to replaceability, and OOP design is the basic tool to achieve that and bring down the costs of hiring and keeping coders.

>>12
Then the getter wasn't converted from a field in the first place, you dumb fuck.

>>14
Yes, in the ideal OOP design there shouldn't even be a need for getters, but in some of the simpler cases the only reasonable objective of sending a message is to get the value of one field. However, after a change of representation this field might disappear and that same message will not be a getter anymore. Yet the encapsulation principle will help you even in such a case.

>>15
This remains complete nonsense, even if you repeat it FIVE times.

The getter is either trivial or not. If it isn't trivial, there can't ever be a raw field because that would mean putting the logic into every call site, which is beyond retarded. If it is trivial, it's a fundamental property of the object, i.e. any potential getter won't ever change.

The only case where something fundamental enough to be a public field might change is a complete redesign, but preparing for that case is insanity. Your case doesn't exist.

>>16
In fact such a use case is mentioned even in the SICP, and I can think of many more. It's complex numbers: initially you represented them as (x, y) pairs, and exposed the getX(), getY() accessors. Then you switched the representation to polar coordinates. Do I need to continue or can you see why you're a dimwit dumbass by now?

Thanks for showing us that you're too stupid to read even a good undergrad book on programming, I had a moderate laugh off your stupidity and ineptitude at even the most basic principles of the dominant contemporary design paradigm. You are shit-coder supreme.

>>16
FUNDAMENTAL PROPERTY OF THE OBJECT HURR DURR
NOTHING WILL EVER CHANGE

>>17
Complex numbers are a great example where this doesn't work outside of theoretic examples as the two representations have vastly different strong points. Suddenly changing the performance (or rather, accuracy) characteristics of points to another coordinate system will fuck up everything.

Even though you insist on SICP, you seem to have missed the parts about EXPERT PROGRAMMERS choosing the abstraction level appropriate for their programs. Changing the fucking coordinate system isn't something that just happens unless you love rounding errors.

>>19

to another coordinate system

This part doesn't belong there.

>>19
Keep to your denial all you want, idiot, and thank goodness I don't have to deal with your code.
Want more examples up your ass - I've got 'em.

https://css-tricks.com/list-of-depreciated-elements-still-in-widespread-use/

Your objects had an align member, now they don't, but .getAlign() is still meaningful.

I could give you more examples but you know what? I'm not your mentor, I don't get paid for educating shit-coders, and - thankfully - I'm not the unlucky bastard that has to deal with your crappy code.

>>19
You were developing a game where units had armor ratings that were used to calculate damage. Then you've decided to extend the game with the ability to change armor based on magic effects or rust or whatnot. Not your units don't even have an armor field, they have baseArmor and shit so you just change the .getArmor() getter to

double getArmor() {
return (baseArmor + armorUpgrades + calcArmorModifiers(getCurrentEffects());
}

___zinit___

Nice undefined behavior.

*(* (*) *(*) **(*)

Nice stars.

*(* (* *) void) * size_t*(*);

Is this even valid C?

>>21,22
So now you have a getter/setter pair for which set(get()) is no longer a noop, good job. Who was the shit-coder supreme again?

What you are describing is essentially a hack that puts logic where it doesn't belong. You are changing the meaning of a method and expect everything to just magically fall into place because in your contrived example, all calls to that method just happen to use the new meaning already. Do I really need to tell you why this is bullshit?

>>24

set(get())

Talk about useless kekek.

>>25
Why is a Korean up so early on a Saturday morning?

>>24

puts logic where it doesn't belong

Who are you to judge that if you can't even understand the principle of encapsulation? Objects are black boxes, they can redistribute logic inside of themselves however the fuck the programmer wants.

You are changing the meaning of a method

I am explicitly not changing the meaning of the method. getArmor() still returns precisely the armor rating effective at precisely the moment of the call.

and expect everything to just magically fall into place

Haha, even the idiot is beginning to appreciate the beauty of the encapsulation principle. Yes, to an undeveloped mind such as yours, good software development techniques such as this must seem like magic. "Any sophisticated technology ..." etc.

all calls to that method just happen to use the new meaning already

They don't happen to use the new meaning, it's that the new "meaning" (new functionality, actually) is the same as the old one - it's just that the underlying representation that has changed! Looks like you're learning something new here.

>>27
You have arrived at the point-by-point-quote stage, where all coherent argument is lost and replaced by irrelevant fragments that create the impression of a rebuttal. Took you only seven posts and one angry sage.

It really makes no difference whether the method that used to return a unit attribute is now performing operations needed exclusively for the likes of damage calculation. After all, there couldn't be even a single call to getArmor that would use it in the base stat sense. Who needs shit like ordering by base stats anyway? Thank G-d for nonsense examples that prove your point without pertaining to reality.

>>24

a getter/setter pair

Who told you that getters and setters have to form pairs, dipshit? Methods are messages and should be designed around the dataflow and functionality separation between objects, not about what fields they happen to have at a certain moment in development & maintenance cycle. It may be totally logical to have a getter without a setter, or a setter that also gets the value, or a getter that also modifies the value, or a getter for three fields at once.

>>29
The premise did. We are talking about turning public fields into getter/setter pairs, remember?

>>28
More contrived bullshit excuses from you? You'll spew any stupidities if only to never admit that reality doesn't conform to your ignorant pre-conceptions about it? OK, I'll respond but this is the last time:

It was a method to get the effective armor rating. It still is, just that the effective armor is not a field anymore, but a calculated value. But the semantics is the same, thus any and all client code remains working correctly without any adjustments.
Armor rating has to be recalculated every time the unit experiences a hit, so the getter is absolutely the right place for that logic.
The baseArmor is another field that may be used by other methods, e.g. there may be an armor buff that is proportional to the base armor not the effective one.
There is the alternative of keeping the armor field and making all the armor-upgrading and effect-adding methods update it, but that is obviously very brittle and error-prone - if you or the maintainer of your code forget to mutate the armor field in some future magic effect, that will introduce a quiet and hard-to-find bug, as well as making your code harder to understand.

>>31
I'm not the one attempting to change topic and premise as he sees fit.

It wasn't an effective armor rating; it couldn't have been, for effective armor implies a difference between states. However, if there was a difference between states, there wouldn't have been any point in ever making effective armor a public attribute — only normal armor. Hence, effective armor cannot be subject to this discussion (>>30) and armor must already be the normal armor, with all the semantical nonsense the changes cause.

It's hilarious that you suggest a baseArmor stat. What is the difference between changing all base stat uses of getArmor into getBaseArmor and changing all damage calculation uses of armor into getEffectiveArmor? The latter doesn't silently break your API, enterprise boy. So much for stability.

>>32
I already said I'll stop explaining it to you. Educate yourself without my help.

>>33
You also said you'll stop responding, yet here we are, without a single point from you.

OO guy you're the best troll I've seen in a while, thanks.

Lisp macros can be done with just a couple of Haskell libraries, and in a type-safe way

http://stackoverflow.com/questions/24172117/navigating-and-modifying-asts-built-on-the-free-monad-in-haskell

>>36
that is gay as fuck
what the fuck are thye smoking

>>37 "Safety"

12 lines of C is a verified fibs generator.
12 lines of Scheme is a bunch of lambda and other side effects avoidance ``code''.

Jesus this thread just gets worse and worse.

>>7

good luck having code like foo.x += 1

If you remove public attribute, then of course you have to change the code using that attribute. So what? This is only relevant for library API. In other cases you just refactor the code using that attribute. If you change the implementation, you most likely have to check the caller code anyway, to check that it's still correct (boring edge cases etc.). The good part in public attribute here is that it forces you to check the usage if implementation changes totally. That reduces bugs. Oh, did I mention using getters and setters make the code harder to read, thus introducing more bugs. LOL, I bet your enterprise code is unreadable shit, full of bugs. All because you insist on your stupid OOP principles. Fucking coder.

>>22
I would not change the getArmor() to incorporate buffs/debuffs, I would add a new function getAdjustedArmor() since the raw armor value is still probably used (say in a stat screen for an item or w/e)

I would not change the getArmor() to incorporate buffs/debuffs, I would add a new function getAdjustedArmor()

And existing mods would not care about buffs/debuffs.

>>41
No, you don't have to change client code, unless you're a shitcoder ignorant of the encapsulation principle. You don't have to refactor and you don't have to check the caller code. The world becomes quite a magical place if you only stop being an ignoramus and start learning proven programming techniques.

>>41

The good part in public attribute here is that it forces you to check the usage if implementation changes totally. That reduces bugs.

You sound like a goddamn Haskiefaggot. "Static types everywhere are good, they reduce bugs because if you change a type, you'll break as much code as possible, forcing you to check every usage. The more broken the better!!1" Fucking idiot.

>>35
I honestly don't know which one of the two you are referring to. It might very well be a match between trolls.

If you rely too much on oo shit to take care of stuff without you having to think about it, you'll start getting bugs where the program does things other than what you think it should do. The code may be doing something now that is very different from what it did when it was first written.