Unless you are architecting core or interested in how that particular sausage is made, please leave in peace and don't hack core.

We try to create APIs that serve a real lot of use cases. However, every API has boundaries. Despite the multitude of alters, there are always more to add. On the OOP side of this, I had a lot of clashes in the past because I did not want to see the protected keyword in core APIs because I was afraid that use cases will rise we couldn't think of before and I felt leaving the object "open" is better. Turns out, the "properties starting with an underscore are private" notation is a PHP4 pecularity that noone knows any more. Marking something protected makes the API easier to understand. And we have an answer in case you (and you alone!) need to something core didnt think of.

The agreement, the common understanding now is this: we are (and always were) trying very hard to find the possible use cases while designing, involving all the high profile people who are doing something related, patching in the open in the hope that others in the community will chime in wih use cases. However, at the end of the day, if you need to do something really crazy and core does not allow for this feature and very few people need it and the change would make everyone's life harder then it is okay to say that yes, you hack core. You do not get to those crazy places without the help of people who already know Drupal rather well, anyways. Of course, this is not an endorsement of hacking core. It is an answer to my question: "And what if a use case we couldn't thought of comes up later?": "If a lot of people need it, we fix it in a later release. But if you are one of the sites with eighty database servers who needs this then you just hack core for it and that is OK."

Ps. Any comments not relating to API design will be deleted.

Commenting on this Story is closed.