On Tue, Feb 19, 2019 at 10:55 PM Robin Sommer wrote:
>
> On Tue, Feb 19, 2019 at 08:28 -0600, Jonathan Siwek wrote:
>
> > we pick points in time as an "event" and associate various bits of
> > data with them, then users declare their interest in some subset of
> > that data. Most natural way for
On Tue, Feb 19, 2019 at 1:27 PM Vern Paxson wrote:
> > Which particular user errors were a concern?
>
> The main one being when there's an API change that's *not* backward
> compatible, and the user doesn't update their scripts to be in conformance
> with it as is required. Clearly something
On Mon, Feb 18, 2019 at 16:32 -0800, Vern Paxson wrote:
> event foo%(a: string%)
> event foo%(a: string, b: string%);
I like this. It addresses my main concern of making it clear what's
happening. If I see an implementation of the event and look up the
prototype, I'll find both
> > (4) avoid certain forms of user errors
>
> Which particular user errors were a concern?
The main one being when there's an API change that's *not* backward
compatible, and the user doesn't update their scripts to be in conformance
with it as is required. Clearly something we'll in general
On Mon, Feb 18, 2019 at 6:46 PM Vern Paxson wrote:
> Suppose "event foo(a: string)" is an event to which we want to add
> a second parameter, b: string. We could express this in event.bif as:
>
> event foo%(a: string%)
> event foo%(a: string, b: string%);
Nice idea. I also
This thread got backburnered for me due to other $dayjob stuff, but returning
to it now, one thing I wondered would be what if instead of just allowing
missing parameters as a way to support changing event interfaces, we
introduced an explicit notion of deprecation, as follows.
Suppose "event
On 06/02/2019 21:00, Jon Siwek wrote:
> On Wed, Feb 6, 2019 at 1:30 PM Vlad Grigorescu wrote:
>
>> I _think_ I like Seth's idea of records, but I'm still thinking it through.
>> It would formalize a growing trend towards moving more parameters into
>> records anyway. If we're worried about
On Wed, Feb 6, 2019 at 1:30 PM Vlad Grigorescu wrote:
> I _think_ I like Seth's idea of records, but I'm still thinking it through.
> It would formalize a growing trend towards moving more parameters into
> records anyway. If we're worried about backwards compatibility, then maybe we
> have a
On Wed, Feb 6, 2019 at 10:51 AM Seth Hall wrote:
> One thing I've been thinking about a little bit is how much we're
> concerning ourselves with maintaining perfect backward compatibility and
> if there is some benefit to breaking a bit of backward compatibility for
> something truly nicer?
I think compatibility is a growing issue with scripts being released as
plugins. I'm already seeing some code shift to:
> @if (Version ...)
> new event
> @else
> old event
I _think_ I like Seth's idea of records, but I'm still thinking it through.
It would formalize a growing trend towards
On 6 Feb 2019, at 10:48, Jon Siwek wrote:
> We can't magically change that user's code. We have to, somehow, let
> that work as it is, without user intervention.
Yeah, I think that's right. I was trying to come up with some proposed
model for indicating that you're specifying named
On Tue, Feb 5, 2019 at 7:40 PM Robin Sommer wrote:
> The following would be even worst in terms of confusion:
>
> global my_event: event(a: string, b: string);
> event my_event(b: string)
>
> Now I need to know if the language goes by order of parameters or by
> parameter name.
The
On Fri, Feb 01, 2019 at 11:17 -0600, Jonathan Siwek wrote:
> > > > global my_event: event(a: count, b: string);
> > > > event my_event(b: string)
> > > > { print "my_event", b; }
> Did it look like an error in the sense of the user making a mistake or
> in the sense of
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 attribute),
Support for in parameters is part of the changes.
But if we don't allow the user to immediately remove the
> 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 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
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
>
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
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
> global my_event: event(a: count, b: string);
>
> event my_event(b: string)
> { print "my_event", b; }
>
> Which is good because:
>
> * 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
Just wanted to draw more attention/feedback to a proof-of-concept
patch I just made:
https://github.com/zeek/zeek/pull/262
Basically lets us do this:
global my_event: event(a: count, b: string);
event my_event(b: string)
{ print "my_event", b; }
Which is good because:
* user
21 matches
Mail list logo
