What exactly is the point of OOP? As far as I can tell, an object

>>60988829
Inheritance and polymorphism.

>>60988896
>Inheritance and polymorphism.
So if you're not using that, your objects aren't real objects/you're not doing OOP?

>>60988923
Yeah. You're just using structs.

>>60988923
Yeah, except that polymorphism isn't unique to OOP and that inheritance is shit.

Don't use OOP, it's shit.

>>60988965
Polymorphism is in no way unique to OOP. Inheritance is, but OOP programmers are instructed to avoid it and to use composition instead. Are you sure those are the two things that make something object-oriented?

>>60989010
>Don't use OOP, it's shit.
I don't, but I'm not here to make value judgments about OOP. I just want to understand what the essence of "objects" is to OOP programmers.

>>60988829
I've no idea what you mean by "mung" so I can't answer your question.

>>60989061
There are many kinds of polymorphism though. I was talking about the stuff where a function with a base class argument also accepts every class derived from it, this also applies to collections. This requires vtables.

>>60989113
>I've no idea what you mean by "mung"
In this context it means mutating the object's internal state.

>>60989144
>a function with a base class argument also accepts every class derived from it
But you're talking about class-based OOP. There are OOP languages without classes.

>>60989076
The essence of objects to OOP programmers is encapsulation. It's mostly just a way to structure a program so as to separate implementation from interface.

It's just a way of designing your code that someone thought was a good idea sometime. Some languages have it built in. If you listen to Alan Kay you may find out that popular oop languages today aren't really the same as the original idea for oop. Have a look at pharo, learn about the Xerox alto and the features of the OS. Then wonder why we still don't have these features in modern OSs

>>60989233
>The essence of objects to OOP programmers is encapsulation
That's what I thought initially, but the average object in OOP-land has a whole bunch of setters. Encapsulation implies self-contained-ness. Most objects are not self-contained.

>a way to structure a program so as to separate implementation from interface
I don't see how this relates to objects.

>>60988829
Just another way to hide the state from the programmer. Any other use of provided mechanisms is heretical.

>>60989289
>If you listen to Alan Kay you may find out that popular oop languages today aren't really the same as the original idea for oop
Can you elaborate on what the "original idea for OOP" was? What's the essence of an object there?

>>60989363
>but the average object in OOP-land has a whole bunch of setters. Encapsulation implies self-contained-ness.
So what, though? Why does self-containedness imply constantness?

>>60989363
>I don't see how this relates to objects.
You can only access them from the outside using their public members, which then constitute their interface, whereas the implementation details are hidden with non-public members.

>>60988829
The point is to write as many lines as possible. Notice how FP-fags write everything in one line and have no jobs? Now you know why.

>>60989502
>Why does self-containedness imply constantness?
It doesn't, but if you find yourself writing getters and setters, it usually means that some other part of the program controls parts of the state of your object, so it's no longer self-contained.

>>60989626
That doesn't necessarily mean the object isn't self-contained. A class for describing 2D coordinates, for instance, can be self-contained even though it can be changed. Other code simply uses this encapsulation of 2D coordinates however they want.

>>60989514
>You can only access them from the outside using their public members
That just brings us back to functions and data structures, though (headers and opaque pointers).

>>60988829

Virtual functions and runtime polymorphism. Essentially just hidden function pointers.

>>60989665
>headers
How are you using that word here?

>opaque pointers
Yes, that's another method that is commonly used for encapsulation. Noone ever claimed that OOP brings new programmatic capabilities to the table (Turing-completeness &c&c). It basically just makes opaque pointers the ideological default.

>>60988829
SAS

>>60989650
>That doesn't necessarily mean the object isn't self-contained.
It does, because the object is no longer an independent unit. The semantics of its supposedly private fields are determined by external code. If you took at object and started to expose its private fields using getters and setters one by one, at what point does it cease being an object and become a glorified struct?

>A class for describing 2D coordinates, for instance, can be self-contained even though it can be changed.
What's the difference between a class for describing 2D coordinates and a struct?

>>60988829
Just another shitty "paradigm" for brainlets full of theoretical buzzwords, promising them a way to make their code fast, portable and maintainable, while those traits come from experience and intelligence of the user.
A good programmer uses the paradigm right for the job, he doesn't get told what he has to do.

Functional programming hype and the crusade against states are the same garbage, mind you

>>60989696
>How are you using that word here?
I was thinking of the separation of C code into .c (implementation) and .h (interface) files. Of course, this is just one of many ways to do it that don't involve OOP.

>It basically just makes opaque pointers the ideological default
My point is that separating interface and implementation (even as an "ideological default") is a principle that doesn't require the concept of an object at all.

>>60988829
>The difference between foo(obj, arg) and obj.foo(arg) is purely syntactic

the point of OOP is that it helps you reason about your software.

>>60989792
>the point of X is that it helps you reason about your software.
You can say that about any paradigm. What's the essence of objects that makes them conductive to reasoning about software?

>>60989805
Encapsulation

>>60989721
>at what point does it cease being an object and become a glorified struct
Implementation-wise, an object really *is* just a glorified struct, but that's not the point. The point is that you choose what getters and setters you add to a class in order to expose the behavior you want to expose. At what point it "ceases to be an object" depends entirely on the object you're trying to create. Why would you complain that, for instance, an object describing a configuration file has a setConfigurationDirective method?

>My point is that separating interface and implementation (even as an "ideological default") is a principle that doesn't require the concept of an object at all.
Conversely, you could argue that a properly designed opaque pointer is an object.

>>60989817
>Encapsulation
Feel free to give your input on this exchange about encapsulation: >>60989363

In the end it's just a way to organize your code.

When you're working on a project with dozens of developers it gets harder and harder to keep track of everything. That's why when you get these enterprise projects with for example factory objects. It seems like too much indirection but when you can document the factory and the output objects then that's all the other developers need to know. They don't need to know what's happening inside.

Biggest team I was on was around 35 programmers and a huge code base. OO and some of the patterns that look funny on a small project were helpful.

>>60989849
>you choose what getters and setters you add to a class in order to expose the behavior you want to expose
As far as I understand it, the "behavior" of an object defines how its internal state should change in response to inputs. Getters and setters don't expose behaviors. They expose data, usually because the behavior (as far as the exposed fields are concerned) is defined outside of the object, thus it is no longer self-contained.

>At what point it "ceases to be an object" depends entirely on the object you're trying to create.
Is there a way in OOP-land to determine whether a particular instance of an object (in the technical sense) is an object in a meaningful sense? Surely you'll agree with me that taking a plain struct, turning it into a class and adding getters and setters for every field doesn't make it an object in any meaningful sense.

>Conversely, you could argue that a properly designed opaque pointer is an object.
How do you figure?

>>60989805
>What's the essence of objects that makes them conductive to reasoning about software?

Because then you can model them as interacting entities.

>>60988829
An object is a data structure with a set of functions to mung it. It's the same thing that you're describing about non-OO programming.

Some languages they're exactly the same. For example objective-c compilers (pre-compiles really) used to just produce c code and then compile that.

It's just a way to organize your code to make it easier to understand.

>>60989961
>Getters and setters don't expose behaviors.
That's not necessarily true. In the example of an object describing 2D coordinates, the data is all the behavior you want to expose. These are, of course, the more struct-like objects of a system, but isn't that all right? In the end, at the bottom of all algorithms, you always need to describe data.

That being said, of course, it could also be a sign of an improperly designed object. Naturally, there are bad programmers out there, regardless of whether you like the OOP ideology or not.

>Is there a way in OOP-land to determine whether a particular instance of an object (in the technical sense) is an object in a meaningful sense?
Not in any context-free sense. As above, it depends entirely on the behavior you wish to encapsulate. The way to evaluate how well that behavior has been encapsulated is, I'd posit, to compare the interface you just wrote to your mental conception of the behavior.

>How do you figure?
One might argue that if you're just using opaque pointers and behavior-like functions to interact with them, you're already writing object-oriented code, only in a language that wasn't explicitly designed for the purpose.

>>60989966
>you can model them as interacting entities
There are many cases where trying to model conceptual entities as objects in code only makes it harder to model the interactions between them. (Copious amounts of getters and setters usually indicate this sort of problem)

