functions truly as globals?

Development
1

At scriptland, when we define function prototypes we define them as globals but they seem to be turned into consts in the core. Does it make sense to actually make them globals?

It would allow me to do runtime monkey patching… which I'm not saying I'd ever do (wink, wink). But it would make runtime instrumentation and measurement significantly easier for some things. Here's an example of what I'd like to be able to do…

global some_func: function(): string;

function some_func(): string
  {
  return "Original function";
  }

function my_func(): string
  {
  return "monkey patched!";
  }

event bro_init()
  {
  some_func = my_func;
  some_func();
  }

Hopefully this would print "monkey patched!".

Are there any conceptually any major problems with doing this? We should still be able to do parse time typing correctly in this case too I believe.

  .Seth

2

Please, no ... That's not only hurting readability profoundly but also
prevents function-level code optimization. Just imagine the impact
once we start compiling scripts ...

Robin

3

Cool, I agree. I just had to make sure. :slight_smile:

  .Seth

4

  some_func = my_func;

Please, no ... That's not only hurting readability profoundly but also
prevents function-level code optimization. Just imagine the impact
once we start compiling scripts ...

Doesn't readability improve if it makes functions behave in a way more consistent w/ other data types? E.g. if you don't want a value to change at run-time, use the "const" modifier, but if you do, use "local" or "global" depending on what scope is appropriate (though actually using the later with that intention isn't recommended or whatever we want to do/say about it).

Right now, the rules for whether you can assign to a variable of function type at run time are a bit dicey. I think you can always assign a function value if it's "local". And you can actually assign to a "global" only if it doesn't already have a value (a function body/definition). Most people probably don't encounter these, but I do think it is jarring.

Changing most/all existing "global" function declarations to use "const" instead would help some, but what about the other inconsistencies?

- Jon

5

I think that in addition to changing those to const we'd change Bro to not accept creating "global" functions.

Are there other inconsistencies?

  .Seth

6

I think that in addition to changing those to const we'd change Bro to not accept creating "global" functions.

You still effectively have global functions if you have a global record w/ a field that is of function type. Do we do something about that?

Are there other inconsistencies?

I think more limitations and the current implicit "const" are adding inconsistency and complexity (which comes with more opportunities to bypass in unintended ways).

So I'm trying to understand how immutable do function values have to be.

The actions I think increase consistency are:

1) change most/all "global" function decls in scripts shipped w/ Bro to explicitly use "const"
2) remove the implicit "const" from "global" functions

These should both be easy tasks, but are they actually enough to allow desired optimizations in the compiled-context? What I didn't get from Robin's comment was if the problem is in what the language *allows* regarding function mutability or in the common *usage* of functions in current scripts?

- Jon