Alan, I think we agree that there's a flaw here, and I can assure you that we, the developers, *are* thinking about solutions to this. Would it solve your problem to be able to optionally specify a default value for globals that is restored whenever `clear-globals` (or, by extension, `clear-all`) is called? For example, you could specify `globals [my-global = 3]` to initialize `my-global` to `3`. Personally, I think this is a pretty sensible solution to something that has *always* irked me about NetLogo.
On the "null" side of things, I have a fairly strong aversion towards adding a special invalid value to the language (like Java's `null` or JavaScript's `undefined`), since I think it's become pretty apparent in the programming community at large that such special invalid values in a language are a net negative for writers of code in the language and for the developers of its libraries alike. I don't feel that the NetLogo solution of defaulting values to `0` is any better—arguably worse, really—but *adding* a value to the language for doing something that leads the error-prone paranoia of continually checking variables to make sure that they aren't *that one evil value* simply seems like a step backwards to me. As for workarounds, it sounds to me like you just don't want globals to be reset between your BehaviorSpace runs. If that's the case, you could substitute any calls to `clear-all` for calls to some procedure `clear-most`, where the code for that is: ``` to clear-most clear-ticks clear-turtles clear-patches clear-drawing clear-all-plots clear-output ; or whichever of these are relevant to your model end ``` Afterall, `clear-all` simply runs all of that code, plus `clear-globals`. Yeah, it's not pretty—it's actually comedically long code—but... it's a workaround. On Friday, October 17, 2014 4:19:54 PM UTC-5, Alan Isaac wrote: > > There is no good workaround. The developers have not suggested a > workaround. This is a widely recognized problem. I personally do not see > how it will be adequately addressed unless initialization of non-interface > globals is changed. I would love to hear how the developers are thinking > about this problem, which poses very real problems for serious NetLogo > users. > > My recommendation would be to plan a transition. Immediately, introduce a > new keyword for the declarations section, allowing specification of the > default value for non-interface globals. (E.g., `__global-default`.) > Ideally, this would immediately be supported by the introduction of a new > value (e.g., `undefined`). Users who want this functionality now would be > able to include the declaration > > __global-default undefined > > In a future version, this would become the default behavior. > > I plead that the developers take this design flaw seriously and that it > not be passed on to Tortoise! > > Alan > > -- You received this message because you are subscribed to the Google Groups "netlogo-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
