Mihail:
Yeah, when to use a property, to me, is not a science, but if I think of a member of an object as a value that should be self-evident, or directly available, then I commonly expose that as a property. In
OOP a class is commonly thought of as having data and behaviours, and so I think of the "data" as being exposed by Properties, and I think of the "behaviours" as exposed by Functions and Subs.
So I guess in general, if a member of a class is not a behaviour, it should be a property.
Also notice that members you add to a class appear in intellisense, and that the icon presented is different for a Property, on the one hand, and Subs and Functions on the other, so that can give the future you some information as to what those members are for, when you create an instance of a class you wrote 2 years ago and you can't remember how to use it.
But it might be interesting too, to look at objects you know in the object browser. A DAO.Recordset exposes a Fields collection as a property, but it exposes GetRows() as a Function. Why? What I imagine is that GetRows() is an added on behaviour, something the recordset can go and do, but internally it probably uses its own Move methods, and Fields collection to construct the GetRows() array on the fly. So the recordset exposes Fields() as a native attribute of what the recordset is, but GetRows() is a request you put in for the recordset to go and do something for you.
Looking at how other people solved these problems in the Object Browser is really interesting. It gives a lot of hints if you want to design your own classes.