Binding vars inside `cond`?

[eksperimental]

@al2o3cr

defp b_cache_wrapper do
  case Process.get(:an_expensive_function_returning_b_cache) do
    nil ->
      result = an_expensive_function_returning_b()
      Process.put(:an_expensive_function_returning_b_cache, result)
      result

    cached_value ->
      cached_value
  end
end

the problem with Process dictionary is that there’s no fetch function, so if your function returns nil or :undefined, it’s not going to be cached, since there’s no way to determine whether the value is cached or has not been cached yet. Please someone correct me if I’m wrong.

[al2o3cr]

You’re not wrong in general; the specific code in the question was comparing the result of an_expensive_function_returning_b to c with <, so I assumed it couldn’t be nil since such a comparison will work but is almost certainly not useful.

In a general situation where the expensive function could return nil, you’d need to wrap the value in something to distinguish “not in the dictionary” from "present but nil", for instance an :ok tuple:

defp b_cache_wrapper do
  case Process.get(:an_expensive_function_returning_b_cache) do
    nil ->
      result = an_expensive_function_returning_b()
      Process.put(:an_expensive_function_returning_b_cache, {:ok, result})
      result

    {:ok, cached_value} ->
      cached_value
  end
end

[silverdr]

@csadewa

True, but it wouldn’t be that much effort because you could easily make a generic wrapper

I am not sure I understand. Unless I am missing something I either would need to write the ETS handling wrapper myself or pull-in another dependency like for example this one. Now both are surely possible if justified. But…

@csadewa

One of the nice thing about caching based solution is that generally you don’t need to think much about it / refactor much your existing code. For example if you function have multiple function path, and only in some (multiple) select function path you need to call you expensive function. you don’t need to refactor the code to ensure expensive function is called on once (and only if it’s needed)

… precisely That’s why I liked @al2o3cr’s suggestion, which does exactly that, and (as long as no IPC is involved) requires neither additional deps nor additional ETS handling

@al2o3cr

the specific code in the question was comparing the result of an_expensive_function_returning_b to c with <, so I assumed it couldn’t be nil

It was dummy code. In reality one of the expensive calls can return nil, but…

@eksperimental

the problem with Process dictionary is that there’s no fetch function, so if your function returns nil or :undefined, it’s not going to be cached, since there’s no way to determine whether the value is cached or has not been cached yet

… in this particular case even if it does return nil, this is already triggering error so it wouldn’t be called again ergo no problem. Still it would be much better to handle also the “valid” nil, and…

@al2o3cr

In a general situation where the expensive function could return nil, you’d need to wrap the value in something to distinguish “not in the dictionary” from “present but nil”, for instance an :ok tuple:

… this looks to me like a nice, Elixirish way to do it

[csadewa]

@silverdr

Now both are surely possible if justified. But…
… precisely That’s why I liked @al2o3cr’s suggestion, which does exactly that, and (as long as no IPC is involved) requires neither additional deps nor additional ETS handling

Ah, i presume too much, i was presuming you are dealing with similar problem i frequently deal at work:

1. Calling expensive function is not a single isolated incident, you have relatively big codebase which have frequent problem of calling expensive function multiple time.
2. your codebase heavily rely on async / Task function.

In which case, it would be nice to have a generic cache wrapper module/function, which you could plug in wherever you need at problematic hotspot. I was creating custom module based on Cachex, but it’s spirit is similar to GitHub - cabol/nebulex: In-memory and distributed caching toolkit for Elixir. or GitHub - melpon/memoize: A method caching macro for elixir using CAS on ETS.