Yes, it's this thread again

Yes, it's this thread again.
Can any of you OOP experts define what an object is?
For bonus points, I challenge you to provide a definition that passes the C struct test:
It should be impossible to take just any random procedural C program and mechanically transform its structs into objects in a meaningful sense.
If you think your definition passes the C struct test, you must prove it relying only on your original definition (no ad hoc excuses and modifications).

No takers?

An entity that provides a set of functions that operate within the context of its lexically scoped data.

>An entity that provides a set of functions that operate within the context of its lexically scoped data.
Fair enough. No bonus points, though.

Traditionally, it's an instantiation of a class. Some languages are different. Getters and Setters do not break encapsulation. Love you.

>Traditionally, it's an instantiation of a class
That doesn't answer the question in a general or useful sense. (what's a "class"?)

>Getters and Setters do not break encapsulation.
Opinion discarded.

>That doesn't answer the question in a general or useful sense. (what's a "class"?)
you asked what an object was, not a class...

>Opinion discarded.
why

>you asked what an object was, not a class...
Your definition relies entirely on another term that you have not defined. It doesn't communicate much useful information on its own.

>why
Because it's an argument about semantics that this thread is specifically trying to side-step.

An object is an instance of a class.

>An object is an instance of a class.
So Javascript and Self objects aren't objects to you?

>Your definition relies entirely on another term that you have not defined
no, the definition of a class is pretty commonly agreed upon. I didn't say class specifically because I knew you'd say , so.

>Your definition relies entirely on another term that you have not defined.
yeah, like an object :)

>It should be impossible to take just any random procedural C program and mechanically transform its structs into objects in a meaningful sense.

why

>the definition of a class is pretty commonly agreed upon
You know what? Sure. You technically did provide a definition. The way you're going about it doesn't facilitate any useful discussion, though. Also you get no bonus points.

>why
Because a definition that doesn't pass the C struct test isn't particularly interesting to me.

you can do oop in c tho

Sure. But seriously, an object in its purest sense is literally just an instantiation of something.

A long long time ago, in a land far far away, computer programs were small and maintainable.

But then the complexity came. And with the complexity came the bugs. And with the bugs came the terror. Deadlines stared to fall like leaves and all we hold so dear started to fall apart, huge software projects failed and turned money into dust and customers into despair.

Nothing seemed to work against complexity and people already started ran out of courage, but then something happend, than nobody would have expected: the 4 tribes reunited for the first time. To form a big alliance, a gang of four, a last line of defense against the dark denizens of complexity. This army of the doomed took the best practices and methodologies of other disciplines and hence called themselves "Software Engineers".

People already started to cheer, but then they went silent and asked: "But who is going to lead us?"
Nobody said anything for a while, then an old voice silently said:
"Follow my lead."
"Who are you? What makes you think you can lead us?" the people replied.
Then an old knight slowly stood up and said:
"I've had many names. I came down from the lands of the LISP and fought along King Simula I., as well as serving in the Smalltalk and Eiffel wars. I've had a lot of different appearances - too many to name them all. But her I am, wiling to take the challenge. Here is my oath:

OOP is sworn to eternal valor.
His design is by contract.
His weapons are reusable components.
His sword is an instance of SharpThings and made by SharpThingsFactory.
His informations are hidden.
His data structures are tied to the algorithms operating on them.
If his sword will break, he will fight with his knife, if his knife breaks, he will fight with his hands, always following the Liskov substitution principle."

The people replied "that's so cool!" and protected by their white board shields and following their clever tactics (written in UML) they won the battle against the bugs.


The end.

Object something, Object could had inner Objects.
Thing about OOP is about interrelation between objects and operation over objects.

OOP is about express domain problem in a language than several programmer could understand,make easy understand and make software.

I'm not really interested in such definitions because it's unclear from them what unique properties or intrinsic value objects (and by extension, object-oriented programming) are supposed to have.

a thing, person, or matter to which thought or action is directed.

Dude what the fuck it's just a way to structure and think about your code

> it's just a way to structure and think about your code
That's a nice platitude, but it doesn't really address the question or the C struct challenge.

your c struct test is bullshit and you are a lame troll

>your c struct test is bullshit
Why is it "bullshit" and why are you getting all angry?

that is what it is you fucking moron.

If your entire definition of an object is that "it's an instance of something", who am I to say otherwise? However, I don't find it interesting for a reason I've already explained. Go shitpost somewhere else.