>>60990050
>That's not necessarily true.
It is necessarily true if you accept that the "behavior" of an object defines how its internal state should change in response to inputs. If you don't accept this, then please define "behavior". I can't really address the rest of your post because at this point I'm not sure what you mean.

>>60990108
>It is necessarily true if you accept that the "behavior" of an object defines how its internal state should change in response to inputs.
As I said, it isn't true if all the behavior you want to describe is a set of data, as in the 2D coordinate example.

>>60990129
I don't understand what it means for data to be behavior. Define "behavior".

>>60990161
Well, take a struct for instance, since they seem topical. The "behavior" of a struct is that it has members, whose contents can be used or changed. Modelling a struct in OOP would seem to imply writing getters and setters for each such member.

>>60990052
>There are many cases where trying to model conceptual entities as objects in code only makes it harder to model the interactions between them.

well then don't use OOP duh

The answer is encapsulation

>>60990177
>The "behavior" of a struct is that it has members
This doesn't make sense to me. I'm asking you for the third time to define "behavior". I think the behaviors of a struct are to read from a field or to write into a field on request, but we seem to disagree.

>>60990187
>well then don't use OOP duh
So what is OOP good for, again?

>>60990192
>The answer is encapsulation
Then why do you have to break it constantly using getters and setters in any non-toy program?

>>60990203
>I think the behaviors of a struct are to read from a field or to write into a field on request, but we seem to disagree.
Do we? That sounds like exactly the same thing I said.

>define "behavior"
I don't have a concise definition of it. Rather, I'm trying to make examples.

>>60990215
Situations where you don't want POD. No paradigm is absolute senpai.

>>60990249
>That sounds like exactly the same thing I said.
No. You said its behavior is "that it has members", which makes no sense to me. What I said is consistent with my definition, which you disagree with.

>I don't have a concise definition of it.
Then we've reached an impasse...

>>60990259
>Situations where you don't want POD.
That boils down to a tautology: "OOP is good when you don't want the opposite of it".

>>60990299

Not all data structures are pairs of coords. You're supposed to use the right tool for the job and encapsulation + abstraction can be very useful for modelling more complex behavoirs than setting and getting x and y.

>>60990233
But I don't.
Stop assuming that everyone misuses OOP like java pajeets does.

>>60989415
http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

>>60990332
>But I don't.
So you don't use getters and setters?

>>60990323
That's all very vague, anon. What I'm essentially asking you is this: what makes a good object? I'm not looking for abstract platitudes like "use the right tool for the job", but rather something more concrete.

File: shitpost-1.jpg (21KB, 320x304px) Image search: [Google]

21KB, 320x304px

>>60990280
>which you disagree with
Why are you contending that I disagree with you at the same time that you're saying that you don't understand what I'm saying? You wouldn't, by any chance, just be trying to be contentious, would you?

>Then we've reached an impasse...
To be fair, you haven't tried either.

>You said its behavior is "that it has members"
I said that it has members "whose contents can be used or changed", which seems consistent with what you said about "to read from a field or to write into a field on request".

>>60990368
>What I'm essentially asking you is this: what makes a good object?
That's like asking "what makes a good data structure". As I said in >>60990050:
>Not in any context-free sense. As above, it depends entirely on the behavior you wish to encapsulate. The way to evaluate how well that behavior has been encapsulated is, I'd posit, to compare the interface you just wrote to your mental conception of the behavior.

>>60989415

The original idea was to have objects be separate entities when the program is running, and pass messages between them. So it was a late binding thing, not a static thing like how the mainstream ran with.

>>60990369
>why are you contending that I disagree with you
Because I said this:
>the "behavior" of an object defines how its internal state should change in response to inputs
And you said this:
>it isn't true if all the behavior you want to describe is a set of data

>you haven't tried either.
I've explained what I understand "behavior" to mean in this context. If it's not clear enough, I can give you something more detailed and definition-like.

>which seems consistent with what you said
The data is not the behavior, as far as I'm concerned. If you expose a data field through getters and setters, you are exposing data, not a behavior.

>>60990379
So basically, OOP programmers don't know what makes a good object? They just somehow "know" it when they see one?

>>60990426
>Because I said this:
>>the "behavior" of an object defines how its internal state should change in response to inputs
>And you said this:
>>it isn't true if all the behavior you want to describe is a set of data
Why are these contradictory? Calling a setter effects a change in internal state.

>The data is not the behavior, as far as I'm concerned.
Why not?

>The data is not the behavior, as far as I'm concerned.
All I'm saying is that what is "good" depends on what you're trying to do. I don't see why this should be controversial.

>>60990382
>to have objects be separate entities when the program is running, and pass messages between them
This has always been my understanding of it as well, but I can see why "mainstream languages" deviate from this: having true separate entities becomes increasingly harder as the interactions between them become more complex.

>>60990215
You're just acting obtuse at this point to try to make a point.

>>60990471
> having true separate entities becomes increasingly harder as the interactions between them become more complex.
That is just reality. FP which actually tries hard to be purely functional has an even bigger problem with this in real code than actual OOP does.

As is, you sometimes just have to compromise a bit on encapsulation to get the job done. Doesn't mean you get nothing from the remainder that you did encapsulate somewhat well, it does still make everything more manageable.

>>60990454
>>The data is not the behavior, as far as I'm concerned.
Fuck the clipboard. That quote was supposed to be >So basically, OOP programmers don't know what makes a good object?

>>60990454
>Why are these contradictory? Calling a setter effects a change in internal state.
I think the problem here is your struct example. You are conflating two different levels of abstraction: if you're talking about the abstract concept of a struct, then field I/O is a behavior. If you're talking about a concrete instance of a struct that is supposed to represent the internal data of some other kind of object, then it isn't.

>>60990473
Not at all. I am asking OOP programmers to explain to me the essence of an object. Can you tell me what makes a good object?

>>60988829
Whole reason for existence of oop is that not so fluent in compsci managers can still approximately get what is going on.

It is just a pure syntax difference. You can achieve the same results, the bloody same algorithms with and without oop.

>>60989721
>What's the difference between a class for describing 2D coordinates and a struct?
That you could have multiple classes for float, double or int coordinates all inheriting from the same interface?

>>60990521
>As is, you sometimes just have to compromise a bit on encapsulation to get the job done. Doesn't mean you get nothing from the remainder that you did encapsulate somewhat well, it does still make everything more manageable.
Right. It seems to me that in practice, most objects are "hybrid" in that they do have some actual private data, but also serve as a way to associate a conceptual entity with data that relates to it but isn't "owned" by it.

>>60989961
>Getters and setters don't expose behaviors. They expose data
What if a setter writes the changes made to the object into a log file or something like that?

File: 1496144418708.jpg (71KB, 700x1636px) Image search: [Google]

71KB, 700x1636px

>>60990596
You would still have different functions for each type being called, it's just syntactic sugar, nothing less, nothing more.

>>60990596
>that you could have multiple classes for float, double or int coordinates all inheriting from the same interface?
The same can be achieved more effectively using data structures and parametric polymorphism.

>>60990541
>if you're talking about the abstract concept of a struct[...]
Is this level of deconstruction really necessary? I just tried to make an example of when you want to represent pure data.

>>60990676
Well coordinates are a bad example for this
You could work with a single method, but with base-types the example doesn't work well

>>60990651
>What if a setter writes the changes made to the object into a log file or something like that?
I don't see how it changes anything.

>>60988896
https://wiki.haskell.org/OOP_vs_type_classes
https://wiki.haskell.org/Polymorphism

Not OO exclusive by any means.

>>60990727
>Is this level of deconstruction really necessary?
Yes, because it explains the root of your error. A data field is not a behavior, and on the level of abstraction we're talking about, getters and setters are just a means to expose data, not a means to expose a behavior.

>>60990756
>haskell

>>60990739
To the outside that behavior is completely invisible. Afaik you can't do that with a struct

>>60990760
>A data field is not a behavior
It has the behavior of being able to being read or written, and getters and setters expose that behavior.

>>60990787
>To the outside that behavior is completely invisible
Okay, the quote you're responding to goes:
>Getters and setters don't expose behaviors. They expose data
And your example still does just that, especially if logging something in the background isn't even part of the stated behavior of the object.

>>60990734
Your compiler still produces different functions. That doesn't change anything.

>>60990794
>It has the behavior of being able to being read or written, and getters and setters expose that behavior.
You're just making the same incorrect assertion again because you didn't understand my rebuttal.

