At its most fundamental level, an object is a collection of data grouped together.
The first statement, and you're already leaving out 50% of the magic
A collection of data on its own is not an object. It's an array, a map, or a struct (or record, if you come from pascal).
What makes it an object is the combination of data and behaviour, aka. methods.
This also shows in your examples: you're bulding a bunch of objects, but you're not giving them any methods. In a strictly OO sense, these objects are completely useless, as the only meaningful way of interacting with them is directly reading and setting their attributes, which you're not supposed to do (tell-don't-ask principle)
Classes in most programming languages are defined like so:
Usually yes, but in dynamic languages, with enough metaprogramming you can often still mess up an object to the point where it's arguable whether it still belongs to its class. In languages like Lua, where classes aren't a language feature but can still be implemented easily through metaprogramming, it is absolutely possible to completely override anything a constructor did and effectively "change" the class of an object.
C is one of the barest languages to exist, but it still provides us with a neat way to organize our data!
C doesn't have classes or objects as a language feature. You can kind of simulate them by combining structs and function pointers, but this is still very rudimentary and doesn't let you use classes at all.
That's just how I see an object, at minimum.
You make a good point that I don't make objects seem discriminable from arrays or maps (though a map is more or less an object around saving k/v).
I tried to coach the idea that objects aren't arrays (because object fields use names and not numbers).
But, maybe this can be covered in a future issue.
Yes; but, put bluntly, that's wrong. What you think of an object is really just a struct.
If you look at wikipedia, you'll get two definitions of what an object is. There's a very generic one:
In computer science, an object can be a variable, a data structure, a function, or a method. As regions of memory, they contain value and are referenced by identifiers.
which you'll often see outside the context of OOP, and there's a more specific definition on the article on object-oriented programming that states:
A feature of objects is that an object's own procedures can access and often modify the data fields of itself.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The first statement, and you're already leaving out 50% of the magic
A collection of data on its own is not an object. It's an array, a map, or a struct (or record, if you come from pascal).
What makes it an object is the combination of data and behaviour, aka. methods.
This also shows in your examples: you're bulding a bunch of objects, but you're not giving them any methods. In a strictly OO sense, these objects are completely useless, as the only meaningful way of interacting with them is directly reading and setting their attributes, which you're not supposed to do (tell-don't-ask principle)
Usually yes, but in dynamic languages, with enough metaprogramming you can often still mess up an object to the point where it's arguable whether it still belongs to its class. In languages like Lua, where classes aren't a language feature but can still be implemented easily through metaprogramming, it is absolutely possible to completely override anything a constructor did and effectively "change" the class of an object.
C doesn't have classes or objects as a language feature. You can kind of simulate them by combining structs and function pointers, but this is still very rudimentary and doesn't let you use classes at all.
That's just how I see an object, at minimum.
You make a good point that I don't make objects seem discriminable from arrays or maps (though a map is more or less an object around saving k/v).
I tried to coach the idea that objects aren't arrays (because object fields use names and not numbers).
But, maybe this can be covered in a future issue.
Yes; but, put bluntly, that's wrong. What you think of an object is really just a struct.
If you look at wikipedia, you'll get two definitions of what an object is. There's a very generic one:
which you'll often see outside the context of OOP, and there's a more specific definition on the article on object-oriented programming that states: