more flexible maxAge about memoizee HOT 3 OPEN

@rektide Do you really need that? What is the specific use case?

I'm not sure is it wise to provide it, also it may appear it'll bad for performance when used

e.g. if we would want to change maxAge on already setup memoized function, then for each already saved results we need to know how much time passed since they were cached (this information is not stored now), and either we need to clear them or replace their timeouts with new ones (that can be heavy for large number of items).

So this functionality may contradict idea of memoization, which is about saving resources, not sure if it's really worth it

from memoizee.

I have two cases I'm working with needing variable lifetimes- a data connection pool with near/far connections needing different lifecycles, and an implementation of etcd, which allows objects posted to be tagged with a TTL.

It'd be fine to not update retroactively. That's certainly something that can be done at a higher level easily, once there's some kind of finer granularity in memoize.

from memoizee.

a data connection pool with near/far connections needing different lifecycles

Wouldn't it be better for each lifecycle to have different memoized function configured?

and an implementation of etcd, which allows objects posted to be tagged with a TTL

That seems make sense. It may work as following:

// Timeout needs to be configured before function is invoked
memoizedFn.configureTimeout(timeout, ...args);
// Invoke function
memoizedFn(...args); // preset timeout is taken into account

It'd be fine to not update retroactively.

Yes, I guess if we'll implement it, it'll be strictly for future hits, no ongoing timeouts would be affected.

from memoizee.