The very core principal of OOP is programming to an interface - contractual behavior and data. Most of the other stuff eg "4 oop features" are kind of incidental, overlap other concepts, and are misunderstood by a large number of average software devs.

Most "OOP" languages are really multi-paradigm now anyway, even java is being slowly dragged into the current trend of functional programming.

>>60990827
What if the change of a value changes the objects name

>>60990846
>The very core principal of OOP is programming to an interface
This principle doesn't require objects in any way.

>>60990851
>what if the getters and setters do things besides being getters and setters
Then they're not getters and setters (at least not for the purpose of my argument).

>>60990846
Also most ITT don't really know what theyre talking about. Arguing about getters and setters is missing the point entirely and arguing about something trivial.

>>60990841
You're just insisting that objects cannot represent pure data, without saying why.

>>60990846
You can treat functions like an interface and it would work just as well. Why objects? Can anyone here give a good use case for objects?

>>60990889
> Arguing about getters and setters is missing the point entirely and arguing about something trivial.
Nice opinion. Too bad you didn't bother to substantiate it in any way or actually address any of the arguments.

>>60990859
Interfaces are THE core features of OOP - they allow inversion of control, encapsulation, polymorphism, and all the other goodies. Things like inheritence are the sideline features.

>>60988829
it was helpful because it allowed you to easily subdivide a complex problem into smaller, easily understandable pieces
but then someone invented design patterns and everything has been going downhill since

>>60990901
>You're just insisting that objects cannot represent pure data, without saying why
No. I'm saying that data fields are not behaviors, and exposing private data fields breaks encapsulation, whether you do it through a getters and setters or directly.

>>60990945
>Interfaces are THE core features of OOP
The principle of coding against an interface is in no way unique to OOP.

>>60990913

You can't treat functions as objects in a state-ful system. You are correct in a stateless system, which is a great ideal but OOP helps us manage state.

>>60990963
To the extent that what you want to model is a collection of data fields, why would you consider those fields private?

>>60990846
Java has map, filter, etc. Good steps, but it's far away from functional and I never see it getting there.

Java has some stuff, like
> Optional.of
> Optional.flatMap
> Optional<T>

But it lacks the type-magic of say, Scala that make it such a mature functional language, alongside being almost magically-bound to side-fx.

Some of the aspects of first-class/higher-order functions have been brought in, and that's cool I guess, but it can't begin to compare to something like Clojure's transducers for example.

tldr java sux lol learn haskell

>>60991003
>To the extent that what you want to model is a collection of data fields
A collection of data fields is not an object in any meaningful sense. It's just a data structure.

>>60991033
To clarify, a collection of data fields doesn't have any behavior at all on its own.

>>60991033
>A collection of data fields is not an object in any meaningful sense. It's just a data structure.
But that's the whole point. There are objects that just represent data structures. The whole 2D coordinate thing was the explicit example thereof.

>>60991070
>There are objects that just represent data structures
You can use the language feature of "objects" to create something that doesn't have any behaviors and isn't meaningfully an object. I don't see how it's relevant to anything.

>>60991051
>>60991089
>a collection of data fields doesn't have any behavior at all on its own.
You yourself said that structs have behavior:
>I think the behaviors of a struct are to read from a field or to write into a field on request

>>60990877
sure not for the purpose of your argument, but if by design, the object needs these changes to remain valid, it wouldn't make sense to provide functionality that doesn't make these changes.
Sure you could still just make a function that does it, but with OOP you can hide stuff, so others can only use the functionality that doesn't break anything

>>60991108
>You yourself said that structs have behavior
You're just making the same error again that's been addressed here: >>60990541

>>60991089
>something that doesn't have any behaviors
Why is the action of storing data and retrieving it not a behavior?

>>60991145
>>60990541
>If you're talking about a concrete instance of a struct that is supposed to represent the internal data of some other kind of object
Why can't a concrete instance of a struct not simply represent itself rather than "some other kind of object"?

>>60991139
None of this changes the fact that real getters and setters usually indicate a break of encapsulation, because they usually serve the purpose of letting some other part of the program control control some of the behaviors of an object. The object's behavior is no longer encapsulated. If the core of OOP is encapsulation, then OOP is an unfeasible ideal that OOP programmers regularly stray from.

>>60989144
Lmao, this is already avaialbe in Haskell through typeclasses, Suck a dick.

>>60991164
>Why can't a concrete instance of a struct not simply represent itself
Because then it doesn't represent an object. It just represents a data structure.

>>60991152
>Why is the action of storing data and retrieving it not a behavior?
You're running in circles. It may or may not be a behavior, depending on the level of abstraction you're looking at.

>>60991226
But what I'm asking is why there has to be a strict dichotomy between objects and data structures.

>>60990990
Why would you treat them as objects? You don't need objects to have interfaces for a state. Just declare a state and define some functions to manipulate that state. Why do you need objects?

File: IMG_3917.jpg (8KB, 230x219px) Image search: [Google]

8KB, 230x219px

>it's another everybody-shits-on-OOP-with-no-argument thread

>>60991249
>why there has to be a strict dichotomy between objects and data structures.
There doesn't have to be. You can admit that in mainstream-OOP-land, an object is just a vague concept, and that any pile of data can be an object if your subjective opinion says it is one. That's fine, too.

>>60991288
>You can admit that in mainstream-OOP-land, an object is just a vague concept, and that any pile of data can be an object if your subjective opinion says it is one.
Isn't that pretty much what I've been saying from the outset?

>>60991200
well in the real world people don't give a fuck about following ideals. They want readable, maintainable code that is unfuckwithable and fast to write. If OOP suffices in these viewpoints, who gives a shit

an object is a data structure with functions bound to it

>>60991295
>Isn't that pretty much what I've been saying from the outset?
The root of the exchange was a claim that OOP is about encapsulation. If that is the case, then most real OOP programs aren't very good examples of OOP because they're full of getters and settes which break encapsulation.

>>60991319
>If OOP suffices in these viewpoints, who gives a shit
I don't think it does. Nobody in this thread is able to explain the unique benefits of OOP.

>>60991288
>>60991295
>>60991410
Also, an object is whatever may be relevant to encapsulate. Part of the OOP ideology seems to be that whatever can at all be meaningfully encapsulated should be encapsulated preemptively.

If I were to try and construe an example of why it may be relevant to encapsulate even such a simple thing as a 2D coordinate and separate implementation from interface, considering the following:

class Coord {
    private double x, y;

    public double getX() {return(x);}
    public double getY() {return(y);}
    public double setX(double v) {x = v;}
    public double setY(double v) {y = v;}

    public double abs() {
        return(hypot(x, y));
    }
}

Now let's imagine that your program is literally *constantly* doing length calculations and that the hypot call turns out to be a bottleneck. Then you could change the implementation as such without affecting the public interface:

class Coord {
    private double x, y;
    private double a = NAN;

    public double getX() {return(x);}
    public double getY() {return(y);}
    public double setX(double v) {x = v; a = NAN;}
    public double setY(double v) {y = v; a = NAN;}

    public double abs() {
        if(isnan(a)) a = hypot(x, y)
        return(a);
    }
}

Obviously, this is a construed example, but it's not like you couldn't find meaningful equivalents in the real world.

>>60991430
hiding functionality that may break stuff from stupid programmers while providing mental models that correlate to the real world.
isn't that enough?

>>60991430
Polymorphism, Inheritance, Encapsulation, Abstraction

stay in school

>>60991200
>getters and setters usually indicate a break of encapsulation

um, what?

>>60991468
>an object is whatever may be relevant to encapsulate
How do you determine what is relevant to encapsulate? It seems to me that the only things that are relevant to encapsulate are those which are determined solely by the object itself, which would mean that almost any given "object" in a real world project contains a bunch of stuff that's associated with the conceptual entity the object is supposed to model, but isn't actually owed by it.

>I were to try and construe an example of why it may be relevant to encapsulate even such a simple thing as a 2D coordinate and separate implementation from interface:
Your example is merely an implementation detail for some optimization. There isn't any meaningful encapsulation going on. It's still just a data structure.

File: osjumh639s4z.jpg (121KB, 1232x1261px) Image search: [Google]

121KB, 1232x1261px

>>60988829
>What exactly is the point of OOP?
It's just a philosophy/methodology a programmer or team can follow for some overall consistent direction for the project.

