Jump to:
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
I'd like to see that Drupal 7 would be more object oriented. I'm no die-hard programmer, so forgive me if I say something stupid.
I've been thinking a bit on how this could be set up and I've come up with the following: Every module should be an object containing methods and properties. Core features should be put into a central drupal object. This would group variables and functions in a logical way and it prevents collisions between names (probably that's only a theoretical problem, but a lot in life consists of such problems :-P ). Achieving this would allow the use of a more consistent naming as well. Instead of drupal_mail() and url() (This is one thing I've been tripping on: the use of the 'drupal' prefix for some functions) we could have drupal::mail() and drupal::url(). Another advantage is the use of private and public variables.
I'm more a Javascript guy and I have no real OOP experiene in PHP, so I can't share any ideas on the technical part. I just hope some people will find this thread worth looking at.
Comments
#1
This is something that should be discussed (again), now that 7.x requires PHP5. A good candidate for a first step could be
$user(fromuser.inc), that is relatively self-contained. The next step could be$form(fromform.inc), before going to the harder$nodeand such.I don't see the use of objectify-ing core functions such as the
drupal_mail()you mentioned, because those are mostly static functions.#2
I'd like to see every module as an object. This prevents naming collisions, offers _real_ private vars, etc. When putting contribs in an object, I think Core should be put in an object as well for the sake of consistency. Seemingly 'random' prefixes like used for drupal_mail() would be erased as well. Although these prefixes might be chosen from the point of view that the functions won't conflict with PHP's built-in functions (drupal_mail() versus mail(), drupal_eval() versus eval(), etc..), putting Core functions in an object as well erases the need for those prefixes completely.
#3
Xano
Short answer: Drupal is OOD (Object Oriented Design) but not OOP (Object Oriented Programming).
The long answer has more details in it.
Asking for OOP is not stupid in itself. However, I often meet people who find procedural code (like Drupal) abhorrent because it is just not OOP, and it eventually boils down to them having grown up (programming wise) with only object oriented languages, and find everything else difficult/incomprehensible.
One module I wrote got an issue one day from someone saying : please allow me to write it as a class. I will make it backward compatible, but I need that to solve such and such problem. After some messages back and forth, it turned up that all what he needed was
somefunction($uid), instead ofsomefunction()which he assumed that it can only handle the current user ($user->uid internally).Also, please read the following, which are previous discussions on this topic:
Drupal from an Object Oriented Prespective
Discussion of the above document
Group on Object Oriented Programming in Drupal.
With Drupal 7 being PHP5 only, the move to OOP is less of an issue than before (up to Drupal 6) because we no longer have PHP4 to deal with. But that is just one battle. There are many others.
So, before we move to OOP, we need to find compelling reasons on why we should do so, what are we missing currently by not doing it (besides people who can only code in OOP), what are the drawbacks (Memory and CPU usage? Performance? Complexity? Maintenance?), how do we move there (incremental patches, one big shot?), and what the impact on contrib will be ...
#4
So far the only benefits outlined here are lack of namespace collisions (which we can work around with function name prefixing), consistent function names (which we can fix by making them consistent regardless if they're in OO or not), and private/public variables which to-date haven't been a problem to my knowledge. Unless there's something more substantial, I don't see a reason to get behind this.
I'm all for converting specific sub-systems to OO where it makes sense; for example, our database abstraction layer switching to PDO for better compatibility with other systems. But switching modules to objects (especially since you will only ever have one instance of each module) seems fairly arbitrary to me.
Remember that any API changes take their toll in the training of new developers, and in holding back upgrades to contributed modules. While we're not at all afraid to refactor and break APIs all over the place if it substantially improves things, we should have a darn good reason for it.
#5
I believe that OOP will give not only namespace collisions benefits. It will give much and much more. It will make the system more flexible and more convinient for developers. It will allow reuse (and make more reusable) much more code. It will allow use and apply all standard OOP patterns in common way. So eventually it will make Drupal more clear and convinient for developers who used to think in OOP (I think that now the most of developers know OOP, patterns, etc.)
I think you are agree that OOP is a mainstream and one of the most important and usefull stages in programming. So why does Drupal go against of the mainstream? Why does Drupal try to invent a wheel again (e.g. implementing basic OOP paradigms with procedural approach)? Why does not Drupal uses the most programming language features and uses just a part of them and so restricts oneself?
I really like almost all ideas and conceptions of Drupal: very flexible module system, very flexible themes system, great multilanguage support, taxonomy, multisiting, etc. All these are brilliant. But I don't like implementation based on procedural paradigm. I believe that such brilliant system as Drupal should use the most powerful paradigms and approaches. Hope that in next versions it will be on the way.
PS: sorry for my English, I am from Russia.
#6
This explains Drupal's non-OOP design philosophy: http://api.drupal.org/api/file/developer/topics/oop.html/6
Again, I think the best place for you to start if you're interested in this area is to find one or two sub-systems that make sense as OO and work with others to help design and convert those. A complete re-write of Drupal in OO is not something I think would get any support.
#7
Mind you, the link webchick posted is based on Drupal 4.6 or earlier and PHP 4, so take it with several grains of salt. That said, she is dead on in #4. OOP is a tool. It is not an Answer.
Like any other tool, it should be used where it makes sense to use it and not used where it does not. "Make Drupal OOP" is a pointless effort. "Make system X more flexible/powerful/better and use classes in the process" is a worthwhile effort, *if* the use of classes there helps make X more flexible/powerful/better.
There likely are places in Drupal where we could leverage OOP better, but that is not the same thing as "Make Drupal OOP". I am marking this won't fix. If you want to see more use of classes and OOP syntax in Drupal, file a patch somewhere that gives a tangible benefit and uses OOP in the process.
#8
There's nothing wrong with doing things your own way as long as it's a good way.
I'm a great fan of creating things in a highly structured and consistent way. That's why making Drupal more object oriented seemed to me as a good thing. I am however no PHP guru, so I don't know about performance issues (haven't thought about them either for that matter) and other side-effects.
A short reply to Webchick's private-variable statement in #4: Indicating private variables and functions using an underscore does the trick, but it seems bit dirty to me. We're saying they're private, but actually they're not.
#9
To OOP for OOPs sake?
Any time I come across this topic, you can invariably divide people into the two respective camps, one main reason being, that particular coding practice is what that person is comfortable using.
There are many advantages in PHP5 OOP, but it doesn't have to be all or nothing, one thing or the other. Drupal is currently based on sound Coding practices, and that's all that counts.
One thing I think a lot of contributors in this kind of discussion forget is, that websites (for the most part) are procedural, users and usage workflow, follow a sequential pattern.
I don't know enough about Drupal core API now, and I certainly don't know what it will look like for Drupal 7, but for MODULES, this idea sounds to me, a good thing.
#10
Here are two recent examples of the "OOP only" mind set where a class is a solution to everything.
http://drupal.org/node/264482
http://drupal.org/node/217949
Blame universities teaching only Java ...
#11
No, I'm definitely against doing something for that something's sake. The reason I made this thread was because I thought it would be a good idea to implement some more OOP features. The reasons are mentioned in the first post on this page.
#12
I don't know why this issue is still getting comments, as this issue has no meaning. There will be no "OOP for OOP's sake" in Drupal, just as there should not be any other programming style for its own sake. Use the tool that makes sense for the use case.
Module-as-class is a use case where it would be catastrophically bad to do. We saved 20% of Drupal's page load time in Drupal 6 by breaking modules up into separate files. In Drupal 7, we now have4 a code registry so we can break modules up even further and save even more load time. Classes in PHP must always be in a single file. Module-as-class would result in a gigantic increase in wasted cycles and memory, and is bad OOP practice anyway because it's using a class as a pseudo-namespace, which is a bad idea to start with. There's plenty of places where OOP makes sense; this is not one of them.
Nothing more to see here, move along.
#13
I have developed a lite-weight streamlined module which can offer full OOP capabailities within Drupal 6. The module offers almost no performance overhead over standard Drupal 6.
http://drupal.org/project/droopal
#14
Thanks Crell, this is an answer that really explains things to me.
#15
I disagree with Crell. Modules as a class would be a godsend, because right now there is no module inheritance mechanism worth even mentioning. Yes, it loads slower, but I'm willing to be that can be fixed, and will be given enough time and thought (There are many tricks we could use to defer code loading and still insert functionality into classes, GoF is full of them ). All OOP loads slower than procedural programming, and it is far and away the architecture of choice for preserving *Developer time*. If we need speed at all costs, we should use something else. ( As to classes as namespaces, that is a design feature of python and it works very well there. That is not a "known truth" )
For me, the big one is CCK/views. I really dislike the way they mix site and data schema and logic up in the content database. If we had decent inheritance mechanisms for modules, we could write custom content in the code without the huge amount of code generation required right now. In decent OO designs, only the "delta" gets coded in an application specific context.
Personally, I must stay then whenever I read threads and posts on OOP with Drupal, I notice a lot of defensivness and a "we don't need that crap" attitude. I don't think there is anything wrong with admitting that Drupal's OOP support is weak because when it started, PHP's was practically non-existent. Drupal is great because of it's maturity, but it's ok to admit that with that maturity comes some *heavy* historical baggage. Now we have introspection and decent class level method support, I think a way to make modules as classes ( perhaps with class level methods? ) would be great. It's the norm for RoR, Pylons, Django, Struts, TurboGears, and I don't think the writers of those frameworks are stupid people. ;-)
I'm interested to hear more from both sides of the fence here.
Thanks
Iain
#16
@#15:
It is bad form to post to an already won't-fixed issue. The issue is closed, dead, and should stay that way. It is accessible for historical reference so that people can see discussions that came before and their resolution, not to argue endlessly over their resolution.
However, if you really want to hear more, permit me to point out all the ways in which you do not understand the problem.
If there is a 1:1 correspondence between a module and a class (that is, "Modules as a class"), then we will be forced to load all of system.install (and every other .install file) on every single page load. It will also be impossible for, say, the Views module to implement views hooks on behalf of the node module, thus completely breaking Views. That cannot be "fixed" without fundamental changes to the PHP language itself.
That is an old wives tail and is heavily dependent on the particular OOP or procedural architecture you are using. It could be faster or slower depending on how you use it.
Unless you factor in the time required to learn OOP, which is more conceptually heavy than procedural and harder to get right. You also clearly haven't talked to any Functional programming fans (which totally pw0ns the market on unit-testable code architecture), or heard anything about the new-fangled Aspect Oriented Programming paradigm. It sounds more like you're just blindly repeating something from a college Java class. (Nothing against college Java classes, mind you. I took several.)
Views 2 is heavily OOP, but not with a module==class design. Its author understands how much module==class would have failed to do, uh, anything.
I have no idea what you're even talking about here. I don't even know what "mix site and data schema and logic up" means.
Just because you can extend a class doesn't mean you get free database storage; mapping OOP data structures to SQL is quite probably an intractable problem.
You should also be aware that inheritance is very heavy and limiting conceptually, which is why the current trend appears to be away from inheritance entirely and heavier reliance on composition. The PHP internals team is currently planning to introduce traits into the language in 5.4/6.0 in order to make naive inheritance even more unnecessary.
All of the other systems you mention there are also written in languages other than PHP. Drupal is written in PHP. Architectural designs that make sense in one language frequently suck in some other language. (Drupal rewritten as-is in Java or Ruby would likely suck horribly.)
And lest you think I'm just one of the anti-OOP luddites you mention, please have a look at the recent work I've been doing on core. I was the principle author of the new database system, which is 100% pure OOP design with a half dozen OOP patterns I could name. I am currently driving hard to implement a third extension mechanism in Drupal, which is based entirely on OOP principles.
I am no enemy of OOP code. I am an enemy of naive OOP code. Module==class is an incredibly naive approach that will fail horribly, which is actually trivial to see if one simply takes a moment to examine the immediate implications of it. Knee-jerk naive "Make Drupal OOP" suggestions do nothing but give OOP a bad name and discourage developers from exploring the major architectural changes that would be necessary to truly leverage OOP in Drupal well.
Threads like this only serve to make it harder to leverage a powerful tool in Drupal. Please, as a supporter of OOP design, stop now.
#17
Loading times and processing times can't be an argument against OOP. Technology will evolve faster than you can code to solve such issues. OOP vs. procedural coding has already been discussed endlessly on an abstract level (Why do you think PHP, ActionScript, the upcoming JavaScript, Java, etc. are OOP?) Grow up Drupal and stop this nonsense about speed -- hardware takes care of that!!!
#18
@Crell
I'm appalled that a core developer of an open source project would actively try to squash community feedback by marking an issue as won't fix in an argument where you're on the losing side of 2 against 6 so far (not saying anything about the relative weight/credibility various people bring though). To then try to enforce your own decision by saying it's "bad form" for people to argue with you, is worse. This smells a lot like the way Chinese and Iranian politics go...
So I'll help out by reopening this issue, because it's still a pertinent one that requires further discussion without flamewars. Also, since there's no way anything discussed will make it into 7.x, I would like to flag it for 8.x, but that's unfortunately not an option yet.
I would like to start my contribution to this discussion by saying Drupal is revolutionary and a great piece of software with an excellent community. I would like to point out that its architecture is not necessarily responsible for its success or these features. Also, I agree that not everything suits an OO-focus. You can definitely go too far.
That said, most PHP applications, especially CMS ones, have embraced PHP5 OOP (and many PHP4 OOP before it). Zend themselves are obviously pushing future PHP features to be more OO through leadership in Zend Framework. You'd actually be doing a great service to developers (who often contribute to more than one project) if you'd follow similar coding standards to the rest of the PHP community, while maintaining all the best features of Drupal that are best implemented in a different way (eg. I think form API is better than most other OO-based forms systems).
Drupal is also limiting the benefits it can reap from future advances in PHP if it follows an anti-OOP track. New features like SPL iterators, autoloaders, magic methods etc are not available to Drupal's implementation of OO. I do note that Zend's decision to make PDO OO has forced Drupal to go OO there too - about time. Being able to foreach over a resultset is something I've been taking for granted in other PDO-based apps since 5.2 went mainstream years ago, and Drupal feels very backwards (and code-bloating) with all these db_fetch_object() calls everywhere.
Further, Drupal is already using objects, and hence PHP's OOP features, what I would consider to be inappropriately. I disapprove heavily of Drupal's use of stdClass everywhere, just to get the benefits of OO shorthand syntax. The process of creating a node in code is disgusting:
$node = new stdClass;$node->type = 'whatever';
$node->uid = 123;
$node->status = 1;
...
To me, that just looks like you're actively avoiding using an object system that was perfectly capable even in PHP4 for this.
$node = new Node('whatever-type');// or, factory pattern
$node = Node::create_new('whatever-type');
Having to call node_save($node) feels a lot like how people used to do OO in C; passing state structs into functions. Where a function can only act on one data type, why on earth isn't it part of a Node class? $node->save() makes much more sense to me, as does $user->save(), User::load($uid) etc. It's shorter to type and easier to understand for modern programmers.
I'm not saying that every node type should have its own class though, that's not necessary. I'm just saying that all the common things you can do to a node could easily be made part of a node class.
If you did choose to use standard Node and User objects, you could embrace the use of mixins rather than inheritance to provide enhanced behaviour. PHP doesn't currently support mixins properly, but they can be emulated using magic methods and search chains. Have a look at the SilverStripe CMS (http://www.silverstripe.com) for a Ruby-inspired PHP5 CMS that makes elegant use of mixins rather than inheritance to enhance content objects. It's possible to implement today, and maybe in the future PHP will give us proper mixins that Drupal could then migrate to.
To Drupal's merit, there is an advantage to not having proper private methods in modules, in that other modules can call private functions "naughtily", which is often helpful. I'd recommend if modules ever went to classes in Drupal (which I agree they should), there should be a convention of keeping the underscore but marking them as public anyway just to facilitate inter-module calls, which are quite important to some contrib.
One way in which the current architecture is letting Drupal down is that there are some hooks that are common between themes and modules, and there's no way to distinguish between a module and a theme with the same name (which has bitten me several times). This leads to a bad developer experience. If a theme and module classes extended either Theme or Module, Drupal would be able to tell which was which, even if they had the same name. Small issue, but an example for you. The advantage of going to classful modules is obvious to me: less typing! I can't count the number of times I've typo'd the module name while prefixing tens of functions. I would much rather have self::do_something() than my_big_long_modulename_do_something(). It makes it easier to read the actual function name, prevents the developer having an incentive to give their module a ridiculously short and uninformative name (case in point the 'fb' module). It would also allow hooks to actually be called hook_menu() and be instantly recognisable as a hook. Recently I accidentally created a function in my module that happened to be modulename_install(), which worked fine until the .install file was included by update.php, when then gave an E_FATAL. These kinds of things are hard to debug for an uninformed developer.
Another issue with Drupal is namespace collision with other projects. I've worked on many Drupal projects for clients that required pulling in other libraries or even whole systems inside Drupal's space. In some cases these have been commercial PHP projects with obfuscated source that I can't change. All that needs to happen is for that project to also have a url() function and the show's over. Having Drupal::url(), or even D::url() would be a welcome help in this regard.
There's a reasonable chance that Drupal 8 will be born into a world of either PHP 5.3 or maybe PHP6 hosts, and it'd be nice to be able to leverage the advances in areas such as namespacing that would come of that. Obviously that doesn't require OOP, but does require an open mind to changing Drupal's architecture and use of language features. Namespaces would be an alternative way to keep modules apart without prefixing function names, although then we'd have mymodule\something(), which just looks ugly :(
Sorry for this fragmented argument, but I'd like to reopen discussion on this topic for Drupal 8, because Drupal is long overdue for an architecture review in this area. I would like to remain a Drupal developer and contributor for many years to come, but I'm becoming increasingly frustrated with having to deal with two different OO paradigms in order to be a PHP developer that includes Drupal in their arsenal.
#19
We encourage feedback and encourage research before feedback.
#20
So where is a lack of research evident here?
My research into good architecture for PHP apps is mostly from being a developer exposed to many different ones. Drupal is the one I found most jarring to get accustomed to, code wise, and given this thread exists, I don't think I'm the only one...
#21
1) nelinz, your "Chinese or Iranian politics" comment is out of line and offensive. If you actually read anything I've written, you'll understand that I am trying to do the exact opposite of stifling discussion. I am trying to encourage productive discussion where it is actually useful. This thread, and the comments in it, only serve to slow down the wider use of object-oriented techniques in Drupal by directing that energy into naive and stupid places.
2) Calling on Drupal to "be more object-oriented" is itself a dead-end, because the concept has no meaning. Religious adherence to OOP or procedural approaches is harmful to Drupal. I have had this debate on both sides and I still hold to it. It's simply a tool; use it where appropriate.
3) Drupal 7 is already making much heavier use of OOP than any version of Drupal before it, ever. Drupal 6 had exactly one class in it. Drupal 7 currently has 63, not counting unit tests (which bring the number up to about 300). The database layer, job queue, caching system, module upgrade system, etc. are all now object-oriented under the hood, for perfectly good architectural reasons in their own right, and the number of systems in that boat is growing. There's also contrib modules such as Views, which is very very heavily OOP for very very good reasons. Sure there are other places that OOP could be used, but that takes time to convert a system the size of Drupal with all its complexity. If you think it's not doing so fast enough, stop whining and start coding.
4) However, converting things to OOP "just because" is that same religious blindness I mentioned earlier and shows extreme naiveté about both Drupal and OOP. For example, any time someone suggests "modules as classes" it instantly flags them as someone who doesn't actually understand how Drupal works, and by association that OOP-supporters do not understand how Drupal works. Every time someone makes that suggestion it sets back Drupal. For more details, see this previous posting: http://groups.drupal.org/node/20728
5) Drupal 7 is the first version of Drupal to require PHP 5, and therefore to even allow the use of more advanced OOP features as PHP 4's OOP sucked. Language-based namespaces are less than a month old, so we can't even think about using them for quite some time. They have to actually be widely supported first, and that requires rapid PHP 5.3 adoption. (Red Hat Enterprise Linux still doesn't support PHP 5.2 out of the box, even though it's several years old and Drupal now requires it. Do you really think we could require PHP 5.3? Not even.)
6) I am familiar with the mixin concept, and ways to emulate it in PHP. They all have flaws, and heavy performance concerns. You can see some of the work and research I've done in that regard here: http://www.garfieldtech.com/blog/php-magic-call I've seen other mechanisms that rely on eval(). I won't even bother commenting on why that is a horrific idea.
In short, if you want to see Drupal use more OOP for the sake of using more OOP, you are going to run up against a brick wall, and that brick wall is me. That's before you even get to the people in the Drupal world who do not like OOP or those who actively dislike it. This entire thread is OOP for OOP's sake. If you want to see Drupal leverage more object-oriented techniques, get cracking and working on patches that make use of OOP in ways that make logical sense in and of themselves. A few just off the top of my head:
#340283: Abstract SimpleTest browser in to its own object
#460320: Standarized, pluggable entity loading (nodes, users, taxonomy, files, comments)
#363787: Plugins: Swappable subsystems for core
Or anything at all in the database queue, which could still use more patch reviewers.
The "research" chx meant, I believe, is the huge number of open issues already on actually leveraging OOP in Drupal, or the thousands of words already written about how to use OOP in Drupal well, many of which are linked from earlier in this thread.
Stop talking, start doing, or else you're just hurting your own "cause". (And by making OOP into a "cause", you are hurting it as well.) That's been said as far back as comment #4 in this thread, by the Drupal 7 branch maintainer. You could research that comment as well.
#22
Because #18 seems to have the (false) assumption that "the number of people voices counts", I cannot agree with Crell more on this. This said, Drupal is not a democracy, so it doesn't even matter ;)
#23
@Crell, right, sorry for any offense caused. I spend a fair amount of time in Drupal issue queues and I often find that maintainers/authors either ignore you or shut you down unnecessarily - it felt like this in this case. I'm glad you responded to my comments - thanks.
As for the other issue, I've come across them from time to time, but generally I get the feeling there's some brainwashing that PHP's OOP features can't be used or suggested, often because of the above-mentioned articles which date back to earlier arguments, and even say that some of the lack of OOP practice is due to "historical reasons", which is why I thought maybe it should be raised again.
I completely agree with you that OOP for OOP's sake it not necessarily a good idea. I used to subscribe to this train of thought, but quickly realised that sometimes you're wasting time for no good reason. In the few specific cases I mentioned, such as themes, modules, nodes and users, I believe OOP would help rather than hinder.
Also, I never aimed this for Drupal 7. I'm well aware of the work that's going in leading up to code freeze, and nothing like this could make it in on time. This was me starting to think about a hypothetical Drupal 8, which may well be released when 5.3 features are reliably available (if D8 is slated for an early 2011 release, for example). I'm painfully aware of RHEL5's PHP 5.1, I maintain several non-Drupal systems that have to deploy to RHEL.
I've got the impression that Drupal doesn't mind breaking backwards compat. I've been using Drupal since 4.7, and there's sure been a few big changes since then, and I've felt they were all pretty good ones. I think appropriate use of OOP where it either helps Drupal's architecture, or helps developers be familiar with the architecture more quickly, would be a beneficial next big step for a D8 release.
I'm definitely not the type to talk with no action, and am perfectly happy to submit patches against core and/or contrib to demonstrate some things that I think could be done. Thanks for pointing me at those issue queues, I'll have a look and see how I can help. I'm also particularly interested in that Droopal project to add an optional OO layer, I've considered writing something like that as a proof of concept in the past myself. Ultimately Drupal lives or dies by its contrib, and there are signs of appropriate OO use as you mentioned in systems like Views, showing a general willingness of contrib authors to use concepts like that where they fit - good on them. I would like to see more Drupal docs that say it's OK to use OO where it can be justified or would make a pattern easier to understand to fresh eyeballs, rather than lots of links to "why Drupal isn't OO but is".
My strongest suggestion for where OO would help would be as I mentioned, the conversion of stdclass to classful objects, especially nodes and users. Now that we're on PDO and can use FETCH_CLASS, it's perfectly efficient to ask PDO to extract node or user objects directly into a Node or Account class. While it may not seem beneficial to do this, I can't see how it would hurt, since everything else would keep working the same way (so nothing breaks), and the code to create and manipulate nodes and users could be more reliable (eg. harder to forget to set type or status on a node if they must be specified in the constructor). Furthermore, it would allow functions that deal with nodes or accounts to have strongly-typed parameters that only accept those types, which I think is cleaner and overall would reduce some of the E_NOTICE noise coming out of Drupal, as well as make function signatures easier to glean in IDEs and api.drupal. If you think this is worthwhile, I'm happy to open a new issue and submit a patch or two.
I'll let this thread die for now if noone else has any interest in commenting, I'll open another issue if I have any specific contributions/suggestions to make in future.
#24
neilnz, if you reread Crell (and others) messages in this issue with a fresh eye, you will understand that we are not saying anything different then you. Drupal would strongly benefit from using PHP OOP in a lot of places. Nobody is "squashing community feedback" as you put it in #18.
What we are arguing here is that broad claims like "Drupal should be OOP", "Drupal is confusing to newcomers because it doesn't use classes everywhere", "Modules should be objects", etc. that were developped in this issue makes very little sense. Fell free to open separate issues and contribute patches to use PHP OOP in the places you believe it makes sense.
#25
Sure thanks. Just so we're clear, the "squashing community feedback" was in response to the issue being marked won't fix and then Crell following that up by telling people to stop discussing it, even though there was still stuff to say. If you look early on:
That sounded to me like an invitation for constructive discussion, particularly on the points raised. Before anything much could be discussed, it was marked "won't fix" and the discussion was apparently over.
Also, I did follow the other links earlier, such as the group page on OO stuff, but that was a dead link, so I figured it was best to reopen this thread and add my thoughts on the matter.
#26
I agree that Nodes and Users should, eventually, become objects. However, with the Field API now in core (which should also have been class-based, but that's something to deal with in Drupal 8) those objects are rather permanently too complex for a single query to load with FETCH_CLASS, although there are other places that could potentially be useful. That's TBD over time.
Another common-but-wrong concept is that node types should be subclasses. The problem there is that nodes in Drupal are additive, not extensive. That is, you add functionality and data sideways, in parallel, via the UI. So while Node could become a class, Node_Page, Node_Event, and so on would not work at all.
The reason this issue was won't fixed is simple: Spending time and energy talking about "make Drupal OOP" is a waste that should be discouraged. If there are places where Drupal could benefit from more use of OOP (and there are), that should be discussed issue by issue where it's being applied to see if it's applicable there or not. That's where such discussion is encouraged.
The old "Drupal and OOP" article is rather dated, yes. Sometime after code freeze I mean to update it, but for now there are other matters to deal with, like code. :-)
#27
I think you guys should first understand the actual architecture before changing it to Object Oriented just because Objects are sexy and trendy...
Since almost 10 years new technologies like objects was promoted because you can "reuse" them (did you ever reused the same object two times in a project???), because they allows abstraction, inheritance, encapsulation, and that's true that they have benefits. But there are anti-patterns, objects are not an answer to all problems, and you should consider the following flaws of Object Oriented Software Architecture.
You should also consider performances, if for programmer mechanism are transparent, it doesn't mean that at the machine level instantiate an object is not time consuming, there is process, memory allocation, dynamic checking for type casting, and a million other hidden operation that you are not aware of just to use objects instead of procedural function. Object is not a solution for everything, they can be faster, and they can be lower.
Here is a very nice must read about Drupal Architecture: Drupal programming from an object-oriented perspective
#28
So, to summarize, for example two interesting articles with some of the, respectively, main pros and cons are:
The current consensus seems to be a practical one: OOP as one of the available tools; that is, not to force OOP or a rewrite of Drupal, but just to use OOP where appropriate, for example the new database abstraction layer. See some details in Does Drupal 7 turn OOP?
#29
+1 for some more OOP in basic areas. Stuff like $node->save() makes more sense than node_save($node)