<div dir="ltr"><div>I think compatibility is a growing issue with scripts being released as plugins. I'm already seeing some code shift to:</div><div><br></div><div>> @if (Version ...)</div><div>> new event</div><div>> @else</div><div>> old event</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> --Vlad<br></div><div><br></div><div>[1] - <<a href="https://github.com/zeek/zeek/pull/191">https://github.com/zeek/zeek/pull/191</a>></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 6, 2019 at 5:10 PM Seth Hall <<a href="mailto:seth@corelight.com" target="_blank">seth@corelight.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 6 Feb 2019, at 10:48, Jon Siwek wrote:<br>
<br>
> We can't magically change that user's code. We have to, somehow, let<br>
> that work as it is, without user intervention.<br>
<br>
Yeah, I think that's right. I was trying to come up with some proposed <br>
model for indicating that you're specifying named parameters but that <br>
would still force existing code to be updated so that it could keep <br>
using the existing model.<br>
<br>
One thing I've been thinking about a little bit is how much we're <br>
concerning ourselves with maintaining perfect backward compatibility and <br>
if there is some benefit to breaking a bit of backward compatibility for <br>
something truly nicer? Like, should we have some specialized syntax for <br>
specifying named parameter use? Should we have something like anonymous <br>
records where you specify a variant of record syntax for named <br>
parameters? (ruby comes to mind for this, but I've seen people do <br>
similar things in c too)<br>
<br>
I'm just wondering if we should do a one-time source compatibility break <br>
to could get some tangible benefit in usability or understanding. I <br>
think Robin's concern is about backing us into a corner with a syntax <br>
that makes code confusing. Is that correct Robin?<br>
<br>
.Seth<br>
<br>
--<br>
Seth Hall * Corelight, Inc * <a href="http://www.corelight.com" rel="noreferrer" target="_blank">www.corelight.com</a><br>
_______________________________________________<br>
zeek-dev mailing list<br>
<a href="mailto:zeek-dev@zeek.org" target="_blank">zeek-dev@zeek.org</a><br>
<a href="http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev" rel="noreferrer" target="_blank">http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev</a><br>
</blockquote></div>