On Fri, Feb 1, 2019 at 12:59 PM Vern Paxson wrote:
> I don't see how it helps with
> deprecating existing parameters (which seems would be better served with
> some sort of &deprecated attribute),
Support for &deprecated in parameters is part of the changes.
But if we don't allow the user to im
> The compelling use-case I'd say is the ability to change/deprecate
> event parameters without suddenly breaking people's code since that
> has come up many times already.
I see how it allows adding new parameters. I don't see how it helps with
deprecating existing parameters (which seems would
On Fri, Feb 1, 2019 at 11:36 AM Seth Hall wrote:
> On 1 Feb 2019, at 11:24, Robin Sommer wrote:
> I think the change to using names does make things a bit more confusing
> for users
Note that the patch makes matching based on parameter name optional.
One can still pick their own parameter names
On 1 Feb 2019, at 11:24, Robin Sommer wrote:
> It's a nice a idea to relax parameter passing to work by name, and
> allow subsets. However, I can't quite get myself to really like it in
> this form, because it *looks* like an error to not have matching
> argument lists. Is there some syntax tha
On Fri, Feb 1, 2019 at 10:24 AM Robin Sommer wrote:
> On Thu, Jan 31, 2019 at 16:29 -0800, Vern Paxson wrote:
>
> > > global my_event: event(a: count, b: string);
> > > event my_event(b: string)
> > > { print "my_event", b; }
>
> it *looks* like an error to not have matching
> arg
On Thu, Jan 31, 2019 at 16:29 -0800, Vern Paxson wrote:
> > global my_event: event(a: count, b: string);
> > event my_event(b: string)
> > { print "my_event", b; }
> Is there a compelling use-case that's motivating this change?
I'm sure the main use case is changing an existin
On Thu, Jan 31, 2019 at 6:29 PM Vern Paxson wrote:
> > * user doesn't care about parameter 'a', so they shouldn't have to list it
> > * it makes it easier for to deprecate/change event parameters
>
> This seems like a pretty niche pair of benefits. Is there a compelling
> use-case that's motivat