> Why do you think RGB being bytes makes it special? Bools aren't bytes...
Bools are special too because the compiler handles ensuring that they are true and false (and you don't even get to choose to representation).
How would you handle a real complex type like Customer or Order or Window or Button?
> That does nothing to prevent errors.
Yes, it does. It's effectively the DRY principle -- you can't repeat the data manipulation code throughout the codebase. OOP formalizes some of the best practices for procedural programming.
>Bools are special too because the compiler handles ensuring that they are true and false (and you don't even get to choose to representation).
No they aren't. You are assuming every language is as shitty as Java. This is not the case. There is nothing special about Bool, it is a normal ADT:
Bool = True | False
>How would you handle a real complex type like Customer or Order or Window or Button?
Defining a type for it, just like anything else? I don't understand what is confusing you here. Do you normally just keep your Customers or Orders as a hash table of string:string or something? Even in OO languages, you create a type for them, it just happens that the only way you can create types in most OO languages is making classes.
>Yes, it does. It's effectively the DRY principle -- you can't repeat the data manipulation code throughout the codebase
Yes you can, there is absolutely nothing stopping you from making a dozen different doThingToCustomer functions/methods scattered across a dozen different classes. I am amazed that you are seriously suggesting that the problem OOP solves is people accidentally writing the same function multiple times, when that was never a problem, and OOP doesn't do anything to address it. And how on earth does this bizarre notion address the class of errors you were complaining about, which are type errors?
> You are assuming every language is as shitty as Java.
Perhaps. Java, C#, C++, PHP, Python, Ruby, etc.
> Yes you can, there is absolutely nothing stopping you from making a dozen different doThingToCustomer functions/methods scattered across a dozen different classes.
If Customer is a class, it's pretty difficult to doThingToCustomer() that the Customer itself doesn't allow.
> And how on earth does this bizarre notion address the class of errors you were complaining about, which are type errors?
Just as I said above, it's difficult to alter the contents of an object in a way that an object doesn't allow. In "pure" Alan Kay style OOP an object is something that responds to messages. In loose languages like Python you can reach into an object and mess with it but that is discouraged.
>If Customer is a class, it's pretty difficult to doThingToCustomer() that the Customer itself doesn't allow.
That applies just as much to functional programming as it does to object oriented programming. If you don't want people to mess with the internals, then don't export them.
Bools are special too because the compiler handles ensuring that they are true and false (and you don't even get to choose to representation).
How would you handle a real complex type like Customer or Order or Window or Button?
> That does nothing to prevent errors.
Yes, it does. It's effectively the DRY principle -- you can't repeat the data manipulation code throughout the codebase. OOP formalizes some of the best practices for procedural programming.