>>60991479
>hiding functionality that may break stuff from stupid programmers
This is in no way unique to OOP.

>providing mental models that correlate to the real world
This isn't necessarily a good thing at all.

>>60991485
>Polymorphism, Abstraction
Not unique to OOP.

>Inheritance
OOP programmers are instructed to avoid it whenever possible due to its crudeness.

>Encapsulation
OOP programmers break it routinely.

>>60991583
>Your example is merely an implementation detail for some optimization. There isn't any meaningful encapsulation going on.
It was the encapsulation that allowed the optimization without any change in external interface, which is exactly the point about encapsulation. With a pure C struct, you wouldn't have been able to reset the cached "a" field on updates to x or y.

>How do you determine what is relevant to encapsulate?
As I said:
>Part of the OOP ideology seems to be that whatever can at all be meaningfully encapsulated should be encapsulated preemptively.

>>60991507
>um, what?
Actually read the post. It explains exactly what: getters and setters expose object data so that other parts of the program could implement object behaviors.

>>60991606
>This is in no way unique to OOP.
who said it was?
It's a flavor of doing that. What is your fucking problem?

>>60991630
>It was the encapsulation that allowed the optimization without any change in external interface
It's again just a matter of what level of abstraction you're viewing it from. Not worth arguing about.

>Part of the OOP ideology seems to be that whatever can at all be meaningfully encapsulated should be encapsulated preemptively
And you still have not explained what can be "meaningfully encapsulated".

>>60991682
>What is your fucking problem?
OOP programmers and the absolute abominations they create, but I didn't want this thread to be about that. I just wanted to see what different people think the essence of an object is, and how they respond when this notion is challenged.

>>60991784
and there are lots of arguments about what the essence of an object is, but they are disregarded because they're not unique to oop or are broken occasionally.
You fail to realize that it's there to be easy and comprehensible. Easy enough that people who shouldn't into programming still can write code that - for the most part - works. Is that a bad thing?

>>60991630
To clarify: from the perspective of the user, you're again just munging a data structure using an interface. The "object" doesn't have any observable behaviors. It's just a repository of data.

>>60991749
>It's again just a matter of what level of abstraction you're viewing it from.
No, it's a matter of being able to change the implementation without affecting the public interface to it.

>Part of the OOP ideology seems to be that whatever can at all be meaningfully encapsulated should be encapsulated preemptively.
Anything that can be described as a class in whatever language you're using?

>>60991906
>The "object" doesn't have any observable behaviors. It's just a repository of data.
For the umpteenth time, though, updating and reading back that data is the observable behavior of such an object.

What exactly is the point of OP?

>>60991872
>they are disregarded because they're not unique to oop
They are disregarded because they don't require a concept of objects at all.

>or are broken occasionally
If by "occasionally" you mean "routinely, and necessarily every time a real program needs to be made".

>>60991916
>it's a matter of being able to change the implementation without affecting the public interface to it.
You're still just munging a data structure using a function. There is no observable behavior. Your object just represents a POD struct. It's the same as the struct example.

>updating and reading back that data is the observable behavior
For the umpteenth time, this depends on the level of abstraction you choose to look at it from, and the level of abstraction where this argument is valid is altogether irrelevant to this discussion.

>>60991949
You have data structures you don't want to fiddle with all the members directly, so you encapsulate the whole thing and access what you need through functions that are bound to the structure.

No, it's not beneficial to put everything as a class. And yes, this Java fad to move all of your main into a class encapsulating your whole program deserves death penalty.

>>60992032
>There is no observable behavior.
The X or Y elements being updated is certainly an observable effect.
>Your object just represents a POD struct.
Not in that it has a hidden "a" member.
>You're still just munging a data structure using a function.
The functions that are available to mung that data constitute the public interface.

>this depends on the level of abstraction you choose to look at it from
It is more than just a matter of point-of-view. It is a matter of defining the public interface separately from the implementation. As a user of the Coord class, you cannot access or see the "a" member.

File: functional languages compared.gif (195KB, 2984x915px) Image search: [Google]

195KB, 2984x915px

>>60991278
You're not wrong, but there is an argument to be made. Preface: OO isn't all-evil and I think objects do have a place just not as they exist now. I'm open to discussion and debate over anything I say here.

- Complaint 1
OO languages seem to try and separate data and functions out into different units, but really they are, and they really should be treated as the same things. Functions and data are one in the same, and this is broken down to the syntax even of most modern languages.

How things *should* be:
> f x = [function body]
> g = [value]
No special syntax, no distinction.

In Haskell's glory

value :: Integer
value = 6

add :: Integer -> Integer -> Integer
add x y =  x + y

Notice how there's no difference? The type annotations are optional so ignore them, but in haskell these values are just defining a function with a constant return value and no params, simple.

Scala gets it wrong

val immutableValue = 1
var mutableValue = 2
def function() = ???

Even Clojure, a lisp(!) gets it wrong

(defn add [x & y]
    (+ x y))

(def value (add 1 2))

In short, in a perfect language all expressions should be evaluated as functions, and functions with a constant return are by-definition immutable values, perfect. This is better for syntax, as it'd be the same as a function with no params, and better for code.

- Complaint 2
Objects hide state, and every good programmer knows that state is literally hitler. Unfortunately, the world is full of state and it's pretty much required.

OO languages tend to hide state from the programmer, forcing you to use access functions to see and interact with it.
Declarative languages say there is no state.
C says state-visibility is determined by scope

The best approach is pretty much what Monads do, they wrap around state so we can keep on programming like state doesn't matter, but they give us the means to freely access if we so desire.

idkeepgoingbutnospacetotypemore
ignoretypos

>>60991961
>They are disregarded because they don't require a concept of objects at all.
but the interplay of those arguments are the essence of oop

>If by "occasionally" you mean "routinely, and necessarily every time a real program needs to be made".
if everybody agrees on how it's rutinely broken, and it works well, I don't see a problem with that.
You can emulate non-oop with oop

>>60992209
>being THIS buttmad

>>60992173
I disagree with you, but I honestly don't care about debating this specific example anymore because it doesn't prove or disprove anything. The point still stands that unless your object is specifically modeling data access and nothing more, getters and setters usually indicate breakage of encapsulation.

>>60992209
>Functions and data are one in the same
That's not true, though. On the hardware level, functions are thing that you use a call instruction on, where as data are things that you use a read instruction on.

>>60992273
>The point still stands that unless your object is specifically modeling data access and nothing more, getters and setters usually indicate breakage of encapsulation.
>unless
Why is this case so completely irrelevant, though? Why do you not need to model data?

>>60992210
>the interplay of those arguments are the essence of oop
No combination of those "arguments" requires the concept of objects. If they are the essence of OOP, then the essence of Object Oriented Programming has nothing to do with objects.

>if everybody agrees on how it's rutinely broken, and it works well, I don't see a problem with that.
But everybody does not agree (as you can see in this very thread), and it doesn't work well. In fact, it produces some of the lowest quality code I've had the misfortune of dealing with.

>>60992209
>Functions and data are one in the same
gotta love that javascript

>>60992284

The instructions are themselves data.

>>60992328
>first class functions are exclusive to Javascript

>>60992339
Yes, but you virtually never have a need to do explicit reads or writes to the code section, and the instruction pointer is kinda relevant.

>>60992304
>Why is this case so completely irrelevant, though?
Because it doesn't disprove the fact that OOP programmers are routinely forced to break encapsulation. Most of the uses of getters and setters involve objects that are supposed to model something other than a data store.

>>60992318
>In fact, it produces some of the lowest quality code I've had the misfortune of dealing with
no the low level of skill required to produce working code with it and somewhat understanding how to make working code with it is the reason for the low quality code

>>60992358
>Most of the uses of getters and setters involve objects that are supposed to model something other than a data store.
>Most
Citation needed. Even among objects that represent what you would perhaps approve as more "proper" behaviors, there is often still ancillary data attached, which is what most setters aim at setting. Random example in Java: Throwable.initCause().

>>60992284
On the hardware-level, this is true I suppose. However, my argument is that to *the programmer* there should be no distinction.

>>60992371
>no the low level of skill required to produce working code with it and somewhat understanding how to make working code with it is the reason for the low quality code
No, the attempt to model conceptual entities as objects produces low quality code, because in 9 out of 10 cases it's inappropriate.

