Specifically this:
https://piechowski.io/post/last-arg-keyword-deprecated-ruby-2-7/
/home/jason/.rvm/gems/ruby-2.7.1@actioncue/gems/memoist-0.16.2/lib/memoist.rb:213: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call
Why adopt it if alive gems with the same `memoize method` API already exists? There is not-null chance that your project already includes `dry-core`, so
`include Memoist` -> `include Dry::Core::Memoizable` or `Memoist = Dry::Core::Memoizable` somewhere and that's it.
There is not `#unmemoize_all` and other methods, but it's easy to add if needed and dry-rb ppl are usually pretty fast at merging stuff.
And there are other gems doing the same.
([I'm afraid that you're right and this gem wouldn't be updated](https://www.justgiving.com/fundraising/inmemoryofmatthewjacobs))
@ojab Dry::Core::Memoizable does not really seem to be really in the user space of dry-rb. There is no documentation for it other than this, which more or less says nothing: https://rubydoc.info/gems/dry-core/Dry/Core/Memoizable
> Why adopt it if alive gems with the same `memoize method` API already exists?
Just came across this thread when trying to debug errors after upgrading to ruby3..
Does anyone know of any other drop-in (or close thereto) replacements for this gem? My only concern with `dry-core` is that their barely-documented `memoize` routines might be meant for internal use only and therefore could be subject to change without warning.
> We may need to face the fact that Matthew may have passed away. There is no activity from him for a long time. This gem may need to be adopted.
@patbl @jasonperrone He died in 2019. https://brightonruby.com/2019/from-developer-to-architect-and-back-again-matthew-rudy-jacobs/
I've loved this gem for a long time, and for years was active in the issues and PRs. Would be happy to help with moving it to an org, keeping the memory of Matthew alive. Certainly feels like I worked with Matthew for a decade. Who's with me? I have no idea what the process is for handling repos of deceased developers, but surely Github has one?
It sounds as though there isn't a process:
* https://github.com/isaacs/github/issues/1385
* https://github.community/t/what-is-github-policy-about-abandoned-repositories/117668
You could create a new account (maybe one named `memoist`—https://github.com/memoist currently 404's), and fork the repo there.
I realized after creating the `memoist` org that @sebjacobs (who is Matthew's [brother](https://mobile.twitter.com/raffijacobs/status/1177980813268471809)) actually has been maintaining this gem since Matthew's passing (at least until the end of 2020), but Seb hasn't been very active in the issues and PRs. I invited @sebjacobs to the new org, and am very interested to hear his thoughts on what direction to go here.
Seb has not been on GitHub in several months, and it is an uncharacteristically long absence (perhaps his longest ever?). He is still [running](https://www.strava.com/athletes/608833), but unclear if still coding.
@patbl I am not sure how much time I'll have to work on it, though I am using the gem in production, so perhaps it could fold into my work day. But I am happy to add anyone to the org / repo that wants to work on it. I don't have rights to the gem itself, so it might need to hard-fork for a release.
Also, since creating the memoist org, I decided that I'll be moving the bulk of my FLOSS efforts to another platform that isn't so [toxic to open source work and developers' rights](https://dev.to/galtzo/im-leaving-github-50ba). So if we do move forward with a hard fork, I'd suggest moving off GitHub to an entirely different platform.
I'll check it out. I've switched to using https://github.com/AlexWayfer/alt_memery, and I'm loving it, but looking over MemoWise, it is unambiguously superior. I'll be switching to MemoWise.
FYI: Added this alert to the [new memoist](https://github.com/memoist/memoist) repo
> [!IMPORTANT]
>
> # Recommendation
>
> Consider using [MemoWise](https://github.com/panorama-ed/memo_wise) instead, as it is maintained, fully tested, provides thread safety guarantees, and is much, much faster.
>
> # Other Alternatives
>
> In case you need a tool with this feature set that is currently maintained, check out:
> * https://github.com/makandra/memoized
> * https://github.com/honzasterba/memoist
> * https://github.com/AlexWayfer/alt_memery
> [!TIP]
> Seriously though, read the important note above.
> [!WARNING]
> If you must continue - be aware that this is unmaintained software.
@pboling unfortunately, the Rubygems page for `memoist` still points to this repository, so there's not much chance of someone coming across your alert.
I came here because the `sys-uname` gem just started depending on `memoist`.
It seems `memoist` is the memoization gem with the most downloads, so naturally people will choose it if they don't see the warnings 😞.
@mvz I'd like to think we rubyists have a process to take over control of a gem like that, to fix the awareness issue, or hand over development to someone maintaining a descendent, like memoist3 by @honzasterba. But I don't have time to look into that yet. :(