Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
We're in the process of cleaning up JS, meaning that capitalized variables are meant to be Constructors, which Drupal isn't.
While moving towards more modular javascript we're going to be using the Drupal
variable less (still going to be using it indirectly). Writing it in all caps discourage people from messing with it, which is a good thing.
Comment | File | Size | Author |
---|---|---|---|
#31 | core-js-rename-drupal-1754344-9.patch | 175.25 KB | seutje |
#8 | core-js-rename-DRUPAL-1754344-8.patch | 175.25 KB | seutje |
#8 | core-js-rename-DRUPAL-1754344-8.interdiff.txt | 280 bytes | seutje |
#6 | core-js-rename-DRUPAL-1754344-6.patch | 175.25 KB | nod_ |
#1 | rename-Drupal-DRUPAL-1754344-1.patch | 171.85 KB | larowlan |
Comments
Comment #1
larowlanLet's see what the testbot says.
Comment #2
nod_Haha, that's awesome!
Seems to work well for me :)
Comment #3
larowlansed got me most of the way there: ;)
The rest were in tests and comments
Comment #5
larowlanAjaxFramework tests failing
Comment #6
nod_got a couple more in inline JS, no idea why it's failling ATM.
Comment #8
seutje CreditAttribution: seutje commentedlooks like you removed a line from the top of
locale_test.js
and I guess it ignores the first line? (o.O)My head hurts now :(
Comment #9
seutje CreditAttribution: seutje commentedwent ahead and updated the summary in #1664940: [Policy, patch] Decide on JSHint configuration
Comment #10
nod_So now the question is: when do we get this in and break every single JS patch in the queue?
I propose we wait until the jshint and the current selector clean-up issues are in to rtbc this one.
Comment #11
tim.plunkettThat's the entire thought process behind all JS files having
DRUPAL
in them?
Comment #12
xjmThis doesn't seem like a good idea to me... can you provide an example of ALLINCAPSWORDOBJECT in another project, or a reference to the standard you're referencing?
Comment #13
cweagans-1 from me too. DRUPAL is not pleasant to type. Why don't you want people "messing with" the Drupal global?
Comment #14
nod_Well, I learned JS from Douglas Crockford which encourages this: http://javascript.crockford.com/code.html, the YUI library follow that, (and the old version as well, Y, and YAHOO)
Usually, all caps means it's a global variable, and a lot of JS coder will think that. The main issue here is that it's capitalized. This is not a constructor, it should be either all caps or all lowercase but can't stay like that now that we are cleaning up the naming of the rest of the things with jshint.
So well I don't really care if it's all caps or small caps, as long as it's not
Drupal
which is misleading.Comment #15
ro-no-lo CreditAttribution: ro-no-lo commentedAll CAPS look like a constant to me in *any* language.
Comment #16
nod_well, constants don't exists in JS so no chances of that happening.
Comment #17
corbacho CreditAttribution: corbacho commentedI don't want to bike-shed the thread, but DRUPAL looks like a constant like ronan says. JavaScript doesn't have constants but anyway it's used like that as convention. For example Backbone.VERSION.
"Drupal" is *more* than a global variable. It's a namespace, so we could do an exception. And it's not fun to break backwards compatibility unless is necessary
I took some time to have a look to different frameworks / popular websites and check their global namespace names, you can see a pattern of having upper-case first letter:
Firebug (Firebug Lite), Modernizr, Github, Mozilla (mdn), yepnope, requirejs, FB (Facebook Button), jQuery, DISQUS, gaGlobal (google analytics), Aloha, Joomla, MooTools, Cufon, Backbone, StackExchange (Stackoverflow), Mollom, Editor ( this last one actually in the JSHint webpage )
Notice that DISQUS and YAHOO have all caps company names
Comment #18
nod_Then again it doesn't really matter, with the file-level closure we have we can name it whatever, and put Drupal as the parameter if people still want to keep using it.
First: We follow the Capitalized constructor name rule, that's in our JSHint configuration. See the relevant thread.
In the list you forgot about JSHINT, html5, google (the api, not the stats thing) and hundreds of others. And yes there are also hundreds of counter-examples. My point, we picked a standard way of doing things, this does not fit it then needs to be changed. It's weird enough trying to get in Drupal JS we don't need to make that worst.
My aim here is to get a lot of real JS devs to come to drupal. This will help, keeping the current naming isn't helping anyone and as the jQuery thing showed, people don't really care (except a handful maybe). You guys are all nice and all but if you want full offline support for Drupal in core one day, we need many more very good JS devs around to actually make that happen. And right now this change is a little piece of the problem why we don't have them with us right now.
Comment #19
nevets CreditAttribution: nevets commentedThis seems like another change without real purpose that will break contributed modules, -1 from me.
Comment #20
cweagansBut it's not hurting anyone either. I write a crapload of Javascript for my personal Drupal projects and the fact that I don't have to write DRUPAL.behaviors all the time seems very nice. Also, all caps DRUPAL looks ugly and I would really hate to work on Javascript if it were that way (more than I already do).
Not sure what this was. Care to share? I'm thinking that the problem isn't so much that people didn't care: it's just that they weren't aware.
Offline support? That sounds insane, but if you think it's cool, more power to you. I don't think it's a core thing though, and I really don't believe that writing DRUPAL in all caps is going to bring in more JS devs.
Comment #21
nod_As I said ealier,
DRUPAL
,drupal
I don't care, just notDrupal
.About the offline thing it's not insane, if you think about it that's what mobile should be about, ask Damien Tournaud he'll tell you all about it :) It's not just that, we have a lot of other JS issues that need real JS people.
Comment #22
cweagansIf we're just going to wrap it in a Compatibility Thingy ™ anyways, then what's the point? There has been no compelling reason to make this change and two reasons against it (DRUPAL is more effort to type, and it's a needless backwards compatibility break).
I will again maintain that this change is unnecessary, it will not have the benefits that you think it will, it will annoy people, and it will not attract JS devs to Drupal.
Comment #23
nod_This change alone won't get more people obviously, I'm looking at the bigger picture and this is a dirty spot on the picture. seutje was telling me on IRC that he got questions from devs about the naming. It's not just me or him. I'm showing the closure thing as a backward compatibility measure. If I have my way we won't even need the closure anymore but that's another story.
To be fair I hadn't tagged the issue to make it part of the bigger changes that have been happening since January.
My question to you is: how do you justify that you can't do
new Drupal
even ifDrupal
is capitalized?(edit) the comment about DRUPAL being more effort to type is spot on, we don't really want people writing it to begin with (and this ties into our weird behaviors system). There are a lot of things connected to this, it's not just a naming issue.
Comment #24
cweagansYou have to justify things getting into core, not the other way around.
Look, if you're going to refactor a bunch of javascript so that a dev doesn't ever need to type Drupal.behaviors, be my guest. I might even help with it. But until that happens, this issue should be postponed, because if that other cleanup doesn't happen, writing Drupal javascript turns into a PITA with no extra benefit.
That is, fix the underlying problems, and THEN fix the naming issue and I'm happy.
Comment #25
nod_The justification for this is here: http://drupal.org/node/172169#constructors and #1664940: [Policy, patch] Decide on JSHint configuration. It's already in core and has been for a long time. It just wasn't enforced before.
I'm one of the guys maintaining this stuff, coherence is good for me and it's good for the users. Right now I can't tell people: "whatever you see something capitalized, it's a constructor you can (and must) use new on it". I'm trying to lower the barrier of entry for new people (should I say new People? :) why is that so bad especially given that we have an easy way of porting old code?
Comment #26
nod_To answer #11 it's not just that, see above.
Comment #27
Kiphaas7 CreditAttribution: Kiphaas7 commented+1 on not using
Drupal
. It's not a constructor, therefore inconsistent. either drupal or DRUPAL, I don't care. But I also agree that it seems a bit overkill to break backwards compatibility for this. Unless there is a greater plan behind a seemingly silly name change......So what is this greater plan? What do you actually want to do here? Remove the .behaviors stuff? Sounds interesting, please elaborate/link to the relevant issue :). If this is a stopgap solution on the move to greater things, where Drupal.behaviors is destroyed anyway, you might get a lot less resistance here.
Comment #28
nod_Yep I can make a write-up of my plan, need to talk that through with a few other people before making an actual write-up, but all that can only happen if #1737148: Explicitly declare all JS dependencies, don't use drupal_add_js lands and not in a few weeks or we'll run out of time anyway.
Comment #29
corbacho CreditAttribution: corbacho commentedAnother point against all-caps variables: Google Closure Compiler will treat All caps words as constants
https://developers.google.com/closure/compiler/docs/error-ref
What if I place a constructor inside the Drupal namespace? Doesnt' look more readable with Drupal than drupal ?
var test = new Drupal.whatever.Constructor();
"whatever you see something capitalized is a constructor"
Well, that's not true even in native JavaScript. Math is not a constructor, it's only a namespace for a group of constants and methods...
In the other hand, I see that you want to force consistency in the code, and I respect you for that. In that case I would go for "drupal" then, because also there is a big trend specially among node.js developers to have all lower-case packages names. But anwyay if we want to remove the drupal namespace at some point, maybe all this mess is not worth it.
The big list of examples I put in #17 have "real" JavaScript developers behind, so I think that it's a pattern very familiar among JavaScript developers. Don't agree with "this is scaring JavaScript developers"
Comment #30
nod_The namespace won't disappear, it'll just be kind of 'not used that much anymore' we'll get access directly to the objects contained inside.
I'm fine with the lowercase version (it's covered by the trademark same as Drupal or DRUPAL so that shouldn't change anything). Then again, this is not a node package. That would allow us to match what's going on better in hook_library_info() though, which is good.
Can someone update the patch based on #8 and the command in #3?
Comment #31
seutje CreditAttribution: seutje commentedComment #32
seutje CreditAttribution: seutje commentedUpdated #1664940: [Policy, patch] Decide on JSHint configuration
Comment #33
sunAll-uppercase didn't fly at all for me, for the reasons outlined by others already, so I appreciate that's no longer being proposed.
While lowercase
drupal
works, I don't really see what's problematic withDrupal
compared tojQuery
though.As others have mentioned, this is a quite heavy API change and will require 13,000+ contributed as well as an unknown amount of custom modules to be rewritten accordingly. That said, the upgrade path is simple. But nevertheless, we better have very good reasons for changing it.
Comment #34
nod_I'm not hard to please,
dRupal
works just as well, pretty ugly though. The issue is the first capital letter which kinda violate our coding standards among other things.Comment #35
nevets CreditAttribution: nevets commentedFix the coding standard then :)
Comment #36
nod_Meh.