Getters and setters in the documentation

[codedmonkey]

I was reading up on #282 where the conversation has segued into misuse of code generation. My problem about this is with the Doctrine documentation, and the fact that it doesn't reflect this practice.

The main tutorial indeed starts with code samples with getters and setters but after this there are only a few amount of mentions of getters and setters across the bulk of the documentation. I get that code examples do not contain getters and setters because the amount of space they take up, but there should be at least some reference about how you should set up your getters and setters.

For example, section 4 is about basic mapping, but doesn't include an example of a getter nor setter, while it's actually very basic since Doctrine doesn't work without them.

@Ocramius seems very adamant in symfony/symfony-docs#5070 that a developer should spend hours thinking about how they should set up their structure. I actually did that, but some in-depth information would help developers that are new to Doctrine achieve the same thing. Code generated by doctrine commands even generate more code than I can find in the documentation, while it should be easier to find it from the documentation if the developer should be thinking about it.

My proposal is, add some simple examples of getters and setters to section 4 and 5 (Basic Mapping and Association Mapping) of the documentation and maybe add some additional practices in section 7 (Working with objects) like is done in section 8.4 with manager methods.

[kimhemsoe]

I believe this issue belong to the ORM and not the bundle.

[codedmonkey]

Yes indeed, I will reopen it there, thank you for pointing it out.

[stof]

@codedmonkey Doctrine does not actually care whether you have getters and setters. It will never call them. You can do what you want for your class API.

[codedmonkey]

Doesn't Doctrine at least need them when the properties are private?

[Ocramius]

Doesn't Doctrine at least need them when the properties are private?

Nope, we use reflection for accessing properties.