622178 - Change JS shell options interface away from toggles

Status: RESOLVED DUPLICATE of bug 668095

(Core :: JavaScript Engine, enhancement)

Description

[Chris Leary [:cdleary] (not checking bugmail)]

The current interface permits a user to toggle an option flag before/after any given file is loaded. For example:

    ./js -x -f file1.js -x -f file2.js

I think we should splurge on some long options to make the usage more obvious/explicit for unintuitive options; i.e.

    ./js --enable-xml -f file1.js --disable-xml -f file2.js

The intended effect of the toggling is much more apparent this way.

(Note that my mq for bug 595691 remove JS_ToggleOptions as public API: following that, "toggling" is shell-specific behavior.)

Comment 1

[Paul Biggar]

I was thinking about this, but it would probably re

Comment 2

[Paul Biggar]

(In reply to comment #1)
> I was thinking about this, but it would probably

require a library to do it right. Boost::program (
http://www.boost.org/doc/libs/1_45_0/doc/html/program_options.html) and Google-gflags (http://google-gflags.googlecode.com/svn/trunk/doc/gflags.html) seemed to be the best ways to do this last time I looked around (never used them though).

Comment 3

[Chris Leary [:cdleary] (not checking bugmail)]

(In reply to comment #2)
> (In reply to comment #1)
> require a library to do it right

I'd prefer we do it wrong than import boost. :-)

It shouldn't be difficult to whip up a decent optparser in < a day with reasonable functionality -- I'm happy to take the assignment, forgot to do that at first.

Comment 4

[Paul Biggar]

(In reply to comment #3)
> It shouldn't be difficult to whip up a decent optparser in < a day with
> reasonable functionality

Well..., no. I agree that you'll get something working, but I suspect it will have the same weird edge cases as all hand-rolled options parsers (which is kinda the problem we're solving). Is there a reason not to use google-gflags?

(FWIW, I'm sure Boost will arrive in our code base sooner or later; it does to any large C++ project :))

Comment 5

[Chris Leary [:cdleary] (not checking bugmail)]

(In reply to comment #4)
> Is there a reason not to use google-gflags?

There's no reason to take an external dependency for something this simple and unimportant. I promise that meeting our needs won't take long.

Comment 6

[Nicholas Nethercote [inactive]]

In Valgrind, almost every option is written --key=value.  Even boolean ones, eg. --xml=yes.  That way, boolean options have the same form as non-boolean one.  And it makes option parsing much easier because there are fewer spaces to deal with!

Comment 7

[Paul Biggar]

(In reply to comment #6)
> In Valgrind, almost every option is written --key=value.  Even boolean ones,
> eg. --xml=yes.  That way, boolean options have the same form as non-boolean
> one.  And it makes option parsing much easier because there are fewer spaces to
> deal with!

<bikeshedding>

The Valgrind way goes against what almost all other command-line programs do. I recall being confused the first time I tried --attach-db in Valgrind. I don't think we're going to like `--methodjit=yes --profiling=yes --tracejit=yes`.

I think The Art of Unix Programming is the definitive reference here: http://catb.org/~esr/writings/taoup/html/ch10s05.html

</bikeshedding>

Comment 8

[Nicholas Nethercote [inactive]]

Fine, fine, just please don't pull in Boost.

Comment 9

[Paul Biggar]

(In reply to comment #5)
> > Is there a reason not to use google-gflags?
> 
> There's no reason to take an external dependency for something this simple and
> unimportant. I promise that meeting our needs won't take long.

One of the things I took away from Anthony LaForge's talk during the work week, was how well external dependencies were working for Chrome.

In general, I think we should be moving towards have more external libraries, not less. Code we write from scratch is code we have to maintain (and code others have to maintain if you move on). We got in this mess because we hand-rolled the options parser; I'm not sure doing it again (but better!) is advised.

But I'm sure you've heard these arguments before, so I'll be quiet now.

Comment 10

[Chris Leary [:cdleary] (not checking bugmail)]

We didn't *change* it away from toggles (for backwards compatibility), but we did add long forms and write a proper option parser in bug 668095. I think that was what I originally took assignment for, and it's probably a bunch of infra work to switch away from toggles, so I think I'm going to mark this as a dupe of that to say that the main work is done!