Era wrote:And if they do encapsulation, you can't even see the code to know what the h is going on!
...
Functions are not encapsulated, thus the code is visible, readable, modifiable.

Anyway, OOP mostly serves purposes unrelated to personal, individual coding. It's at base a clerical system, an effort at version control when people program in groups. Plus its theoretical abstractions appeal to academics and its complexity creates job protection via obscurantism.

I must hope that you become at some point aware that your blithe self-confidence can be hard for others to understand.

I don't think proof is possible because the dispute isn't fundamentally about programming; it's about religion. True believers in OOP will defend it endlessly.

nnnik wrote:You prove your main argument that the over head of OOP exists.

You have not yet defeated the counter argument that the over head gives the programmer better abilities over the long run.

Era wrote:My dear Mr. ? SwagFag:
Functions can be provided with input/output descriptions via comments...so you don't need to tax your pretty head with reading the code within. I/O comments are quite like OOP in that way, without the messy code hiding and cascade. You can tell people what to put in , and what to expect out. Just like a laxative. Get it?

nnnik wrote:

Era wrote:My dear Mr. ? SwagFag:
Functions can be provided with input/output descriptions via comments...so you don't need to tax your pretty head with reading the code within. I/O comments are quite like OOP in that way, without the messy code hiding and cascade. You can tell people what to put in , and what to expect out. Just like a laxative. Get it?

So it's okay if functions are black boxes but if classes are it isn't?

Also please stop that belittling tone with our helpers.

Era wrote:My dear Mr. ? SwagFag:
Functions can be provided with input/output descriptions via comments...so you don't need to tax your pretty head with reading the code within. I/O comments are quite like OOP in that way, without the messy code hiding and cascade. You can tell people what to put in , and what to expect out. Just like a laxative. Get it?

Era wrote:

nnnik wrote:Only very few things make sense as functions.

1. Functions are for the parts in your script that you are never going to reuse as objects are meant for and superior for reuseability.
2. Functions are for the parts of your script that access super globally, because if you don't need them everywhere encapsulating them in an object makes more sense.

Reuseability is a complete myth. How many times have you actually plugged a previous bit of code into new source code? Probably never. This is because context defines the massively unpredictable interactions between input and output. So the hoped-for black box reuse is a complete non-starter.

I've been hearing for three decades about how this and that will allow you to reuse code. Beyond any but the most simplistic, short, code snippet, reuse is more trouble than it's worth.

Crockery.

lexikos wrote:Please give an example of a move toward OOP in v2 that you find baffling.

Reuseability is a complete myth. How many times have you actually plugged a previous bit of code into new source code? Probably never. This is because context defines the massively unpredictable interactions between input and output. So the hoped-for black box reuse is a complete non-starter.

swagfag wrote:just using it as an example, this was posted just a while ago: https://autohotkey.com/boards/viewtopic ... 18&t=48182

full disclosure, i hit expand, scrolled past 5 screenfuls of text and instantly my gut wrenched with aversion. i didnt even want to try and read, let alone comprehend the code

the dude is trying to click some buttons in a game, imagine how nice it wouldve been if you had a Button class, which had its coordinates, its corresponding image for imagesearching, its own randomize coordinates and click methods, and all this errorLevel checking fuckery tucked and handled neatly away from sight. U would then have the script read for each Button, do Button.click() and it would be immediately apparent what the script does, and if you needed to know what click() does specifically, you could peek into the class and its definition.

instead you have to go line by line(and no u cant assume and skip over) and cram all of that in your head at once to maybe get the big picture of whats going on with the program

kczx3 wrote:I don’t think anyone got trolled here...

nnnik wrote:Only very few things make sense as functions.

1. Functions are for the parts in your script that you are never going to reuse as objects are meant for and superior for reuseability.
2. Functions are for the parts of your script that access super globally, because if you don't need them everywhere encapsulating them in an object makes more sense.

jeeswg wrote:- If you're saying that anything done via object classes can be done just as well if not better with custom functions alone, I'm tempted to agree. Suggestions of any *well-argued* exceptions are welcome.
- I'd say that often people write both custom object classes and custom functions in an unnecessarily unclear way. I'd also say that object classes can be written in a way that is as readable as custom functions. However, in practice, I would say that people use object classes where functions would be sufficient or preferable, and that the classes will end up being more unreadable than the functions would have been.
- Personally, for anyone writing a class, I find that OTB instantly makes the class harder to follow, I would use Allman style.
- Since this is in the AHK v2 development forum, I suppose that you are saying that AHK is becoming 'too OOP'. Which bits are becoming 'too OOP' in your view, and what would you propose instead?