Matthew Spence Fri Sep 23 04:10:56 -0400 2011

Subject: unnecessary use of private visibility, why?

Why are you using private visibility for methods
It makes modifying the deeper behaviour of AR impossible
I understand that in principle these function are not part of the API but it means that when I extend a class to customise the behaviour I have to repeat the entire class rather than just the method with the behaviour I wish to change. And beside why not just use protected?

There are two reasons I might what to do this
1. Because the AR functionality is lacking in some way and I need to modify it quickly and without any hassel, in theory I should fork, submit a pull request and wait patiently, but I'm a developer, I'm busy and I need to release yesterday. I'll contribute back just not right now
2. Because of specific project use case that shouldn't be part the standar library

Nobody has every really explained real practical benefits of using strict visibility, maybe I'm missing something?

(Apologies for any uncurrents of discontent, but this is a real bug bear, I am in fact a big fan of PHPAR and really appreciate the work you are doing on it)


Beau Beauchamp Fri Sep 23 06:20:43 -0400 2011

I agree. Private visibility should only be used in the RAREST of circumstances and to maintain some particular base class property or method that should never be overridden lest it might break critical functionality.

Frankly, within open source code, I can really see only very limited reasons to ever have a property or method set as private. If you must set these to private, please provide some accessors that expose the property or method to other developers. JM2¢

Nanne Huiges Tue Sep 27 04:43:20 -0400 2011

If you make functions protected, you open them for calling from their extended class.
In the case of 'normal' use of the library, you extend the Model class, and are not supposed to call certain functions. The practical benefit seems to me that you are being led to use the API/Model-class as intended: that's basically what visibility is for? Otherwise, why not make everything public?

Why not change the functions as it is in its current form, instead of override it?

I don't really see what "open source code" has to do with it btw.

Matthew Spence Tue Sep 27 06:28:44 -0400 2011

Libraries should (where posible) be flexible enough to be used not as intended, even in ways the original author never considered. This is part of the beauty of open source.

Why not make everything public? Good question, why not?

Nanne Huiges Tue Sep 27 07:08:29 -0400 2011

I disagree: The beauty of open source is that if you want to change the behavior, you can! It seems to me that this is no reason to shun good practices like visibility of methods, is it?

But basically you say: make everything public.
Why not make all variable public too? And going on like that, why all these seperate classes? You can better put everything in one class, so you don't need to bother with objects and all (reduction ad absurdum).

Ofcourse I know there is a difference between these, but the argument stands.

If you want a specific reason: by 'hiding' all methods and only opening to use some methods, you can change the behaviour of these methods with certainty that you will not break anything. Closely related is the single responsibility principle but probably a lot of different paradigms.

My advice would be to just change the object if you need changes? The beauty of open source and all

Matthew Spence Tue Sep 27 07:35:13 -0400 2011

Why not make variables public too? the numbers of times I've wanted information about an object and the property is private, (relationships a good examples here)!

Just changing the object: yes this is the right thing to do, but in the real world sometimes its really useful to quickly be able to hack around and public methods make this really easy to do. Forcing me to use the API is basically the library saying it doesn't trust me to think out side the box and break a few rules in the interest of pragmatism.

It should let me use it which ever way I like, by all means warn me, either through the docs or prefixing properties and methods with _ but dont force me. Dont treat me like a child: if i fuck it up I can take responsibility for that.

Nanne Huiges Tue Sep 27 07:45:12 -0400 2011

But being the responsible adult you are, why not just change the code where you actually can? There's nothing at all stopping you from placing these hacks in the current code, instead of in your extension. Nothing. Go for it! Work outside the box! nobody is forcing you to use the API! You can even change the library to have all methods public. No issue at all.

There are however reasons not to make everything public:
In the real world you want that if you know you use this product in the intended way, any update of said product should not break your code. This is a great peace-of-mind for any developer using this in a production environment. Having a product that knows what functions it is allowd remove, move around or change parameters from is great for maintainability etc.

So there is the option you want: make all public, have library that is not maintainable, but you can hack your heart out.
And there is the other option: Project uses good practices, and you hack you hacks in a different file (you can, because the beauty of open source lets you). I see no problem!

Matthew Spence Tue Sep 27 08:01:17 -0400 2011

OK that makes sense...

I would still argue that underscored properties and methods make more sense as it clearly distinguishes what is API and what is not, but still allows people to hack around when they feel there is a need to

Some people weren't entirely happy about another forked library to maintain
But we have now made the jump :)
https://github.com/unikent/php-activerecord

(1-7/7)