>>60992397
>Citation needed
So you're just going to engage in full blown denial now, and claim that most objects either represent data stores or don't use getters and setters? Fair enough. I don't have any research on hand to prove otherwise, but thanks for the conversation.

>>60992402
That's a completely domain-dependent statement.

CODE REUSE
O
D
E

R
E
U
S
E

Anything else you get told about OOP is an abstracted lie.

>>60992402
>However, my argument is that to *the programmer* there should be no distinction.
The ultimate goal of the programmer is always to manipulate the hardware. Using a high-level language that completely isolates you from the hardware always makes it more difficult and complex to reason about the performance implications of your program constructs.

Also, if you're isolating yourself completely from the hardware, the paradigm and ideology you choose to program by becomes completely arbitrary. If you don't have the hardware to go by, then there's no standard by which you can objectively say that "functions and data should be one and the same". Without any hardware to relate to, that's just an assertion.
Sure, it may fit your personal ideology better, and that's meaningful and good, but it is subjective and you can't count on other people to share that ideology just because.

>>60992447
how often have you reused OOP code?

>>60992444
>claim that most objects either represent data stores or don't use getters and setters?
No, I claimed that many object have a mixture of the two. As I said, even if you have an object that wouldn't require and getters or setters in its core idea, it may still be relevant to attach ancillary data to it.

>>60992404
it's a one size fits all thing.
Is OOP the best tool for every job? No. Is it the best tool for some jobs? Yes. Is it a tool that you can do all jobs with? Yes. Same goes for functional programming or any other paradigm.
OOP may not be the best for the job, but it is probably good enough.

>>60992458
You make a strong, convincing argument. I still believe in what I said, and someone more prepared than I could probably argue for it, but with this you have a point.

As a sidenote, at this point I'd bet most code is completely isolated from the hardware by at least one layer though. JVM Code Condom^TM

>>60992476
I have a simple question for you: suppose you're making a simple Mario clone in Java. Would you model Mario as an object? If so, what data members (just the most immediately necessary ones you can think of) would it have? If not, why wouldn't you have a Mario object?

>>60992549
>JVM Code Condom^TM
One core point of the JVM is that it indeed is fairly low-level, however. You basically deal directly with the processor's native numerical data type and pointers. The JVM just only gives you access to operations which guarantee the preservation of the basic structure of the data so as to avoid the very worst examples of type confusion. This is the basic reasons why Java, among relatively high-level languages, can be implemented so efficiently as to sometimes rival C code.

That being said, though, I don't particularly like Java and would much rather write C code, I'm just saying that likeness of abstraction layers to the underlying thing they abstract does matter for performance.

>>60992639
Going by the textbook, it seems reasonable to say that Mario should probably inherit from some more general game-object class, and have such data as position, velocity and sundry states for animations and groundedness &c. Please expand on why you're asking.

>>60988829
OOP is a methodical way to structure your program.
In a lot of situations, it makes sense as the real world is often easy to model with objects.
As to the technical differences between foo(obj, arg) and obj.foo(arg), there is almost none.
With objects, you store the state in the object.

A simple example is an image.
If you were to create an image library, several things needs to be a part of the object, (resolution, pixel values etc).
If you wanted to make it object oriented, you add functions that is directly relevant for the image (loading an image, resizing the image, manipulating pixels, writing the image to a file, stuff etc).
Functions that uses the image would not be inside the class, like applying a filter and other forms of processing.

>>60992807
>Going by the textbook
>inherit from some more general game-object class
>position, velocity and sundry states for animations and groundedness &c
Okay. I agree with you that this is the textbook OOP way of going about it.
Now, why does Mario have position and velocity data members?

>>60991648
that doesn't "break" encapsulation

>>60992850
>In a lot of situations, it makes sense as the real world is often easy to model with objects.
Does this apply in this case: >>60992639 ?

>>60992883
>that doesn't "break" encapsulation
It does, and the post explains why. Simply ignoring it and restarting your assertion without addressing the argument doesn't help anything.

>>60992879
Because that's part of the intrinsic description of Mario? The final result of a Mario program is a picture where Mario appears visually at a particular location. Analogously for velocity.

>>60992549
>I still believe in what I said, and someone more prepared than I could probably argue for it
If that is so, then please present an underlying reason for why data and functions should be one and the same regardless of hardware. In >>60992209 you basically just asserted that was the case, without arguing for why.

>>60992913
no, your explanation doesn't make any sense. All you're doing is setting field values, not interacting with any logic behind them.

>>60992930
>Because that's part of the intrinsic description of Mario?
So it's part of the conceptual entity of Mario, which the Mario object tries to model, right?

>>60992975
Pretty much, yes.

File: (you).jpg (70KB, 488x393px) Image search: [Google]

70KB, 488x393px

>>60992959
>your explanation doesn't make any sense
>All you're doing is setting field values, not interacting with any logic behind them.
So you didn't understand what I said, claim that it doesn't make sense, and then you come out with gems like "interacting with any logic behind X". Guess how I know that this isn't worth engaging with.

>>60992975
not him
it would probably be part of the conceptual class the mario inherits from

>>60992999
Does the Mario class also try to model a data store in addition to modeling the conceptual entity of Mario?

>>60993008
>it would probably be part of the conceptual class the mario inherits from
Yes, but the conceptual entity of Mario is based on the conceptual entity of a Game Object, so it's fine, if not 100% precise.

>>60992903
games are always a bit different.

I haven't looked too much at the mario implementation, but I think you would want to keep track of the current speed, position, the evolution stage, dimensions of the bounding box, jump height and the sprites.

>>60993031
Not just in the most basic Mario concept you could imagine. However, imagine that the game lets the player name Mario. In that case, Mario's name could be considered such an ancillary data field.

>>60993007
man you're stupid.

>>60993059
>I think you would want to keep track of the current speed, position, the evolution stage, dimensions of the bounding box, jump height and the sprites.
Fair enough. Then follow the short exchange stating with >>60992879 and tell me your take on it. I think it applies equally well to you.

>>60993007
is your point that objects shouldn't be allowed to have properties that can be changed from the outside?
It may break your ideal of what an object is, but in the end an object is supposed to be useful. Changing values of objects directly is useful as fuck

>>60993064
>Not just in the most basic Mario concept you could imagine.
Let's stick to the Mario concept you've described. Does it try to model a data store? Yes or no?

>>60988896
>>60989233

those are just a retard's higher order function

https://en.wikipedia.org/wiki/Higher-order_function

>>60993183

objects are more useful than closures
deal with it functionaltard

>>60993124
Not wholly, he obviously does other things as well, but the part of the Mario class that stores a name seems to model a data store, yes.

>>60993196
>objects are more useful than closures
You can trivially implement objects using closures.

>>60993183
... no? I don't even see the connection.

>>60993202
>do something you will certainly not like doing

>>60993202
I'm having trouble understanding, could you give a quick example?

>>60993202

You can trivially implement closures using objects.

>>60993198
>but the part of the Mario class that stores a name seems to model a data store, yes.
But we're sticking to the nameless Mario described by you initially. Does it try to model a data store? I just want an unambiguous yes/no answer to this question. I'm not going to move the goalpost.

>>60993227
>Does it try to model a data store?
No, but so what? I didn't say that every single object tries to model a data store, and therefore I tried to modify the example to one that does, since that's what I at least thought we were trying to discuss.

>>60993204

objects and closures are fundamentally related
The methods you can ivoke on an object are analogous to applications of that function - its member variables are equivalent to the environment that has been closed over.

>>60993262
>closures
You weren't talking about closures but about higher-level functions, though. Or are you so retarded that you think they are the same thing?

>>60993218
https://repl.it/IuGv
Ignore the fact that 'plainOldStruct' actually uses a javascript "object". It could just as well be a lisp plist.

>>60993302

Thought you were replying to this guy. >>60993202 My mistake.

>>60993202
>You can trivially implement objects using closures.
You can, but it would be inefficient as each function enclosing the same data would have its own separate representation of that closure, whereas several methods in the same class explicitly share the same closure.

>>60993221
Also this. There's nothing to say that either underlies the other. If anything, implementing closures using object isn't less efficient than the other way around.

>>60993357
Doesn't change the fact that higher-level functions have nothing with encapsulation, inheritance or polymorphism.

>>60993380

Pretty much.

