Drupal OO Discussion: Difference between revisions
Osejisycym (talk | contribs) No edit summary |
m (Reverted edits by Osejisycym (Talk) to last revision by Davidm) |
||
| Line 1: | Line 1: | ||
cannot model anything | cannot model anything | ||
nothing like agile | nothing like agile | ||
| Line 9: | Line 8: | ||
considerable angst about OO, arguments against it seem defensive. | 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 | 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 | 29:00 - building scaffolding on arrays | ||
34:00 | 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 | 36:00 take parts and make them OO | ||
| Line 27: | Line 26: | ||
provides a lot of support for objects, with regard for areas oo doesn't provide answers (eg menus) | provides a lot of support for objects, with regard for areas oo doesn't provide answers (eg menus) | ||
seems more a matter of | seems more a matter of "when." | ||
a) OOP is only so natural for those who goes through CS courses. | a) OOP is only so natural for those who goes through CS courses. | ||
| Line 43: | Line 42: | ||
OO - develop concrete idea of model and services. drupal - not. | OO - develop concrete idea of model and services. drupal - not. | ||
attitude | 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. | Views/Panels already use OO classes. | ||
Latest revision as of 01:51, 24 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.