Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
node system
Priority:
Normal
Category:
Task
Assigned:
Issue tags:
Reporter:
Created:
13 Dec 2007 at 13:28 UTC
Updated:
2 Jan 2014 at 23:34 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
moshe weitzman commentedooh - nice. code looks good. i hope to test this.
Comment #2
asimmonds commentedDo we want to reconsider this again? Issue for 5.x that was marked won't-fix, http://drupal.org/node/43355
Comment #3
scoutbaker commented-1 as I tend to agree with the conclusions from the 5.x issue. For simple boolean values, 0 and 1 are good enough. If we had a negative logic situation (i.e., status = 0 means published), I could see doing this, but that's not the case for these three.
Comment #4
sasconsul commentedI vote +1 for self documenting code vs magic numbers. Magic numbers are very dangerous!
The Wikipedia page, http://en.wikipedia.org/wiki/Magic_number_(programming)#Unnamed_numerical_constant , provides some background.
In this case how much code would I have to read to find meaning of status=0 is published? I know that PHP is interpreted, so the overhead of looking up the constants is a issue. But, good software engineering should be the rule.
Comment #5
moshe weitzman commentedi think this is desireable for consistency. that issue was not marked won't fix by a committer so it really doesn't represent a "decision". the documentation here is a nice bonus.
Comment #6
Crell commentedI'm also +1 on constants over magic numbers, even when there's just 2 of them. The performance hit is so small as to not be worth mentioning. Also, it's all in compile time. If you're running an Opcode Cache, there isn't even a cycle's worth of cost.
Comment #7
pwolanin commentedA nice idea - but I have to think the patch is incomplete?
Also, if we're going down this road, there are some even more serious magic number issues in menu.inc that deserve this treatment first.
Comment #8
robertgarrigos commented+1 for this patch. Very handy for more than 2 choices and consistent with comments. Also: status = 1 means published ? not so clear as promote = 1.
+1 to look for other magic number issues but this doesn't mean this patch is incomplete. I tested it and, for me, it's RTBC
Comment #9
gábor hojtsyWell, pwolanin's point is that lots of places, the magic numbers are still used for status, promote, etc.
Comment #10
robertgarrigos commentedHe is talking about the menu.inc and I only could find some
and
but nothing else.
I did a grep also looking for '$node->status = 1' and '$node->promote = 1' and only could find the ones already patched here....so I don't know what are those magic numbers actually pwolanin is referencing to.
Comment #11
gábor hojtsyLet me give some examples. Not all of them are node status, but well... We can also look for INSERTs, where there is no such clear pattern to look for, as well as array formats for submitted forms, etc. In short I am not convinced that having a small number of these magic numbers disappear from core is what we should concentrate this close to a release. There are lots of places to introduce this if you aim for consistency.
Comment #12
pwolanin commentedI don't think something as simple as 0/1 for FALSE/TRUE needs constants very badly.
I was thinking in terms of the menu system, about the use of "(1 = a disabled menu item that may be shown on admin screens, -1 = a menu callback, 0 = a normal, visible link)" in {menu_links}.hidden as a case where the code in menu.inc is confusing because of the magic -1/0/1 system
Comment #13
robertgarrigos commented@Gabor, you are right. SQl queries should be changed also, just like comment.module does with comment status...
Comment #14
pwolanin commented@robertgarrigos -- I thiink you are volunteering for a D7 node module cleanup. I think it would be foolish to undertake revising all those (working) queries and code at this stage for D6. I'd only weakly support doing it for menu.inc for the exapmle I cited for D6 just because that it much less obvious in what the "magic" numbers mean.
Comment #15
asimmonds commentedI have a patch that I had done for the previous 5.x node constants issue as it was marked won't fix, so I had never got around to finishing and uploading it. That patch ended up being a 35KB patch (unfinished), and that's just for 5.x at the time, a current HEAD patch will probably be a bit bigger.
Comment #16
catchOk then.
Comment #17
gábor hojtsyNote that comment module uses the status constants because it has status = 0 for published and status = 1 for unpublished, and it is rather unusual.
Comment #18
robertgarrigos commented@powlanin: you are right at #12 and #14 but not that I'm volunteering (yet) ;-). theborg should say something about it first and assimmonds might almost have it.
Comment #19
theborg commented@asimmonds: Sorry, I didn't know about your patch.
I don't like magic numbers and at least this is useful for documenting purposes. I changed some SQL queries on node, blogapi and ping modules, I will take a look at Gábor's #11 queries.
Also I added the 'promoted' and 'sticky' status to admin/content/node table for testing the changes, I will remove them if you don't like it but I think it's an interface improvement.
I volunteer to clean up the node and other modules from node magic numbers but I need to know if you plan to do it with all modules magic numbers at once.
Anyway, waiting for asimmonds comments on this.
Comment #20
theborg commentedComment #21
Crell commentedRe #17: In Drupal 7 we should probably just switch those around to be standardized and be done with it. Then we can use the same constants across the board.
Comment #22
lilou commentedReroll to HEAD.
Comment #23
catchre: #17/#21 comment.module was fixed in a recent commit.
Comment #24
lilou commentedExact : #237636: Comment status field should match node status field
Comment #25
recidive commentedThese are not 'magic numbers'. node.sticky, node.published, node.promoted are (pseudo) booleans. You can read them as:
Is it sticky? Yes/No
Is it published? Yes/No
Is it promoted? Yes/No
What's wrong with that?
Unless you want to take on serious inconsistencies like comments (#17), I'm +1 to won't fix. All that I see on the patch is:
A_B = 1
A_NOT_B = 0
There are already the 'constants' TRUE and FALSE we can use for that.
Comment #26
sasconsul commentedThe problem is the word "can" in the sentence, "You can read them as:"
Anything that is up for interpretation will be interpreted incorrectly at 3 am.
Stuart
Comment #27
webchick+100 kabillion for this.
Comment #28
webchickTagging as novice. Looks like this was pretty close before it fell off the radar.
Comment #29
damien tournoud commentedAn alternative implementation strategy for this would be (as discussed earlier), to simply remove the 3am - 4am timeframe, which is actually very bad for rolling core patches.
Comment #30
floretan commentedAdded #428234: Use constants for block visibility. Same issue, but for block attributes.
Comment #31
robertgarrigos commentedrerolled to HEAD. I left out the extra columns added by theborg at #19 in order to not interefere with actual interface works. If you are happy with this, I may add other constants found in other core modules, as this patch only acts on node module.
Comment #33
robertgarrigos commentedsorry, I missed the patch :-)
Comment #34
lilou commentedComment #35
pwolanin commentedI really don't see this as helpful in terms of understanding the code. @webchick - why is this not a "won't fix"?
Comment #36
Crell commented@pwolanin: You don't see how replacing undocumented magic numbers with named constants improves code readability?
Comment #37
recidive commentedThey are not "magic numbers" but booleans, we can add schema support to booleans and change those table fields to booleans (optional) and change code to use TRUE/FALSE instead of 1/0 and ensure they are correct handled by db layer.
Comment #38
pwolanin commented@Crell - no I really don't if the only possible values are 1/0
Comment #39
moshe weitzman commentedWe have had great success replacing 1/0 with constants like COMMENT_PUBLISHED/COMMENT_UNPUBLISHED. This looks good. It isn't complete as far as i can tell, but once it is it is RTBC IMO.
Comment #40
chx commentedI tend to agree that booleans do not need constants and that comment had it backwads and there it's useful.
Comment #41
chx commentedHowever... if I remember correctly comments now are fixed and yet we kept the constants. I am unsure how to proceed... do we want to remove them, then?
Comment #42
dries commentedCommitted to CVS HEAD. Thanks.