>>60993257
>No, but so what?
If the answer is "no", then you concede that, for instance, the position property is definitely part of the Mario model, not part of some kind of data store. Would making it public break encapsulation?

>>60993380
>higher-level functions have nothing with encapsulation, inheritance or polymorphism.
Well, my example shows how higher level functions can be used to implement encapsulation. You're right that the other two have nothing to do with higher-order functions, but polymorphism (in the general sense) has nothing to do with OOP, and I'm really not convinced about the usefulness of inheritance.

>>60993405
>Would making it public break encapsulation?
Depends on what game mechanics you're trying to define. It is quite conceivable that enemies need to know Mario's position eg. in order to walk towards him. It is also conceivable that you want to implement eg. teleports in the levels, in which case they would want to set his position.

>>60993454
>Well, my example shows how higher level functions can be used to implement encapsulation.
Aren't you talking about closures again now?

>>60993454
higher-order*

>>60993457
>Depends on what game mechanics you're trying to define.
No, it actually doesn't depend on it in any way.

>>60993496
I just explained why it does.

>>60993465
>Aren't you talking about closures again now?
D'oh. Yes, I was. My bad.

>>60993513
In that case, see >>60993358.

>>60993506
>I just explained why it does.
Your explanation is a complete non-sequitur. You just saw what's coming next and tried a stinky little evasion manouver.

>>60993529
No, I'm saying that the game mechanics you want to implement affects the very definition of Mario. If you want a Mario that can be teleported, then obviously it is part of his public interface that his position can be set.

>>60993529
>>60993555
Conversely, if you don't want a Mario that can be teleported, then he probably wouldn't have a setPosition.

>>60993358
>each function enclosing the same data would have its own separate representation of that closure
You're talking about compiler implementation details here. There's nothing stopping the compiler from generating the same kind of code it would have generated for a class.

>>60988829
Objects can be thought of as state plus behavior. For example, a timer. You can start it, stop it, and have something happen when it expires. It is an useful abstraction, since you could program against a generic timer interface and not care how it is implemented by the OS. This also makes code reusable.

>>60993555
>>60993572
More non-sequiturs. Exposing Mario's position and velocity fields, either directly or through getters and setters, breaks encapsulation because you are exposing part of the internals of your model so that external code could implement behaviors like falling or not passing through other objects.

>>60993654
If you're doing it through getters and setters, it does not break encapsulation.

>>60993665
As far as I'm concerned, I've made my case and there's nothing you can do about it.

>>60993654
>breaks encapsulation because you are exposing part of the internals
My very point is that defining the game mechanics that way has the effect of making the position not be an internal implementation detail.

If, contrariwise, you want it to be an internal implementation detail that shouldn't be exposed, then you cannot implement such game behaviors.

>>60993604
True enough. Nevertheless, there's nothing saying that closures underlie objects or the other way around. They're basically just two different ways to think of the same thing.

File: Screen Shot 2017-06-20 at 2.18.02 PM.png (362KB, 1490x1082px) Image search: [Google]

362KB, 1490x1082px

>>60993680
fine keep being stupid.

Here's an approved answer about it from SO.

>>60993692
Letting external code modify the position, either directly or through setters, breaks encapsulation. This is not up for debate.

>>60993708
Why? If Mario's position is considered a public detail, why does it break encapsulation to access it?

>>60993708
If you have external code modify position by calling the appropriate setter, then it does not break encapsulation.

Having it set as a public variable that any other object can come by and modify on the other hand... but a simple setter does not break encapsulation.

>>60993698
>there's nothing saying that closures underlie objects or the other way around
If you have a language that supports closures and you want objects, you can make them relatively easily. If you have a language that supports objects but not closures, you're stuck with manually creating classes every time you want a closure. Emulating closures using objects is more cumbersome than the reverse.

>>60993727
>>60993755
Either it breaks encapsulation, or "encapsulation" doesn't actually mean anything. "It's not really breaking encapsulation if I can't avoid breaking it" is not a valid argument.

>>60993792
>you're stuck with manually creating classes every time you want a closure
That's just an implementation detail as well. You could easily have the compiler construct classes for closures, as illustrated by Java lambda expresssions.

>>60993817
Encapsulation, again, is separating internal implementation details from the public interface of a piece of code. If Mario's position is part of the public interface, then, by definition, it does not break encapsulation to access it.

Breaking encapsulation would be accessing the internal hash bucket array of a "Map" data type.

>>60993817
no. Encapsulation doesn't mean absolutely no assess to internal state, that makes no sense, just that access between objects is structured and organized.

>>60993821
>That's just an implementation detail as well.
It isn't. You have to support closures on the language level first. You don't have to support objects on the language level to have them if you already have closures.

>>60993858
>Encapsulation, again, is separating internal implementation details from the public interface of a piece of code
So you're going with the "doesn't mean anything" position. Okay.

>>60993899
No, it means exactly what I said: Separating internal implementation details from the public interface.

>>60993880
Conversely, if you support objects on the language level, then you don't have to support closures on the language level. Again, as demonstrated by Java lambda expressions.

>>60993899
>i don't understand so that must mean it doesn't mean anything!

lol

>>60993934
>you don't have to support closures on the language level
>as demonstrated by Java lambda expressions

>>60993914
>>60993934
>>60993943
Alright, folks. I don't think we're going to get much further given the level of sheer absurdity we've reached here. Thanks for demonstrating everything that's wrong with OOP programmers.

>>60993899
>desperately clinging to a long lost argument instead of just admitting you were wrong
never change, internet discussions. so many man-hours wasted. even wanking or laying down and staring at the ceiling are more productive than this shit.

>>60993971
>desperately clinging to a lost argument by claiming that exposing internal object state doesn't break encapsulation if you tell yourself it's "public"

>>60993969
stay ignorant i guess.

>>60993953
Well, I meant at the JVM level, but if you truly meant at the language level, then you'd also want to implement objects on the language level even if you implement them with closures, because manipulating closures everywhere you want objects would be just the same kind of pain that you claim that it is to manipulate classes in every place you want a closure.

File: tfw-this-shit-again.jpg (6KB, 139x150px) Image search: [Google]

6KB, 139x150px

>>60994005
Keep producing low-quality Java code, I guess. I'm glad my career has progressed beyond having to work with OOP programmers and their code.

>>60993995
>exposing internal object state doesn't break encapsulation if you tell yourself it's "public"

no, this is literally what getters and setters avoid

>>60993969
>lol i realized i was wrong so let's just stop arguing here all the while pretending that i'm superior to you
I'm not even an OOP advocate, and always write plain C code wherever I can. All you're doing is twisting definitions to demonstrate that they're wrong.

>>60994045
eating tendies in your room is hardly what I call a "career"

>>60994060
>>60994055
You're indisputably wrong. It's not up for debate, and you're not dragging me back into one.

>>60994075
nope :)

>>60994074
>projection
Even just your writing style makes it obvious. Anyway, not wasting any more time on pure shitposting.

>>60994075
>You're indisputably wrong.
By what standard?

>>60994087
>>60994087
>Anyway, not wasting any more time on pure shitposting.
great, thanks.

File: shitpost-3.jpg (89KB, 1280x720px) Image search: [Google]

89KB, 1280x720px

>>60994087
>Anyway, not wasting any more time on pure shitposting.
Happy to see that you're admitting that that's what you've been doing all this time.

>>60994089
>By what standard?
By the very definition of encapsulation. Your object relies of external code to implement some of its behaviors, and is therefore no longer self-contained.

>>60994087
So we've lost the single person holding your position while everyone else disagrees with good arguments.
SAD

>>60994117
>Your object relies of external code to implement some of its behaviors, and is therefore no longer self-contained.
But that's exactly what it doesn't do. It is the behavior of a teleporter to move Mario around, and it uses Mario's public interface to do so.

>>60994117
>>60994147
I mean, conversely, please explain, then, how you'd implement teleporters without breaking encapsulation?

>>60994117
you don't know what you're talking about.

>>60994117
>objects are not allowed to interact with other objects
Good that your career has ascended beyond oop. Hopefully out of programming as a whole

>>60994160
getters and setters

boom

>>60994160
He can't and that's why oop is bad hmkay?

>>60994183
I meant without breaking his definition of encapsulation.

