Dear Paul,
That sounds reasonable to me.
I suggest to try it (and I will) later if reduce arg_count_max to 3 works
fine at present, so we can reduce the affect from 8215622 ASAP. Then I will
consider it when refining the patch for adding more options (such as
"incremental" for jmap histo , described in 8215623).
what do you think?
BRs,
Lin
________________________________________
From: Hohensee, Paul <[email protected]>
Sent: Thursday, February 28, 2019 7:48:06 PM
To: 臧琳; David Holmes; Yasumasa Suenaga
Cc: [email protected] [email protected]
Subject: Re: Protocol version of Attach API
I'd like to propose an alternative approach, namely, we could add another
argument parsing feature on top of the old functionality intact and leave the
latter intact. We currently have just a single constant
AttachOperation::arg_count_max, which the patch changed from 3 to 4. We could
leave it at 3 and add another constant, call it extra_arg_count, and set
extra_arg_count to 1 for now. The required number of attachListener args stays
at 3, and we add code that checks for up to extra_arg_count arguments. As part
of the new code, add a sentinel argument value (all 1s?) to signal end of extra
arguments, rather than overloading the null string, since a null string is a
valid argument. Opinion(s)?
Thanks,
Paul
