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?

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).

> 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"

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.

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.

Don't be ridiculous.

1. It's not ugly

2. It's how CPUs work

3. It's how most people think

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.