>Yes, it's this thread again.
>Can any of you imperative experts define what an struct is?
>For bonus points, I challenge you to provide a definition that passes the Java object test:
>It should be impossible to take just any random Java program and mechanically transform its
>objects into structs and functions in a meaningful sense.
>If you think your definition passes the Java object test, you must prove it relying only on your original >definition (no ad hoc excuses and modifications).

>managing to miss the point so perfectly

It's impossible to pass the Java object test, user, because Java objects are glorified structs and functions. Way to go shooting yourself in the foot.

Irony

Don't use words that you don't understand. It's embarrassing.

Its a struct with functions defined inside, so you cant use them outside the object.

It's a meme you dip

Still no takers?

Oh my how insightful! We have found a strange loop in the matrix! Abort abort!

Please explain the point.

It's not my fault that there's no insight to be gained from your shitpost.

An object is an instance of a class.

A class is just a data structure with its own methods.

>Please explain the point.
The point is that if your definition of an object doesn't pass the C struct test, then objects (as per your definition) don't have any intrinsic unique or useful properties beyond what's offered by C functions and structs. Proving that structs and functions also don't have any intrinsic or useful properties beyond Java objects achieves nothing.

Lets see you implement private functions in c then :)

Let's see you provide a definition first.

lol

It's trivial to implement "private functions" in C. I just don't see a reason to engage with this, because it's unclear what "private functions" have to do with anything.

>It's trivial to implement "private functions" in C

can you do it in a non kludgy way?

>It should be impossible to take just any random procedural C program and mechanically transform its structs into objects in a meaningful sense.

It's impossible not to be able to take any random procedural C program and mechanically transform its structs into objects in a meaningful sense.

Structs are just objects with only getters and setters as functions.

So, regardless of how you define an object, you can mechanically transform C structs into it.

>can you do it in a non kludgy way?
I don't think your subjective tastes in are relevant here, unless you want to involve specific syntax as part of your definition of an object.

>So, regardless of how you define an object, you can mechanically transform C structs into it.
I can think of at least one definition that can pass the C struct test, but you probably wouldn't agree with it and it doesn't matter. The bottom line is that your inability to do so means that you don't have a concept of an object that offers any unique and useful intrinsic properties over C structs and functions.

In a way that's easier or at least as easy as how it's handled in, say, seppels or even Java

This is completely irrelevant as I've already explained. I'm discussing concepts while you're discussing syntax sugar.

lets hear it :)

I tried to give a conceptual definition earlier but you called it "unclear". What exactly do you want?

An object is (sort of) similar to a pointer.

I mean, this:
public class YourObject
{
int x;
YourObject next;
}

public class MainObj
{
YourObject obj = new YourObject();
obj.x = 1;
System.out.println(obj.x)
obj.next = null;
obj.next = new YourObject();
obj.next.x = 2;
System.out.println(obj.next.x);
obj.next.next = null;
}


is almost the same as this:
struct node
{
int x;
node* next;
};

int main()
{
node* head;
head = new node;
head -> x = 1;
std::cout x;
head -> next = null;
head -> next = new node;
head ->next -> x = 2;
std::cout next->x;
head -> next -> next = null;
}


well, at least that's how I understand it.

I'm not sure which conceptual definition you're referring to. Put a reference to it in your next post.

no

Fuck me, the Java part has the method missing. But, at least you get the point.

>But, at least you get the point.
I assume your point was that Java objects are glorified structs?

But standard c-like structs are missing conveniences that make it useful to work with them to accomplish OOP.

It can be done, for sure, but that's what c++ already is.

Not really. My point is that Java objects are SIMILAR to pointers (well, if you look at it in terms of linked lists). But, yes, objects are structs.

fuck, I meant that objects are structs with the ability to have a function/method inside.

TOO LATE FAGGOT

>conveniences
That's another argument about syntax. It misses the point of the thread.

You really like to shitpost in my threads, don't you? Did I hurt your feelings yesterday or something?

The point of the thread was to define what an object is, which has been done multiple times.

Then you follow up with this c-struct autism even though you refuse to elabourate why or how it's relevant to anything at all.

good thread

Do we need to treat a collection of structs as the object?

>The point of the thread was to define what an object is, which has been done multiple times
You mean the "instance of a class" thing? Sure, you can go with that if you really want to exclude a bunch of OOP languages and fail to the C struct test.

>Then you follow up with this c-struct autism even though you refuse to elabourate why or how it's relevant to anything at all
It's up there in the OP, and I actually have elaborated multiple times how it's relevant:

>Do we need to treat a collection of structs as the object?
Not sure what you mean by this.

>I actually have elaborated multiple times how it's relevant:

really? where?

>how it's relevant

