4 ms·

I haven't studied OOP extensively in a strict setting, but I would have said that in the OO world, a property is completely separate to a method. For example,

by axod 16y ago

I haven't studied OOP extensively in a strict setting, but I would have said that in the OO world, a property is completely separate to a method. For example, class flower property color property numberOfPetals method pluckPetal() method water() A property defines data about an object, and a method defines something you can 'do' with the object. Could you give some pointers to the OOP principle that blurs the line between these two?

adambyrtek 16y ago
It's called the Uniform Access Principle, as I've already mentioned in a separate comment. Getting back to your example, it is not very useful without mentioning a language under examination. There is no single definition of OOP, and every language implements in a slightly different way. There are languages where UAP is enforced by the syntax (eg. Eiffel, Smalltalk, Ruby) and languages where it's a matter of convention. But even in the latter it's considered a good practice to keep properties private and encapsulate them with accessors. Some even have dedicated features that help with that (auto-properties in C#, properties in Python).
masklinn 16y ago
> I haven't studied OOP extensively in a strict setting, but I would have said that in the OO world, a property is completely separate to a method. There is absolutely no reason for that, and the grandparent of all things object-oriented (Smalltalk) very strongly disagrees with you: everything is a message, and there are no properties. > A property defines data about an object, and a method defines something you can 'do' with the object. A getter method is a property and a method. Properties are irrelevant, access should be uniform, the implementation details of an object (whether a "property" provides direct access to internal data or not) is of no concern to the user of the object. A property is nothing more than a method whose contract is "give me some data"
- axod 16y ago
  That's a fine answer, and some people may find that a helpful way to organize programs. However, for me, and the CPU, we treat code execution differently to data access.
philwelch 16y ago
There's OOP qua Smalltalk/Kay, and then there's OOP qua Java. You're describing OOP qua Java, which is an ugly type of OOP designed for certain performance advantages.
- axod 16y ago
  Don't be ridiculous. 1. It's not ugly 2. It's how CPUs work 3. It's how most people think
  - philwelch 16y ago
    1. By ugly, I mean less mathematically elegant. In Ruby, you say "paul.foo" and get foo from Paul. How Paul gets foo for you is up to Paul. Simple. 2. If you want a programming language that maps closely to how CPU's work, Ruby's definitely not for you. Assembly and C are for you. 3. I can't speak for most people. What I can say is that I can think in C and I can think in Ruby, and it doesn't seem difficult for me.

by axod 16y ago

adambyrtek 16y ago

It's called the Uniform Access Principle, as I've already mentioned in a separate comment. Getting back to your example, it is not very useful without mentioning a language under examination. There is no single definition of OOP, and every language implements in a slightly different way. There are languages where UAP is enforced by the syntax (eg. Eiffel, Smalltalk, Ruby) and languages where it's a matter of convention. But even in the latter it's considered a good practice to keep properties private and encapsulate them with accessors. Some even have dedicated features that help with that (auto-properties in C#, properties in Python).

masklinn 16y ago

> I haven't studied OOP extensively in a strict setting, but I would have said that in the OO world, a property is completely separate to a method. There is absolutely no reason for that, and the grandparent of all things object-oriented (Smalltalk) very strongly disagrees with you: everything is a message, and there are no properties. > A property defines data about an object, and a method defines something you can 'do' with the object. A getter method is a property and a method. Properties are irrelevant, access should be uniform, the implementation details of an object (whether a "property" provides direct access to internal data or not) is of no concern to the user of the object. A property is nothing more than a method whose contract is "give me some data"

axod 16y ago
That's a fine answer, and some people may find that a helpful way to organize programs. However, for me, and the CPU, we treat code execution differently to data access.

philwelch 16y ago

There's OOP qua Smalltalk/Kay, and then there's OOP qua Java. You're describing OOP qua Java, which is an ugly type of OOP designed for certain performance advantages.

axod 16y ago
Don't be ridiculous. 1. It's not ugly 2. It's how CPUs work 3. It's how most people think
- philwelch 16y ago
  1. By ugly, I mean less mathematically elegant. In Ruby, you say "paul.foo" and get foo from Paul. How Paul gets foo for you is up to Paul. Simple. 2. If you want a programming language that maps closely to how CPU's work, Ruby's definitely not for you. Assembly and C are for you. 3. I can't speak for most people. What I can say is that I can think in C and I can think in Ruby, and it doesn't seem difficult for me.