PHP standards/recommendations

[nikita2206]

We have two branches for PHP right now (the second one). So we need to come to some agreements and merge them, this PR is RFC stage - so additions/objections are welcome from anyone. /cc @geshan @hossam-fares @AyhamAlzoubi @cirpo @odino

[nikita2206]

About getters and setters, I didn't read or see this article before, but this quote perfectly outlines my feelings about accessors:

Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters. This is what the 'property' built-in is for. And do not take that to mean that you should write getters and setters, and then wrap them in 'property'. That means that until you prove that you need anything more than a simple attribute access, don't write getters and setters. They are a waste of CPU time, but more important, they are a waste of programmer time. Not just for the people writing the code and tests, but for the people who have to read and understand them as well. (source)

[odino]

re: getters / setters I think there are a few ways of doing it and its quite tricky. Python's way of exposing attributes publicly kind of makes getters / setters uber-counterintuitive, but that's just python.

Is there any PSR that mentions getters / setters? I think if we agree to remove them, we can remove them, but we need a policy for it, ie. are we gonna expose them publicly? are we only gonna directly access them in the class' scope?

ie. symfony has a mixed strategy on this: properties are accessed directly from within the class, but not exposed publicly. In some other places, they are public. It looks like a messy mixed solution and I'd want to keep it consistent...

In JS the solutions is to usually use bare properties, in and outside the object. In PHP it's quite different as the consensus seems to be to use properties, directly, only within a class (but as we saw in symfony, there seem to be some exceptions).

Let's try to look at other libraries, even in other languages, and see what they do? But lets remember python doesnt have protected properties, so it's a bit useless for them ;-)

[odino]

Also: we dont need abstraction if we dont need abstraction :) sometimes the PHP community tends to overcomplicate things, so have a look elsewhere to see whats the real trend

[nikita2206]

@odino

Is there any PSR that mentions getters / setters? I think if we agree to remove them, we can remove them, but we need a policy for it, ie. are we gonna expose them publicly? are we only gonna directly access them in the class' scope?

It's out of FIG's scope so no PSR for it. I don't think that we need a policy for it because you need getter only if you have reasons to have it: if it's a data object and you need to hide properties then most likely you'll need a getter, but setter is another thing - it depends on if your object is designed to mutable/immutable - and actually if you have a pair of stupid getter/setters then you probably need to just open your property to be publicly visible (again - doctrine and public interfaces are another thing).

are we only gonna directly access them in the class' scope?

Yes - this is the question we should ask ourselves everytime we write code - you can't say it for all the code you have, you need to see the exact case. This is why I'm saying that policy is something impossible here.

In some other places, they are public. It looks like a messy mixed solution and I'd want to keep it consistent...

I think this is not the thing that you can keep consistent and I, for one, don't see a reason to. Seems like the cost of this consistency is too high. (and again, for me it's kinda unreasonable to enforce such things as a standard)

Also: we dont need abstraction if we dont need abstraction

Exactly, that's why I don't like using getters/setters here and there :)

[odino]

are you guys ready to merge this?

[cirpo]

@odino closing this because this stuff are already in my PR