Drupal OO Discussion: Difference between revisions
Osejisycym (talk | contribs) No edit summary |
(No difference)
|
Revision as of 23:47, 23 November 2010
cannot model anything nothing like agile
video
http://www.archive.org/details/Drupal_and_PHP_5_OOP
considerable angst about OO, arguments against it seem defensive.
"Drupal has gotten a long way without using objects"
"Can't fix OO framework" - can hack procedural
resolve with tricks like interception / aspect - end up with drupal
"for the first time" design specification for drupal 7, implement in drupal 8
29:00 - building scaffolding on arrays
34:00 "drop from OO to drupal is small" ... uh.. is Drupal chx? very discouraging comments exclusively, overly defensive. it's just another developed approach.
36:00 take parts and make them OO
43:50 hidding backend changes
provides a lot of support for objects, with regard for areas oo doesn't provide answers (eg menus)
seems more a matter of "when."
a) OOP is only so natural for those who goes through CS courses.
there's a reason to use OO - larger scale systems
overdone - basic concepts are logical and easier to learn than made-up ways.
b) OOP is more rigid. If you fuck up there is no way out
workalikes for db abstraction, NIH
type hinting
OO - develop concrete idea of model and services. drupal - not.
attitude "assume caller is intelligent" - changing code, late nights. no way to design something. why wouldnt you make it totally robust?
Views/Panels already use OO classes.
Core doesn't.
Provide an OO discovery method so classes can support unit-tested OO classses
Not a conversion.