If they are direct FFI bindings then we can't rename them, since those
are the actual exported symbols names from mozjs. If they are custom
glue code we've written, my preference is to keep the UpperCamelCase
format if they are only transparent wrappers around C++ methods like
https://github.com/servo/rust-mozjs/blob/437460db87ef3c10f34388fc565d590110ead571/src/jsglue.cpp#L1049-L1117
..
On 2020-01-10 1:39 a.m., Cheng You Bai wrote:
No objection either! but, currently, there are some functions which will be
communicated with mozjs bindings are named in camel case.
Would it be good to keep them in camel case way? (ex.
*HostResolveImportedModule* for *SetModuleResolveHook*)
On Fri, Jan 10, 2020 at 5:59 AM Simon Sapin <simon.sa...@exyr.org> wrote:
On 09/01/2020 22:33, Josh Matthews wrote:
After coming across an instance of a non-snake case variable name that
didn't trigger any compiler warnings, I discovered that we disabled that
warning for the script crate 5 years ago
(
https://github.com/servo/servo/commit/dc86e8365495acc87b983a290bb7277a37a5247f#diff-7efb30b262e93375ff2af348d5a870f9R11
).
Any objections to re-enabling it in Servo-specific code throughout the
project and fixing the existing instances?
No objection, but fixing may be non-trivial. Changing that `allow` to
`deny` produces:
error: aborting due to 368 previous errors
It looks like many of these names are generated from WebIDL, so this might
require
codegen change (not just renames in source code).
--
Simon
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
