Bug 20369 - OpCodes violate the WebKit style guidelines... and should be autogenerated
Summary: OpCodes violate the WebKit style guidelines... and should be autogenerated
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Nobody
URL: http://trac.webkit.org/browser/trunk/...
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-12 20:19 PDT by Eric Seidel (no email)
Modified: 2011-07-21 22:57 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2008-08-12 20:19:01 PDT
OpCodes violate the WebKit style guidelines... and should be autogenerated

Kinda two bugs in one... i guess.

Am I missing something here?  Why would they use foo_bar instead of FooBar?  And why not autogenerate Opcodes.h using a hacked version of one of the autogen scripts from WebCore or a spankin new ruby/python/whatever-that's-not-perl verison?
Comment 1 Maciej Stachowiak 2008-08-12 20:23:00 PDT
We say foo_bar instead of FooBar because we want the enum values to match the way the opcodes will look in bytecode assembly dumps. In assembly-style languages, StudlyCaps would look funny. A patch that adds a brief comment explaining this would be ok if you think it is necessary.

I also think autogenerating the opcode list is a good idea. We'd take a patch to do that.
Comment 2 Gavin Barraclough 2011-07-21 22:57:45 PDT
This hasn't changed in nearly 3 years, so I think it is only pragmatic to consider this 'won't fix'.  :-)

I think we may want to revisit this position, but with no plan on making this change in the near future I don't think this bug is usefully tracking intended work for now.  As such, I think closing for now is wisest.