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 moving more parameters into records anyway. If we're worried about backwards compatibility, then maybe we have a built in version number in each record. Whenever fields are added/removed, or there are more subtle contextual changes, the version number could increase. As a concrete example, the is_server parameter of the ssh_capabilities event was being set backwards (effectively as "is_client.") I introduced a change[1] where the is_server parameter was corrected, but now how to interpret the value depended on the Bro version. This is a very subtle case, where no field was added or deleted, but users were still expected to change their code. --Vlad [1] - <https://github.com/zeek/zeek/pull/191> On Wed, Feb 6, 2019 at 5:10 PM Seth Hall <s...@corelight.com> wrote: > > > 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 parameters but that > would still force existing code to be updated so that it could keep > using the existing model. > > 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? Like, should we have some specialized syntax for > specifying named parameter use? Should we have something like anonymous > records where you specify a variant of record syntax for named > parameters? (ruby comes to mind for this, but I've seen people do > similar things in c too) > > I'm just wondering if we should do a one-time source compatibility break > to could get some tangible benefit in usability or understanding. I > think Robin's concern is about backing us into a corner with a syntax > that makes code confusing. Is that correct Robin? > > .Seth > > -- > Seth Hall * Corelight, Inc * www.corelight.com > _______________________________________________ > zeek-dev mailing list > zeek-dev@zeek.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev >
_______________________________________________ zeek-dev mailing list zeek-dev@zeek.org http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev