Use & instead of | in the value of [CallWith] / [SetterCallWith]

Use & instead of | in the value of [CallWith] / [SetterCallWith]

[CallWith=ScriptExecutionContext|ScriptState] meant that both the
ScriptExecutionContext AND the ScriptState would be passed as
arguments to the implementation (not one OR the other).

This patch changes the semantics for those IDL extended attributes
to make it less confusing. Proper usage is now:
[CallWith=ScriptExecutionContext&ScriptState]

R=haraken

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=153217

[marja, 2013-06-26 11:37:14]

I don't think this is any less confusing; the flag-like syntax

foo = flag1 | flag2;

is intuitive. Does this change make this somehow more consistent with anything,
or... why?

[do-not-use, 2013-06-26 11:41:04]

On 2013/06/26 11:37:14, marja wrote:
> I don't think this is any less confusing; the flag-like syntax
> 
> foo = flag1 | flag2;
> 
> is intuitive. Does this change make this somehow more consistent with
anything,
> or... why?

Well it is consistent with existing conditionals:
[Conditional=A|B] != [Conditional=A&B]

It will also be consistent with https://codereview.chromium.org/17826003/ when
it lands.

[haraken, 2013-06-26 11:44:44]

LGTM

[do-not-use, 2013-06-26 11:58:10]

Marja, are you still opposed to this change?

I do think it makes things a bit less confusing. Kentaro had this idea
originally so it is not just me at least.

[Nils Barth (inactive), 2013-06-26 12:11:49]

The flag-like syntax is appealing, but as Christophe notes, we're putting
logical expressions in the arguments, not just flags.
Since we want both logical OR and AND, using | and & for these seem reasonably
clear.

Maybe we should distinguish flag arguments from logical expression arguments?
We could use || and && if we want to be explicit that these are logical OR/AND,
so we'd have
  foo=flag1|flag2
for flag-type arguments, and
  [Conditional=A||B] or [Conditional=A&&B]
for logical expression arguments
...which emphasizes that these have different semantics.

Also, in IDLAttributes.txt we use Attr=X|Y to mean that Attr=X or Attr=Y are
both ok, which might be further confusing.
We could change IDLAttributes.txt to use ',' if we want to clearly distinguish
these as just a list.

[do-not-use, 2013-06-26 12:20:43]

On 2013/06/26 12:11:49, Nils Barth wrote:
> The flag-like syntax is appealing, but as Christophe notes, we're putting
> logical expressions in the arguments, not just flags.
> Since we want both logical OR and AND, using | and & for these seem reasonably
> clear.
> 
> Maybe we should distinguish flag arguments from logical expression arguments?
> We could use || and && if we want to be explicit that these are logical
OR/AND,
> so we'd have
>   foo=flag1|flag2
> for flag-type arguments, and
>   [Conditional=A||B] or [Conditional=A&&B]
> for logical expression arguments
> ...which emphasizes that these have different semantics.
> 
> Also, in IDLAttributes.txt we use Attr=X|Y to mean that Attr=X or Attr=Y are
> both ok, which might be further confusing.
> We could change IDLAttributes.txt to use ',' if we want to clearly distinguish
> these as just a list.

Where do you suggest we use "foo=flag1|flag2" ? It appears "|" is currently only
used for CallWith and Conditional. Unless we have a need for both '|' and '||',
I don't see a need for distinguishing.

[marja, 2013-06-26 12:43:24]

On 2013/06/26 11:58:10, cdumez wrote:
> Marja, are you still opposed to this change?
> 
> I do think it makes things a bit less confusing. Kentaro had this idea
> originally so it is not just me at least.

I'm not opposing anything, I'm just drive-by commenting :)

[do-not-use, 2013-06-27 06:00:53]

On 2013/06/26 12:20:43, cdumez wrote:
> On 2013/06/26 12:11:49, Nils Barth wrote:
> > The flag-like syntax is appealing, but as Christophe notes, we're putting
> > logical expressions in the arguments, not just flags.
> > Since we want both logical OR and AND, using | and & for these seem
reasonably
> > clear.
> > 
> > Maybe we should distinguish flag arguments from logical expression
arguments?
> > We could use || and && if we want to be explicit that these are logical
> OR/AND,
> > so we'd have
> >   foo=flag1|flag2
> > for flag-type arguments, and
> >   [Conditional=A||B] or [Conditional=A&&B]
> > for logical expression arguments
> > ...which emphasizes that these have different semantics.
> > 
> > Also, in IDLAttributes.txt we use Attr=X|Y to mean that Attr=X or Attr=Y are
> > both ok, which might be further confusing.
> > We could change IDLAttributes.txt to use ',' if we want to clearly
distinguish
> > these as just a list.
> 
> Where do you suggest we use "foo=flag1|flag2" ? It appears "|" is currently
only
> used for CallWith and Conditional. Unless we have a need for both '|' and
'||',
> I don't see a need for distinguishing.

Nils, could you please follow up? Can the patch land this way or do you have a
better proposal? I still not clear regarding where you want to use | and ||
(which actual extended attributes?).

[haraken, 2013-06-28 03:35:11]

Nils is out of office. I think it's ok to land your CL as is. You can talk to
Nils later and address the issue in a follow-up.

[commit-bot: I haz the power, 2013-06-28 06:17:21]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@sisa.samsung.com/17851002/1

[commit-bot: I haz the power, 2013-06-28 07:56:03]

Change committed as 153217

[Nils Barth (inactive), 2013-07-01 05:45:09]

On 2013/06/27 06:00:53, cdumez wrote:
> On 2013/06/26 12:20:43, cdumez wrote:

> > Where do you suggest we use "foo=flag1|flag2" ? It appears "|" is currently
> only
> > used for CallWith and Conditional. Unless we have a need for both '|' and
> '||',
> > I don't see a need for distinguishing.
> 
> Nils, could you please follow up? Can the patch land this way or do you have a
> better proposal? I still not clear regarding where you want to use | and ||
> (which actual extended attributes?).

Sorry for the late reply – missed update in the pile!
Patch (landed) is fine; since this isn't used widely, there's no need for
distinguishing,
as you note.