>>60994195
I bet he'd want the object to access all the games code and logic so the object can calculate the position it should be teleported to without having it be told from the outside, because otherwise it's clearly no true oop

>>60994117
You're literally just drawing up a useless strawman of encapsulation and arguing that it's useless.

>>60992209
Clojure's defn is just a macro that desugars into def with a lambda argument.

>>60994195
I know, but he's just an idiot. His idea of OOP is bloated monolithic siloed God classes, and I highly doubt he's coded a single line of OOP in his entire life

>>60989754
>paradigm right for the job
So, which are the paradigms used besides OO and functional?

>>60989754
>OOP
>for fast

what?

Basically what this OP is getting at is the fact that programming is filled with a ton of fucking stupid buzzwords that mean nothing unlike math where things are perfectly defined.

What is an "object" with a rigorous definition? If you ran into an object how would you know it is an object? How can you test if it is an object? Programming is fucking insane because definitions and names are just jargon and not actually real.

>>60994254
Purely imperative is fairly common for some classes of programs.

>>60994147
The behavior of an object defines how its state changes in response to messages. It's not so much your teleport example that causes a problem (you could easily have Mario respond appropriately to a "teleport" message detailing where to go) but more complex interactions like collisions with other objects, where the response is effectively decided by an external piece of code rather than the object itself, and the object has to comply with this external invariant imposed on it to function correctly in the context of the rest of the application.

>>60994290
C++ is among the languages with the fastest and most efficient implementations, in case you haven't noticed. Java is also pretty up there.

>>60994293
>What is an "object" with a rigorous definition?

a collection of methods and fields... Do you have any idea what you're talking about?

>>60994334
Oh, sorry, how embarrassing. An object is an instance of a class, which is a collection of methods and fields.

>>60994310
Now this I agree with. As I said elsewhere, I'm not actually an OOP advocate at all, and your example is exactly the kind of thing that OOP is the worst at handling.

>>60994322

Try to do OOP in C++ with virtual and your performance gets halved, easily.
Otherwise you're just writing procedural code with different syntax.

>>60994293
>programming is filled with a ton of fucking stupid buzzwords that mean nothing unlike math where things are perfectly defined
>What is an "object" with a rigorous definition? If you ran into an object how would you know it is an object? How can you test if it is an object?
Very much this. Even if you seemingly nail one of them down on something (e.g. "objects should be encapsulated") they'll just rely on a meaningless non-definition of "encapsulation".

>>60994310
>the response is effectively decided by an external piece of code rather than the object itself

nothing wrong with this, and you can easily have the update be handled within the class

>>60994351
Glad at least someone in this thread understands what I'm talking about.

>>60994385
you don't even know what you're talking about.

>>60994385
Though, it should be said that eg. CLOS is far better at handling it, and CLOS claims to be about OOP. Of course, it's far from "orthodox" OOP.

>>60994375
>nothing wrong with this
There is something wrong with this, because it should be an object behavior (since it imposes invariants on the of the object), but making it so is a big hassle, so you effectively handle this behavior externally and leave the object with just a "setPosition" stub that does nothing but to comply with an external imposition.

>>60994358
>Try to do OOP in C++ with virtual
OOP doesn't necessarily imply virtual methods. Also, if you need virtual methods for something, it's not like you'd get greater performance using any other method. Indirect calls have the same performance regardless of what language construct results in them.

>>60994423
invariants on the state of*

>>60994423
How is collision detection an invariant

>>60994400
>CLOS is far better at handling it
Perhaps, but the hassle of implementing interactions between objects while maintaining encapsulation fundamentally grows with the complexity of the interactions, regardless of what tools you have to mitigate the issue.

>>60994462
>How is collision detection an invariant
For the program to work correctly, the position of Mario should never be inside a brick wall, for instance. How is that less of an invariant than the requirement that a name field not be null?

>>60994350
Ok so what is a collection and how do you define a method and a field? How many methods and fields can be contained in a collection? You are just hiding your ignorance with buzzwords and when asked you just throw some more out. How do you know something is a field? What actions can you perform on a field, what about a method how do decide what exactly a method constitutes?

>>60994549
It's probably possible to address those questions rigorously (I'm not going to try, though), however, at this point it seems like we can't even agree on something more basic, like a meaningful definition of encapsulation.

>>60994549
How about you check out any entry-level textbook on OOP for those definitions? They aren't exactly contested by anyone.

>>60994829
> check out any entry-level textbook on OOP for those definitions
He's talking about a while different level of rigor that I don't expect. I'll settle for much less, but you can't seem to provide even that. How do you define encapsulation?

>>60994481
The point being that CLOS doesn't have the same kind of rigorous idea about encapsulation that orthodox OOP has. Thanks to methods, generic functions and classes being decoupled from each other, rather than strictly coupled as in orthodox OOP, it's easy and uncontroversial to write methods that live "between classes".

>>60994254
didn't expect to get a (You) this late.
But simply put I guess that I tend also to use a classic imperative coding style.
But I sprinkle my code with object if they are a clear advantage (usually for programs that have a visual "gamey" driven nature), while I steer towards a functional approach when I am working on big homogeneous chunks of data.

My main gripe is the usual fever that invest some programmers/theorists that usually boils down to "hide the state", that's literally retarded since programs are instructions acting on a state, no matter what wankery you put down. And in a way I don't give a shit, but teaching absurd limitations and coding style as absolute just degrade the overall program quality, since programmers instead of thinking what implementation to use rely on the rule they are given, and you end up with objects that hardly represent objects and make your code hard to follow logically. Worse than goto

>>60994322
>Java
>fast and efficient
What universe do you live in anon?

>>60994869
>How do you define encapsulation?
From Wikipedia:
>In programming languages, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof:
>A language mechanism for restricting direct access to some of the object's components.
>A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.
I don't mind this definition.

>>60994900
The real world, Anon. The fact that many Java applications are slow have nothing with the JVM to do, but with the fact that many Java programmers suck. It's entirely possible to write Java programs that are just as fast as a corresponding C program. Hotspot isn't quite at the level of GCC, but it's not at all far from it.

>39 posters

>>60994900

The real world. The only languages that are faster than Java are compiled to native code, and nobody does that any more.

>>60994934
Java is compiled to native code, though?

>>60994549
Mathematical rigour has its place, this isn't one of them. We aren't using classes with logical connectives or anything similarly pedantic.

File: wat-2.png (362KB, 700x700px) Image search: [Google]

362KB, 700x700px

>>60994934
>nobody uses C or C++ anymore

>>60994927
Is that supposed to mean something?

>>60994956

Java is compiled to bytecode.

>>60994964

C and C++ have been on the decline for general purpose applications development for years.

>>60994890
Well said.

>this late
It's daylight here.

>>60994980
>Java is compiled to bytecode.
which is then compiled to native code and executed

>>60994980
>Java is compiled to bytecode.
Only inasmuch as C is compiled to LLVM IR by Clang. Bytecode is just an IR.

>>60994993
I meant I posted that hours ago

>>60989363
the idea is just that to interact with an object (get data, set data, perform operation x, etc.) you can have a public interface that's independent of the private implementation. So you could have say multiple variables that describe a person's age in years, months, days, seconds, etc and one that gives their absolute age in years, months, days and so on, but internally you could store each individually as a number, are you could store their total age in seconds, or the time of their birth, and use getters and setters to return the correct value for each variable based on an internal function (dividing the seconds to get years, etc.). Additionally, you can have functions as members that can change. You foo.bar() might always take an int and return a string, but you could set the function to any arbitrary function you want, perhaps depending on run time conditions, and it'd work the same way.

>>60995002

Why even have a distinction then? Every language needs to be interpreted or recompiled at some point before or during execution. By that logic every language that exists can be considered to be compiled to native code.

>>60995023
don't worry, he's just autistic.

>>60994980
>C and C++ have been on the decline for general purpose applications development for years.
That is probably more a reflection of the fact that there are more languages to choose from. There are still tons of new projects being started in C and C++. Either way, they are very definitely far from dead, so many people are certainly doing that every day.

Also, Rust and Go are also compiled directly to native code, so it's not just "the old languages".

>>60995003

Your C binaries aren't LLVM IR.

>>60995027
>Why even have a distinction then?
Simply to have a well-defined transfer form for code. Basically the same as LLVM IR.

>>60995027
>By that logic every language that exists can be considered to be compiled to native code.
No, there are tons of purely interpreted languages, like Python.