Yes. It's ir-

Whatever helps you sleep at night. Go shitpost somewhere else.

> make up constraint about mechanical translation of c structs
> have it pointed out C structs are universally translatable
> claim magic knowledge and refuse to share it
> victory

Shitposts belong in a shitthread.

you're cute :)

That's basically a long-winded and angry way of admitting that as far as the OOP crowd is concerned, "objects" are glorified structs and functions with no intrinsic value of their own, and that building programs out of "objects" yields no added value. Now combine it with the fact that the supposed tenants of OOP are in no way specific to OOP (except for the anti-feature of inheritance) and you can see why everyone outside your cult thinks that you're a joke.

tenets*

>"objects" are glorified structs and functions with no intrinsic value of their own
true

>and that building programs out of "objects" yields no added value
not

I see what you're going for now. You're just bad at getting your point across and condescendingly mistake your bad communication as others' poorly understanding what you meant.

> it's you

The thing is is that you cannot define a type of object that a struct isn't, but you can create objects that are not structs.

Structs cannot carry reference to the lexical environment which created them, as they do not capture the environment, and C does not support inline functions of any sort to assist them. So any object which can capture its environment is automatically unrepresentable in C structs.

Additionally, you can define objects to send messages to other objects, or have functions which generate complex values unrelated to the struct.

The only way to encapsulate such a thing in a c struct would be to use function pointers and pass the struct to them. However, to do so generically requires complex typing information that is unavailable to structs at run time.

You can then create an adhoc type system using integers, unions, (void *)s or whatever, but at this point you're hitting turing completeness rather than anything specifically to do with c structs.

Mathematically, you can convert anything into a c struct and set of related functions. They're universal computation machines.

>The thing is is that you cannot define a type of object that a struct isn't
Yes you can.

>Mathematically, you can convert anything into a c struct and set of related functions.
That is not relevant to what I asked in any way, shape or form.

The rest of your post has been ignored because it doesn't address the OP.

ur helpless

>Yes you can.

Prove it, or go choke on a bag of dicks and autism.

Not my fault that you're too dumb to understand and address the OP.

>> claim magic knowledge and refuse to share it
>> victory

Wrong, the reference variable acts like a pointer TO the object, the object is just a simple object living in the heap.

pOOP fags on sucide watch

>Prove it
I'm not going to bother with a full definition here because it's hardly relevant, but here's one possibility:
For something to be an object, the validity of its state must depend only on the correctness of its message processing code.

>implying my "victory" depends on my ability to define an object in a way that passes the C struct test
If you weren't so retarded, you'd realize that if it's impossible, that only makes your paradigm even less salvageable.

Throw an exception handler into a setter, boom

people aren't allowed to define words using terms the OP doesn't know: The Thread

Object is a struct + vtable + RTTI.

I think you mistakenly posted in the wrong thread because your response is a non-sequitur to literally everything in this one.

>define an object!
>I'm not gonna do it myself that would be irrelevant

Are you for real?

Um, no? If you have properly defined setters them the objects state will always be correct by way of code only within the object, to the point where its literally even recoverable if some other object tried to give it garbage. Stay in school

You are clearly a literal drooling retard (pretty much like any OOP "programmer"). I don't need to define or prove anything in this thread whatsoever. Nonetheless, I just proved to you that you can define an object in a way that passes the C struct test. I don't need to provide a full definition. You can fill in the blanks yourself however you like, but I did list the property that would make it pass the challenge.

Again, a complete non-sequitur. Very low IQ people in this thread. Sad!

>It should be impossible to take just any random procedural C program and mechanically transform its structs into objects in a meaningful sense.
Why? I don't think anyone argued OOP had hard features that declarative didn't. Both Java and C are Turing complete, after all.

Whatever, fag

He's an idiot don't worry about it

>Turing complete
This is irrelevant. x86 assembly is Turing-complete, but if I were to come up with a new language (let's call it Z) such that you could mechanically decompile a random x86 asm program into something that looks like idiomatic Z, one would start questioning the merit of Z and its idioms.

>low IQ retards patting eachother on the back
Cute. The bottom line is that you objectively did not provide a definition that passes the C struct test. Your opinions about things don't really matter to me.

Your test doesn't make any sense

>Your test doesn't make any sense
Really? Why not? Is it really so hard for your mind to process simple English? What part of it don't you understand?

How it's relevant to anything

Your inability to grasp how it's relevant to anything doesn't matter to me in the least. You either can provide a definition that passes it or you can't. I'm not here to debate whether it's somehow subjectively "relevant" for brainlets or not.