Time for a new chapter of an endless debate
Hi, Drupal uses objects. Reasons are probably lost by now in the ancient past. PHP is still not the best. I can write: somefunction(array('this' => 'that')) while there is no similar construct for objects. Also we use arrays for links, menus, links and soon mails. So, I propose removal of objects on practical grounds: shorter notation and a very little memory gain. If you have an opinion please share but I think we are only furthered by _practical_ viewpoints. No theory can make Drupal faster or lower its memory usage. The change looks big but it's not, it's scriptable and I can whip up such a script in a very short time. Regards NK Ps. Readability issues? I do not think there is any difference.
Drupal uses objects. Reasons are probably lost by now in the ancient past.
PHP is still not the best. I can write:
somefunction(array('this' => 'that'))
while there is no similar construct for objects.
Also we use arrays for links, menus, links and soon mails.
So, I propose removal of objects on practical grounds: shorter notation and a very little memory gain.
Add to that consistency in the code, shorter learning curve for newbies as well.
If you have an opinion please share but I think we are only furthered by _practical_ viewpoints. No theory can make Drupal faster or lower its memory usage.
The change looks big but it's not, it's scriptable and I can whip up such a script in a very short time.
Ps. Readability issues? I do not think there is any difference.
What about the future? Say we want to move Drupal to be OOP. I guess the pain is already there since arrays are all over the place anyways.
I think this is good idea. People sometimes ask for an "object_merge()" function - that is just weird (to me).
What about the future? Say we want to move Drupal to be OOP. I guess the pain is already there since arrays are all over the place anyways.
We cross that bridge when we are there but Drupal is OOP just does not use the class construct, see JonBob's excellent work a http://api.drupal.org/api/HEAD/file/oop.html .
Another advantage of arrays over objects, is that arrays work almost exactly the same in PHP4 as they do in PHP5. By ditching objects, it should make it much easier to keep Drupal compatible with both of these PHP versions. For example, I just discovered today that in PHP5, object variables are always created as references to the underlying object. So when you copy an object, you're just copying the reference (unless you clone the object). And when you pass the object to a function/method, you're passing the reference (whether or not the parameter is specified as 'by reference'). In PHP4, however, object variables are not references, unless this is explicitly specified. If we don't use objects anymore, we won't have to worry about differing behaviours (across PHP versions) such as this one. Objects are one of the most poorly designed constructs in PHP4, whereas arrays are one of the best and most powerful constructs in all of PHP. I'm all for using arrays across the board in Drupal. Cheers, Jaza. On 7/3/06, Karoly Negyesi <karoly@negyesi.net> wrote:
Hi,
Drupal uses objects. Reasons are probably lost by now in the ancient past.
PHP is still not the best. I can write:
somefunction(array('this' => 'that'))
while there is no similar construct for objects.
Also we use arrays for links, menus, links and soon mails.
So, I propose removal of objects on practical grounds: shorter notation and a very little memory gain.
If you have an opinion please share but I think we are only furthered by _practical_ viewpoints. No theory can make Drupal faster or lower its memory usage.
The change looks big but it's not, it's scriptable and I can whip up such a script in a very short time.
Regards
NK
Ps. Readability issues? I do not think there is any difference.
I would have to say -1. 1) Ease of development. Objects have a shorter syntax than arrays do; half as many funky control characters. (-> vs. [' ']). That's half as many opportunities for typos. 2) Classes. Some contrib modules, e.g., Views, do use not only objects but classes. Those cannot be made into arrays with a simple regex. 3) Semantic consistency. An array is a list, or a multi-dimensional data structure. That's how we use it. An object is a complex entity "thing". That's how we use it. They are semantically different things, each with their own meaning and purpose. 4) Speed. Under PHP 4, arrays and objects are internally nearly identical and I believe there's no appreciable speed difference at all. Under PHP 5, objects have been rewritten and redesigned to be faster. Thinking for the future (and those many people that use PHP 5 already), there is a performance question to consider given the different engine. (I have not benchmarked the difference extensively, but it is something that should be considered.) On Sunday 02 July 2006 10:04, Karoly Negyesi wrote:
Hi,
Drupal uses objects. Reasons are probably lost by now in the ancient past.
PHP is still not the best. I can write:
somefunction(array('this' => 'that'))
while there is no similar construct for objects.
Also we use arrays for links, menus, links and soon mails.
So, I propose removal of objects on practical grounds: shorter notation and a very little memory gain.
If you have an opinion please share but I think we are only furthered by _practical_ viewpoints. No theory can make Drupal faster or lower its memory usage.
The change looks big but it's not, it's scriptable and I can whip up such a script in a very short time.
Regards
NK
Ps. Readability issues? I do not think there is any difference.
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Karoly Negyesi wrote:
Hi,
Drupal uses objects. Reasons are probably lost by now in the ancient past.
PHP is still not the best. I can write:
somefunction(array('this' => 'that'))
while there is no similar construct for objects. This can easily be accomplished with somefunction((object)array('this' => 'that'))
Also we use arrays for links, menus, links and soon mails.
So, I propose removal of objects on practical grounds: shorter notation and a very little memory gain. Or, we remove arrays.
If you have an opinion please share but I think we are only furthered by _practical_ viewpoints. No theory can make Drupal faster or lower its memory usage.
The change looks big but it's not, it's scriptable and I can whip up such a script in a very short time.
Regards
NK
Ps. Readability issues? I do not think there is any difference.
--No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.8/380 - Release Date: 6/30/2006
-- ---------------------------------------------------------- It is by Caffeine alone that I set my mind in motion It is by the beans of Java, that my thoughts acquire speed The hands acquire shakes; the shakes become a warning It is by Caffeine alone that I set my mind in motion
On 02 Jul 2006, at 17:04, Karoly Negyesi wrote:
Drupal uses objects. Reasons are probably lost by now in the ancient past.
I don't see the point. Let's just continue using what makes most sense in each of the individual contexts. -- Dries Buytaert :: http://www.buytaert.net/
On Sun, 02 Jul 2006 21:47:25 +0200, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 02 Jul 2006, at 17:04, Karoly Negyesi wrote:
Drupal uses objects. Reasons are probably lost by now in the ancient past.
I don't see the point. Let's just continue using what makes most sense in each of the individual contexts.
Khm, I asked for 'no theory' replies. Sorry, but even from you -- this has very little founding in PHP environment. An associative array has the same meaning as an object.
Op zondag 2 juli 2006 21:47, schreef Dries Buytaert:
I don't see the point. Let's just continue using what makes most sense in each of the individual contexts.
We can achieve a lot more consistancy (and thus a lot less code) if we settle for a good guildeline. I certainly do not agree that we should choose only one. Arrays and objects both make sense in lots of cases. We shouldn't try to settle for one, but use the programming language we have in a proper way. PHP has them both, for good reasons, why should we abuse the language, or not allow certain parts of a language to be used? Which does not mean we should leave stuff as it is, but instead we could settle for a guideline. Look at: 1) http://api.lullabot.com/api/HEAD/function/user_save 2) http://api.lullabot.com/api/HEAD/function/taxonomy_save_term 3) http://api.lullabot.com/api/HEAD/function/node_save All three *should* do the same. Yet 1) uses an object *and* arrays, 2) uses only arrays, and three uses only objects. The guideline I proposed several times is VERY simple. And it is the way PHP meant it to be: «use objects for structured items» «use arrays for lists of similar items» Yet everytime the Arrayfetishists (sorry) Shoot that down with theoretically (!) reasonings like "but arrays and objects are under-the-PHP-Hood handled the same", or "one performs better then another one". In the above examples, ALL foo_save and foo_load functions return objects. If you have a lot of such objects (a list of nodes, a group of users) you can put them in arrays. Keyed arrays if you wish. Bèr
On Sun, 2006-07-02 at 17:04 +0200, Karoly Negyesi wrote:
Hi,
Drupal uses objects. Reasons are probably lost by now in the ancient past.
PHP is still not the best. I can write:
somefunction(array('this' => 'that'))
while there is no similar construct for objects.
Also we use arrays for links, menus, links and soon mails.
So, I propose removal of objects on practical grounds: shorter notation and a very little memory gain.
If you have an opinion please share but I think we are only furthered by _practical_ viewpoints. No theory can make Drupal faster or lower its memory usage.
The change looks big but it's not, it's scriptable and I can whip up such a script in a very short time.
Regards
NK
Ps. Readability issues? I do not think there is any difference.
I'm down on consistencies sake. I'm also into the flexability of arrays. Our occasional use of objects don't allow us to do anything useful with them. Where we do have objects, they don't have any methods. So whats the point of keeping them around? .darrel.
On Sun, 2006-07-02 at 20:22 -0400, Darrel O'Pry wrote:
I'm down on consistencies sake. I'm also into the flexability of arrays. Our occasional use of objects don't allow us to do anything useful with them. Where we do have objects, they don't have any methods. So whats the point of keeping them around?
.darrel.
Not a very good blanket statement on my behalf, but there are several places where objects are used without any methods. I think those objects that have no methods should be converted to arrays. I don't think I've seen anything that says objects in php5 are faster/use less memory than arrays in php4. I've only seen those comments and mentions in relation to objects in php4 and objects in php5. (benchmark addicts?) If we get more consistent code and more consistent behavior between php4 and php5 with arrays, then I think it makes sense and has a founding as an idea. The argument of using which ever fits a situation is kind of lame. Why use an object if it doesn't have any methods or private variables? What do you gain? Why we using this complex construct if we just need a reliable data container that works with php4 and php5. see: $node & $file Is there any real reason for either to be an object? Or was it an arbitrary decision because someone thinks its prettier and easier to type -> instead of [' ']. What are we gaining by using StdClass instead of array? What would we lose by converting to arrays?
Hi,
I'm down on consistencies sake. I'm also into the flexability of arrays. Our occasional use of objects don't allow us to do anything useful with them. Where we do have objects, they don't have any methods. So whats the point of keeping them around?
There are a couple of reasons why we do not change. 1. Objects are easier to work with than arrays, but then again, it is 6 of 1, half a dozen of the other. 2. What is changing going to get us? We would spend the next 6 months moving all the code so that we use arrays over objects, and we will be no further ahead. There is no gain or loss. 3. I remember reading somewhere long ago. Dries likes them over arrays. This is like saying nodes are crap, and we should change them to the next greatest XYZ. Gordon.
Think of all the little php snippets, custom blocks, *.tpl.php, etc. files that use object notation instead of arrays. All of them will be useless. Converting them all over will cause a lot of people a lot of pain and frustration. Switching would not be worth it and a big mistake, IMHO. On 7/2/06, Gordon Heydon <gordon@heydon.com.au> wrote:
Hi,
I'm down on consistencies sake. I'm also into the flexability of arrays. Our occasional use of objects don't allow us to do anything useful with them. Where we do have objects, they don't have any methods. So whats the point of keeping them around?
There are a couple of reasons why we do not change.
1. Objects are easier to work with than arrays, but then again, it is 6 of 1, half a dozen of the other.
2. What is changing going to get us? We would spend the next 6 months moving all the code so that we use arrays over objects, and we will be no further ahead. There is no gain or loss.
3. I remember reading somewhere long ago. Dries likes them over arrays.
This is like saying nodes are crap, and we should change them to the next greatest XYZ.
Gordon.
-- Dondley Communications http://www.dondleycommunications.com Communicate or Die: American Labor Unions and the Internet http://www.communicateordie.com
Hi, This is just the tip of the ice burg. It comes down to. What extra does it give us? Nothing! Gordon. Steve Dondley wrote:
Think of all the little php snippets, custom blocks, *.tpl.php, etc. files that use object notation instead of arrays. All of them will be useless. Converting them all over will cause a lot of people a lot of pain and frustration.
Switching would not be worth it and a big mistake, IMHO.
On 7/2/06, Gordon Heydon <gordon@heydon.com.au> wrote:
Hi,
I'm down on consistencies sake. I'm also into the flexability of
arrays.
Our occasional use of objects don't allow us to do anything useful with them. Where we do have objects, they don't have any methods. So whats the point of keeping them around?
There are a couple of reasons why we do not change.
1. Objects are easier to work with than arrays, but then again, it is 6 of 1, half a dozen of the other.
2. What is changing going to get us? We would spend the next 6 months moving all the code so that we use arrays over objects, and we will be no further ahead. There is no gain or loss.
3. I remember reading somewhere long ago. Dries likes them over arrays.
This is like saying nodes are crap, and we should change them to the next greatest XYZ.
Gordon.
On 7/3/06, Gordon Heydon <gordon@heydon.com.au> wrote:
This is just the tip of the ice burg.
It comes down to. What extra does it give us? Nothing!
Not nothing. As chx explained, it gives us consistency, as well as bringing the handiness of arrays (e.g. all the useful array_* functions) to more variables. But now that I think about it, this is not nearly enough of a reason to justify the amount of code that will get broken (IMHO). Cheers, Jaza.
Hi, Jeremy Epstein wrote:
On 7/3/06, Gordon Heydon <gordon@heydon.com.au> wrote:
This is just the tip of the ice burg.
It comes down to. What extra does it give us? Nothing!
Not nothing. As chx explained, it gives us consistency, as well as bringing the handiness of arrays (e.g. all the useful array_* functions) to more variables.
Yes, consistency would be nice. so would been able to the useful array_*()'s.
But now that I think about it, this is not nearly enough of a reason to justify the amount of code that will get broken (IMHO).
I see this as being about same size in changes to the formapi() with no benefits. We would be spinning our wheels for 6 months and not achieving anything. I see this come up every so often, and the people who raise this don't really think about what would be involved in making this change. I don't even think a change like this could be fitted into a normal release cycle. Gordon.
Cheers, Jaza.
!DSPAM:1000,44a87e4d256438460975785!
On Mon, 2006-07-03 at 12:34 +1000, Gordon Heydon wrote:
Hi,
Jeremy Epstein wrote:
On 7/3/06, Gordon Heydon <gordon@heydon.com.au> wrote:
This is just the tip of the ice burg.
It comes down to. What extra does it give us? Nothing!
Not nothing. As chx explained, it gives us consistency, as well as bringing the handiness of arrays (e.g. all the useful array_* functions) to more variables.
Yes, consistency would be nice. so would been able to the useful array_*()'s.
But now that I think about it, this is not nearly enough of a reason to justify the amount of code that will get broken (IMHO).
I see this as being about same size in changes to the formapi() with no benefits. We would be spinning our wheels for 6 months and not achieving anything.
I see this come up every so often, and the people who raise this don't really think about what would be involved in making this change. I don't even think a change like this could be fitted into a normal release cycle.
trading -> for [' '] has nothing to do with the way we handle or represent data as developers. It won't be a major change to the way in which we carry and represent data and designate data handling in Drupal. It only affects how the interpreter handles the list of variables we store in $node, etc. and how we reference that data as developers. It is nothing like form api, and form api 2.0 is lurking out there somewhere anyway.
Hi, Darrel O'Pry wrote:
On Mon, 2006-07-03 at 12:34 +1000, Gordon Heydon wrote:
Hi,
Jeremy Epstein wrote:
On 7/3/06, Gordon Heydon <gordon@heydon.com.au> wrote:
This is just the tip of the ice burg.
It comes down to. What extra does it give us? Nothing! Not nothing. As chx explained, it gives us consistency, as well as bringing the handiness of arrays (e.g. all the useful array_* functions) to more variables. Yes, consistency would be nice. so would been able to the useful array_*()'s.
But now that I think about it, this is not nearly enough of a reason to justify the amount of code that will get broken (IMHO). I see this as being about same size in changes to the formapi() with no benefits. We would be spinning our wheels for 6 months and not achieving anything.
I see this come up every so often, and the people who raise this don't really think about what would be involved in making this change. I don't even think a change like this could be fitted into a normal release cycle.
trading -> for [' '] has nothing to do with the way we handle or represent data as developers. It won't be a major change to the way in which we carry and represent data and designate data handling in Drupal.
Agreed, it only changes how we interact with the data.
It only affects how the interpreter handles the list of variables we store in $node, etc. and how we reference that data as developers. It is nothing like form api, and form api 2.0 is lurking out there somewhere anyway.
I didn't say it was like the formapi change, but in terms of the scale of work it is going to be a big, if not bigger. This change will most likely change every source file in Drupal and Contrib. Every patch that is in the queue will then need to be re done and submitted again, and a change like this will take months to check and test to make sure that nothing was stuffed up, and at the end of all this work, where would be. At the same position we were before the change. Granted there are some good performance boosts (Thanks Angie I didn't think they would be that big) that we will get, but is this enough? I do not think that we could do this by hand coding, but if we could do this with a program that will rewrite everything and we also had a very comprehensive test suite (that would basically test every line of code) that we could run to make sure that nothing was broken. Gordon.
!DSPAM:1000,44a88805259161336712104!
(Disclaimer: I only have a passing understanding of the Drupal API's, but do have a fair grasp of coding theory. So take my comments with the proper amounts of skepticism.) I've read through all the posts on this thread, and I think a fundamental point has been missed. Objects and arrays serve different purposes. Granted PHP does some amazing stuff with arrays, but they still boil down to a list of items. Objects are different. They represent something tangible, in a meaningful way, and can DO meaningful things (methods). They HIDE how something is done (the encapsulation concept). To call an object with something like node->render(), or node->checkAccess(uid) - well, I don't care how the rendering or the security check is done, but I do care about what those methods spit out. This is SO much easier to understand in the long term, and results in much cleaner code. In a well designed object oriented app, the flexibility of objects is ENORMOUS. Properties that are themselves an object are a god send. And with objects, you do not need to abandon arrays - you just change how an array is treated. You treat it like the data construct it is, rather than trying to make it into something more meaningful by representing complex data. Yes, we can make arrays in PHP do a lot of similar things as objects. But the resulting API is an exercise in memorizing what function does what, rather than looking at what methods an object has and being able to make some reasonable deductions. Objects in PHP are still relatively new, seeing as (proper) support for them didn't arrive until PHP5. I see Drupal now dealing with the resulting capabilities this buys. As a result, Drupal seems to be in an "in between" spot right now - predominantly arrays, with a smattering of objects. But the objects are not well planned in a big picture sense, and doing a wholesale change to a true OO model is quite a bit of work. So, my thoughts on the next step is that someone needs to sit down and work out a class diagram that represents just what Drupal does currently. Then this becomes a model to be adopted over time as opportunities present themselves in future updates/releases. The speed thing is a non issue (not enough performance gain either way). The consistency thing is more of an issue, but still not the point. The core question is the future design direction of Drupal. To me, arguing to stick with an array is tantamount to saying that a basic data structure is all we'll ever need. The coding industry has proven this mindset wrong. But of course, arrays will always have a place in code. Shawn
Shawn wrote: [snip]
Objects are different. They represent something tangible, in a meaningful way, and can DO meaningful things (methods). They HIDE how something is done (the encapsulation concept). To call an object with something like node->render(), or node->checkAccess(uid) - well, I don't care how the rendering or the security check is done, but I do care about what those methods spit out. This is SO much easier to understand in the long term, and results in much cleaner code.
In a well designed object oriented app, the flexibility of objects is ENORMOUS. Properties that are themselves an object are a god send. And with objects, you do not need to abandon arrays - you just change how an array is treated. You treat it like the data construct it is, rather than trying to make it into something more meaningful by representing complex data.
[snip]
So, my thoughts on the next step is that someone needs to sit down and work out a class diagram that represents just what Drupal does currently. Then this becomes a model to be adopted over time as opportunities present themselves in future updates/releases.
To me, arguing to stick with an array is tantamount to saying that a basic data structure is all we'll ever need. The coding industry has proven this mindset wrong.
Hear, hear! Proper use of objects provide immense benefits -- including consistency (e.g. Nick's remarks about how do I access X here, and it being different from module to module). I would rather work toward a unified, consistent object model for Drupal using classes and methods -- and arrays as data structures -- because it would eventually lead to better and more rapid development in the future. And now my 2 cents are spent. :-)
Steve Dondley wrote:
Think of all the little php snippets, custom blocks, *.tpl.php, etc. files that use object notation instead of arrays. I actually wouldn't mind the work on the sites I'm responsible for if it meant putting an end to that sick little game I play everyday where I ask, "do I get to you through $foo->bar, $foo['bar'], or are you a very special $foo[0]->bar? and are you the same if I'm dealing with you in hook.module, a template.php, or a node.tpl.php?" ['the answer is often no']. The inconsistency has a tendency to be very annoying, imho. Not to mention... the methods used in about 60% of the snippets in the handbook make the hair on the back of my neck stand up... forcing a rewrite of some of them might not be a totally bad thing.
Can anyone here give an explanation of the status quo"an object here, an array there, and an intelligible pattern nowhere" that goes beyond, "well... that's just how its always been, and some things are now dependent on it, and its going to be a pain the ass to change it..."? Maybe I'm alone here, but I think that moving to make drupal's code more logical, consistent and predictable is a critical priority -- as high as usability, sexiness, ajaxitiviy,etc etc. Regardless of there being no immediate benefits on the feature/performance level, we should consider the value of having a platform that new developers describe as "friendly, and intuitive". Best, Nick Lewis "captain obvious" http://www.nicklewis.org
All of them will be useless. Converting them all over will cause a lot of people a lot of pain and frustration.
Switching would not be worth it and a big mistake, IMHO.
On 7/2/06, Gordon Heydon <gordon@heydon.com.au> wrote:
Hi,
I'm down on consistencies sake. I'm also into the flexability of
arrays.
Our occasional use of objects don't allow us to do anything useful with them. Where we do have objects, they don't have any methods. So whats the point of keeping them around?
There are a couple of reasons why we do not change.
1. Objects are easier to work with than arrays, but then again, it is 6 of 1, half a dozen of the other.
2. What is changing going to get us? We would spend the next 6 months moving all the code so that we use arrays over objects, and we will be no further ahead. There is no gain or loss.
3. I remember reading somewhere long ago. Dries likes them over arrays.
This is like saying nodes are crap, and we should change them to the next greatest XYZ.
Gordon.
On 03 Jul 2006, at 05:42, Nick Lewis wrote:
Maybe I'm alone here, but I think that moving to make drupal's code more logical, consistent and predictable is a critical priority -- as high as usability, sexiness, ajaxitiviy,etc etc. Regardless of there being no immediate benefits on the feature/performance level, we should consider the value of having a platform that new developers describe as "friendly, and intuitive".
You're not alone. If you want to improve the developer experience, and lower the barrier to development, changing objects to arrays is hardly going to make a difference. Instead, work on forms API 2.0, views API, CCK in core, etc. Personally, I very much prefer to use objects, and to use arrays as containers of objects. The 'everything has to be an array'-mantra is just awkward -- especially for new developers. -- Dries Buytaert :: http://www.buytaert.net/
Op maandag 3 juli 2006 05:42, schreef Nick Lewis:
I actually wouldn't mind the work on the sites I'm responsible for if it meant putting an end to that sick little game I play everyday where I ask, "do I get to you through $foo->bar, $foo['bar'], or are you a very special $foo[0]->bar? and are you the same if I'm dealing with you in hook.module, a template.php, or a node.tpl.php?" ['the answer is often no']. The inconsistency has a tendency to be very annoying, imho. Not to mention... the methods used in about 60% of the snippets in the handbook make the hair on the back of my neck stand up... forcing a rewrite of some of them might not be a totally bad thing
Very true. Yet "making it all arrays" is not the only way to solve that. It is, however, by far the most labour intensive way. Making them predictable one by one, is a better solution, I think. Often simple patches like "make the input parameters of user_load consistent with node_load" can help a lot more then some strange "(ab)use arrays for all sorts of stuff" patch. regards '#Bèr' => 'Kessels' (Am I really the only one who gets chicken-pocks everytime he writes these awkward object-imitation '#keys' ?)
On 03 Jul 2006, at 11:19 AM, Bèr Kessels wrote:
Making them predictable one by one, is a better solution, I think. Often simple patches like "make the input parameters of user_load consistent with node_load" can help a lot more then some strange "(ab)use arrays for all sorts of stuff" patch.
fapi only accepts arrays. the moment that we are submitting forms programmatically to create nodes, sending objects will be wrong. you will be sending a collection of the fields meant to be in the object.
regards '#Bèr' => 'Kessels' (Am I really the only one who gets chicken-pocks everytime he writes these awkward object-imitation '#keys' ?) except that you can't go : $obj = object( ber = kessels);
if php could do that, life would be good. it doesn't , so we're left to do what we can. ps: i am unsubscribing from this list for a while. if anyone needs to contact me, mail me directly. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Mon, 2006-07-03 at 11:05 +1000, Gordon Heydon wrote:
Hi,
I'm down on consistencies sake. I'm also into the flexability of arrays. Our occasional use of objects don't allow us to do anything useful with them. Where we do have objects, they don't have any methods. So whats the point of keeping them around?
There are a couple of reasons why we do not change.
1. Objects are easier to work with than arrays, but then again, it is 6 of 1, half a dozen of the other.
Not really. There are more functions for manipulating arrays than objects. The functional design of drupal makes methods useless. No inheritance, no private variables(no need for them without methods), basically all the cool stuff that makes OO design worth while isn't used, and can't be without a ground up rewrite of drupal as an OO application. How are they easier -> vs. [' '] come on that's an aesthetic argument. You want to say easier I have at least 10 hours in debugging file api errors that were caused by casting issues where you get arrays from FormAPI, but objects are used for files. See the various casts in upload.module.
2. What is changing going to get us? We would spend the next 6 months moving all the code so that we use arrays over objects, and we will be no further ahead. There is no gain or loss.
+1 more consistent behavior between php4 and php5 creating int arrays is an order of magnitude faster than creating objects. see: http://byster.net/?page_id=36#a2 May not work in our case, but I would definitely like to see real benchmarks of array vs object performance for assigns, creation, passing to a function by reference and as a copy then being returned. memory usage and execution time. $node gets around. I'd like to know that it is in the proper vehicle. as for effort. I heard Karoly volunteering to do regexes to make the job easier, I've already got $file ready to live as an array, but have been holding off on it since I've been focused on my own filesystem.module lately.
3. I remember reading somewhere long ago. Dries likes them over arrays.
I like them, too. I really like them when I can use the things that make them cool. Private vars/protected data space and Inheritance are two biggies for me. plus the whole oo design paradigm which to me is about reusable packaging.
This is like saying nodes are crap, and we should change them to the next greatest XYZ.
No I don't really think so. Nodes are awesome and people can justify it. I think we can base our work and decisions in sound technical judgment and experimentation... One of the things I like about drupal being procedural is we can break the object orientedness as needed. I don't like the way we use objects, because in nearly every case I've seen them, they aren't the right tool for the job there is nothing gained by using an object instead of an array. I think a technical reason for keeping objects instead of arrays would be nice to hear. I understand the social resistance. I mean it will result in real work site maintainers have to do, and there will be code some developers are going to have to write. Something will break. I think if there is some significant advantage either in performance or memory then its something we should do. Or at least argue about for a bit. I'm going to go hide in the corner and stop trolling now. *** dopry ducks.
chx helped me figure out how to benchmark tonight, so here are some results from some random tests. Tested on Mac OS X 10.4 and MAMP 1.2.1. The table in question for the fetch tests had about 2,500 records in it: PHP 4.4.2: Initialize 1 million objects: 1192.52 ms Initialize 1 million arrays: 735.15ms Fetch object: 2.34ms Fetch array: 0.81ms Make object with 1,000 properties: 3ms Make array with 1,000 keys: 2.51ms Foreach through 1,000 object properties: 3.78ms Foreach through 1,000 array keys: 2.6ms PHP 5.1.2: Initialize 1 million objects: 811.72 ms Initialize 1 million arrays: 281.83ms Fetch object: 0.94ms Fetch array: 0.72ms Make object with 1,000 properties: 1.77ms Make array with 1,000 keys: 1.38ms Foreach through 1,000 object properties: 0.98ms Foreach through 1,000 array keys: 1.21ms My horrible script is below. ;) Looks like PHP 5 did indeed speed up stuff. In PHP 4, arrays are faster across the board, but in PHP 5 it's somewhat mixed. That said, these can hardly be called "real world" tests :P but I found it kind of interesting. --- <?php include 'includes/bootstrap.inc'; drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL); echo "Initialize 1 million objects: "; timer_start('object'); for ($i = 0; $i < 1000000; $i++) { $object = new stdClass(); } $stop = timer_stop('object'); echo $stop['time'] ." ms<br />"; echo "Initialize 1 million arrays: "; timer_start('array'); for ($i = 0; $i < 1000000; $i++) { $array = array(); } $stop = timer_stop('array'); echo $stop['time'] .'ms <br />'; echo "Fetch object: "; timer_start('fetch_object'); $result = db_query_temporary("SELECT * FROM {node_revision}"); $i = 0; while ($object = db_fetch_object($result)) { $i++; } $stop = timer_stop('fetch_object'); echo $stop['time'] .'ms <br />'; echo "Fetch array: "; timer_start('fetch_array'); $result = db_query_temporary("SELECT * FROM {node_revision}"); $i = 0; while ($array = db_fetch_array($result)) { $i++; } $stop = timer_stop('fetch_array'); echo $stop['time'] .'ms <br />'; echo "Make object with 1,000 properties: "; timer_start('big_object'); $object = new stdClass(); for ($i = 0; $i < 1000; $i++) { $prop = (string)$i; $object->$prop = $i; } $stop = timer_stop('big_object'); echo $stop['time'] .'ms <br />'; echo "Make array with 1,000 keys: "; timer_start('big_array'); $array = array(); for ($i = 0; $i < 1000; $i++) { $key = (string)$i; $array[$key] = $i; } $stop = timer_stop('big_array'); echo $stop['time'] .'ms <br />'; echo "Foreach through 1,000 object properties: "; timer_start('foreach_object'); $i = 0; foreach ($object as $prop => $value) { $object->$prop = $value++; } $stop = timer_stop('foreach_object'); echo $stop['time'] .'ms <br />'; echo "Foreach through 1,000 array keys: "; timer_start('foreach_array'); $i = 0; foreach ($array as $key => $value) { $array[$key] = $value++; } $stop = timer_stop('foreach_array'); echo $stop['time'] .'ms <br />'; ?>
Here are some more, at the request of dopry: PHP 4.4.2: Send 1,000 objects with 500 properties to a function by value: 1400.54ms Send 1,000 arrays with 500 keys to a function by value: 1033.07ms Send 1,000 objects with 25 properties to a function by value: 78.26ms Send 1,000 arrays with 25 keys to a function by value: 51.39ms Send 1,000 objects with 500 properties to a function by reference: 1392.78ms Send 1,000 arrays with 500 keys to a function by reference: 1067.2ms Send 1,000 objects with 25 properties to a function by reference: 79.5ms Send 1,000 arrays with 25 keys to a function by reference: 50.37ms PHP 5.1.2: Send 1,000 objects with 500 properties to a function by value: 734.31ms Send 1,000 arrays with 500 keys to a function by value: 475.04ms Send 1,000 objects with 25 properties to a function by value: 40.94ms Send 1,000 arrays with 25 keys to a function by value: 22.07ms Send 1,000 objects with 500 properties to a function by reference: 698.29ms Send 1,000 arrays with 500 keys to a function by reference: 472.9ms Send 1,000 objects with 25 properties to a function by reference: 36.54ms Send 1,000 arrays with 25 keys to a function by reference: 25.43ms Code: <?php echo "Send 1,000 objects with 500 properties to a function by value: "; timer_start('object_by_val'); for ($i = 0; $i < 1000; $i++) { for ($j = 0; $j < 500; $j++) { $obj = new stdClass(); $prop = (string)$j; $obj->$prop = $j; } do_nothing_val($obj); } $stop = timer_stop('object_by_val'); echo $stop['time'] .'ms <br />'; echo "Send 1,000 arrays with 500 keys to a function by value: "; timer_start('array_by_val'); for ($i = 0; $i < 1000; $i++) { for ($j = 0; $j < 500; $j++) { $arr = array(); $key = (string)$j; $array[$key] = $j; } do_nothing_val($arr); } $stop = timer_stop('array_by_val'); echo $stop['time'] .'ms <br />'; echo "Send 1,000 objects with 25 properties to a function by value: "; timer_start('small_object_by_val'); for ($i = 0; $i < 1000; $i++) { for ($j = 0; $j < 25; $j++) { $obj = new stdClass(); $prop = (string)$j; $obj->$prop = $j; } do_nothing_val($obj); } $stop = timer_stop('small_object_by_val'); echo $stop['time'] .'ms <br />'; echo "Send 1,000 arrays with 25 keys to a function by value: "; timer_start('small_array_by_val'); for ($i = 0; $i < 1000; $i++) { for ($j = 0; $j < 25; $j++) { $arr = array(); $key = (string)$j; $array[$key] = $j; } do_nothing_val($arr); } $stop = timer_stop('small_array_by_val'); echo $stop['time'] .'ms <br />'; echo "Send 1,000 objects with 500 properties to a function by reference: "; timer_start('object_by_ref'); for ($i = 0; $i < 1000; $i++) { for ($j = 0; $j < 500; $j++) { $obj = new stdClass(); $prop = (string)$j; $obj->$prop = $j; } do_nothing_val($obj); } $stop = timer_stop('object_by_ref'); echo $stop['time'] .'ms <br />'; echo "Send 1,000 arrays with 500 keys to a function by reference: "; timer_start('array_by_ref'); for ($i = 0; $i < 1000; $i++) { for ($j = 0; $j < 500; $j++) { $arr = array(); $key = (string)$j; $array[$key] = $j; } do_nothing_ref($arr); } $stop = timer_stop('array_by_ref'); echo $stop['time'] .'ms <br />'; echo "Send 1,000 objects with 25 properties to a function by reference: "; timer_start('small_object_by_ref'); for ($i = 0; $i < 1000; $i++) { for ($j = 0; $j < 25; $j++) { $obj = new stdClass(); $prop = (string)$j; $obj->$prop = $j; } do_nothing_ref($obj); } $stop = timer_stop('small_object_by_ref'); echo $stop['time'] .'ms <br />'; echo "Send 1,000 arrays with 25 keys to a function by reference: "; timer_start('small_array_by_ref'); for ($i = 0; $i < 1000; $i++) { for ($j = 0; $j < 25; $j++) { $arr = array(); $key = (string)$j; $array[$key] = $j; } do_nothing_ref($arr); } $stop = timer_stop('small_array_by_ref'); echo $stop['time'] .'ms <br />'; function do_nothing_val($thing) { return $thing; } function do_nothing_ref(&$thing) { return $thing; } ?>
Karoly Negyesi wrote:
Drupal uses objects. Reasons are probably lost by now in the ancient past.
PHP is still not the best. I can write:
somefunction(array('this' => 'that'))
while there is no similar construct for objects.
Also we use arrays for links, menus, links and soon mails.
So, I propose removal of objects on practical grounds: shorter notation and a very little memory gain.
Ps. Readability issues? I do not think there is any difference.
I suspect that absent hair-splitting benchmarks, it really boils down to personal preferences. (I personally prefer object syntax for a lot of situations over array syntax.) To unilaterally forbid all use of object syntax for what will essentially be a very long time seems likewise a poor idea. Especially if it is done on "religious" grounds, i.e. personal likes without significant, demonstrable benefits. PHP5 is magnitudes better at object handling and provides a lot of OO power. Although most Drupal hosts may be on PHP4 now, they will not be in some short amount of time, perhaps 6 to 18 months. Objects in PHP, even in PHP4, provide namespaces and there is currently no other way to do that in PHP. And if I understand what you are trying to do above, you could write: somefunction((object)array('this' => 'that')); Perhaps not as terse or beautiful, but it works fine. Count me as a -1 vote unless there are some good quantitative benefits that someone can show me. ..chris
participants (16)
-
Adrian Rossouw -
Angela Byron -
Bèr Kessels -
Chris Johnson -
Darrel O'Pry -
Dries Buytaert -
Gordon Heydon -
Jeremy Epstein -
Karoly Negyesi -
Khalid B -
Larry Garfield -
Nick Lewis -
Robert Wohleb -
Shawn -
sime -
Steve Dondley