>>60994881
>CLOS doesn't have the same kind of rigorous idea about encapsulation that orthodox OOP has
Judging by this thread, it sounds like the "orthodox OOP" idea of encapsulation is that as long as external code is munging your object's internal state through a public interface, you have perfect encapsulation, even if you're effectively implementing object behaviors and enforcing object invariants outside of the object itself.

>methods that live "between classes".
I assume you're taking about multimethods. If so, I don't really see where you're going with this. What is the CLOS idea of encapsulation, according to you?

>>60995045
right it's the meme languages, too

>>60995068

How do you suppose the python is executed? Somewhere down the pipeline it needs to turn into the assembly for your machine.

>>60995072
Encapsulation is about *controlling* access, not denying it outright.

>>60995026
>the idea is just that to interact with an object (get data, set data, perform operation x, etc.) you can have a public interface that's independent of the private implementation.
Are you saying that working with a pile of data through an interface instead of doing it directly in and of itself constitutes "encapsulation" and makes something into an object?

>>60995116
>Encapsulation is about *controlling* access, not denying it outright.
Can you or anyone define what "encapsulation" means?

>>60995117
nice strawman, nobody's saying having a getter and setter for every field is good encapsulation

>>60995072
>as long as external code is munging your object's internal state through a public interface, you have perfect encapsulation
By the definition that is true, but it's not really meaningful when more and more external requirements are added onto that interface that isn't really related to the core concept of what is being modeled. At some point along that line, encapsulation becomes a pointless burden.

>I assume you're taking about multimethods. If so, I don't really see where you're going with this. What is the CLOS idea of encapsulation, according to you?
CLOS doesn't really focus on encapsulation per se, so CLOS' idea of encapsulation isn't really that important. What matters, however, is that you can have a method that properly "belongs to" two classes at once, and there isn't really anything conceptually strange about such a method touching the internal state of both of those objects.

>>60995140
>nobody's saying having a getter and setter for every field is good encapsulation
Nobody is saying anything. You are fundamentally incapable of defining your own terminology.

>>60995139
can you?

>>60995086
>Somewhere down the pipeline it needs to turn into the assembly for your machine.
The Python code itself is never turned into assembly. There's a native program that walks through the Python bytecode instruction and emulates their effects, but the Python bytecode itself is never turned into assembly.

>>60995156
lol nice memepost

>>60995170

Early JVMs interpreted Java bytecode in the same fashion, with a glorified switch statement.

But the truth is, that doesn't happen to Java any more. The bytecode gets dynamically recompiled and executed as native code at runtime. Which, not coincidentally, also happens to modern Python.

>>60995205
>Early JVMs interpreted Java bytecode in the same fashion, with a glorified switch statement.
I know, but that's along time ago. Obviously, I'm aware that when discussing these things it's important to distinguish between language and implementation, but Hotspot is the JVM implementation that rules supreme, so it goes without saying when talking about Java that you mean Hotspot.

>Which, not coincidentally, also happens to modern Python.
Except it doesn't. CPython literally has a gian switch statement for each bytecode instruction.

>>60995148
>By the definition that is true, but it's not really meaningful when [real life stuff inevitably happens]
I agree that such a definition quickly becomes meaningless, and I don't understand the point of having such a definition and relying on it to explain the essence of an object.

>CLOS doesn't really focus on encapsulation per se, so CLOS' idea of encapsulation isn't really that important.
Well, what is the essence of a CLOS object, then?

>>60995233

So use PyPy. PyPy uses JIT just like Java does.
Interpreter vs dynarec is an implementation detail.

>>60995260

>just like Java does.
I mean Hotspot, of course.

>>60995158
>>60995176
Do you consider encapsulation to be the essence of an object? If so, define encapsulation objectively. This is literally all I'm asking.

>>60995255
>I don't understand the point of having such a definition and relying on it to explain the essence of an object.
I agree to some extent, but there are many classes that the concept does apply to rather cleanly and is at least slightly meaningful.
>Well, what is the essence of a CLOS object, then?
I'm not sure if there's any particular ideology underlying CLOS. I wouldn't be surprised if there is, since it was influenced by many of the same people who made Smalltalk and other early OOP implementations, but I don't know.
To me, CLOS objects are simply a type tag and a way to look up members in a multiple-inheritance structs.

>>60995289
>Do you consider encapsulation to be the essence of an object?

What does that even mean? Encapsulation is a feature of OOP, i'll say that much...

>>60995260
Yes, but just like how literally everyone running Java uses Hotspot, literally everyone running Python uses CPython..

But sure, I agree it's about more than just whether there is being native code being generated. "Threaded Code" (using the classical definition, not talking about multithreading) can't really be meaningfully be said to be "natively compiled" either, even though technically native code is being generated that corresponds to the source program. And for many programs (those not just involving Fortran like numeric code), PyPy's generated code isn't much better than threaded code. As opposed to Hotspot, which truly generates efficient native code.

>>60989805
It's just a way of thinking about data. People that try to coerce everything into an OOP model are idiots, and their mantra is horseshit. Say in C you had a program that needed to interact with databases, and you needed it to work with multiple types of databases, so you couldn't just use one library throughout your code and be done with it. An OOP approach would be define a common interface you need throughout your program (i.e. get address, age, etc. from name/ID lookup, delete actions, etc. whatever) and define a set of functions, so you'd have foo() that took a name and returned an array of entries with that name, or bar() that would delete an entry with an ID, number or whatever you need to do with the data. Now, the problem comes when you want to support multiple formats, because foo() can only work for one format, or you have to pass the type it'll be working on, or define multiple foo()s for every supported type and choose the correct one while you program, etc. OOP looks at it and says, we'll wrap each database in a struct that contains foo(), bar(), etc., a reference to the database, and some meta about it (name, type, etc.). Then you'd have a constructor function, so that you can create a new database object, which would presumable take a reference to the database, it's name, and it's type, and then would create a an instance of the struct with that information, and based on the type would assign foo, bar, etc. to the appropriate functions for that particular data type, and return a pointer to it. Then you'd have an object with a universal interface foo and bar, that worked with a variety implementations hidden from the programmer working with databases. That's OOP. Retards take it to an extreme and coerce everything into such a model, but anytime you abstract the implementation of data manipulation away behind a universal interface, you're doing OOP.

>>60989961
Your problem is you think OOP is specific to certain languages and impossible in others. That is absolutely not the case. It is simply a way of modeling data in a program, and many instances where structs are popularly used can be considered OOP models.

>>60995351

I think we got sidetracked. There, at the very least, is a respectable difference between compiling to native code ahead of time like C, C++, Rust, Go, D and leaving translation to runtime like Java or C#.

With that distinction in mind, Java performs well.

>>60995316
>there are many classes that the concept does apply to rather cleanly and is at least slightly meaningful
I agree, but then there are many cases (perhaps even most, if we're talking about complex objects) where it only applies in the trivial (and rather meaningless) sense to the object as a whole, or only applies meaningfully to certain aspects of the object.

>To me, CLOS objects are simply a type tag and a way to look up members in a multiple-inheritance structs.
So basically, to you they are what CLOS defines them to be. Fair enough.

>>60995473
>There, at the very least, is a respectable difference between compiling to native code ahead of time like C, C++, Rust, Go, D and leaving translation to runtime like Java or C#.
There is, but also in terms of the quality of the generated code, there is a much, much more respectable different between Java and Python than between Java and C.

>>60995322
>What does that even mean?
I don't know. Other people maintain that objects are all about encapsulation. What do you think objects are all about?

>>60995509
what's a "complex object"?

>>60995519

You can thank both the Java language specification and bytecode specification for that. And the quality of the JVM itself.

>>60995530
objects are instantiations of classes...

>>60995509
>there are many cases (perhaps even most, if we're talking about complex objects) where it only applies in the trivial (and rather meaningless) sense to the object as a whole
I don't wholly disagree, but I do think there's a respectable number of classes in eg. the Java standard library where it applies somewhat properly, like the ADT implementations and such.

>So basically, to you they are what CLOS defines them to be. Fair enough.
Well, I think it's also fair to say that CLOS is much less ideological about how it wants to be used than eg. Java is. Java really goes out of its way to make the programmer respect OOP orthodoxy, whereas CLOS tried to be more like a tool that you can use however you want to. Much like C.