task_local_storage() is un-Julian

[stevengj]

Seems like it would be much more idiomatic to have a global variable TASK_LOCAL_STORAGE::Task_Local_Storage with get, getindex, and setindex! methods for Task_Local_Storage <: Associative{Any,Any} so that you could just do TASK_LOCAL_STORAGE[:foo] = bar etcetera.

I noticed this because there is no documented analog of get(TASK_LOCAL_STORAGE, key, default) for task_local_storage() ... I expected task_local_storage(key, default) to do this and was surprised that it acted as assignment (without !). There is the undocumented get(task_local_storage(), key, default), but it occurred to me that just having TASK_LOCAL_STORAGE act like a Dict would be much cleaner and clearer.

[JeffBezanson]

This is a good idea. I only wonder if it's ever useful to get a reference to the actual storage of a specific task. Would we do that via TASK_LOCAL_STORAGE[]?

[stevengj]

@JeffBezanson, in all the cases that I can find that currently call task_local_storage() (to fetch the Dict), it is to call methods like get and delete! that could instead be defined directly for TASK_LOCAL_STORAGE.

[IainNZ]

👍, I experienced this when I redeveloped Base.Test and it felt like very clunky

[tkelman]

unlikely to be refactored right now

[Keno]

Discussed during triage and decided that having a special array type seems like a nice design. Removing decision, adding up for grabs.

[StefanKarpinski]

Could we just express this with indexing into type objects? E.g. task[:key] and task[:key] = val.

[stevengj]

@StefanKarpinski, you mean into the Task type? (Instead of defining a global?) That seems like a cute design, albeit a little unusual.

[StefanKarpinski]

No, I meant the task object, but the task type could work too. The task object would allow accessing a tasks storage externally.

[stevengj]

So you would do current_task()[:foo]? That seems fine to me.

[JeffBezanson]

I'd be a little worried that that would prevent us from adding other operations on Tasks, e.g. we used to have task iteration (for x in task), which would now be iterating over the storage.

[StefanKarpinski]

It's not entirely kosher but you could distinguish indexing into a task with integers versus symbols...

[StefanKarpinski]

Another thought: have a Base.Tasks module so as to avoid polluting the Base namespace with generic names related to tasks (or use Base.Threads) and have Tasks.storage() for the task-local-storage of the current task and Tasks.storage(task) for the task-local storage of another task.

[Keno]

This seems non-breaking. Worst case we have to keep the old function as an alias. Propose to remove from milestone.