jw3126 / Setfield.jl

Update deeply nested immutable structs.
Other
167 stars 17 forks source link

Camel case for package's name? #54

Open favba opened 6 years ago

favba commented 6 years ago

I don't how hard/annoying it is to change a package's name. But wouldn't it be more consistent with Julia to name the package "SetField" instead of "Setfield"? It is not a big deal, but I did get used to writing every module in camel case and it might be what everyone else using Julia expects.

jw3126 commented 6 years ago

Yes, might be more consistent. But I think its not worth the change. I don't particulary like the current name anyway. If the package becomes more matrue, it can be renamed into something completly differnet.

tkf commented 5 years ago

Do you have a new name in mind?

jw3126 commented 5 years ago

I had Lens.jl in mind. It would require renaming the type Lens to AbstractLens. What do you think?

tkf commented 5 years ago

Unfortunately, there is already Lens.jl: https://github.com/zenna/Lens.jl

Maybe we can use Lenses.jl but I feel it a bit confusing because:

  1. people may mistype package name and surprise to get a very different package

  2. lens is not super descriptive if you don't already know it (I personally find lens super cool, but it would be sad to decrease discoverability of this package. For example, I'd assume very few people know that Setfield can be used with StaticArrays because of the naming.)

tkf commented 5 years ago

(and it's still registered https://github.com/JuliaRegistries/General/blob/master/L/Lens/Package.toml)

jw3126 commented 5 years ago

Ok since Lens is taken, I like SetGet and Accessors the most.

jw3126 commented 5 years ago

So how would we execute the renaming practically? Create a whole new package starting with version v0.1.0. That package can do some breaking changes like change semantics of @set! and remove some cruft like the Experimental submodule. And we do a final Setfield.jl release that has some depwarns and points to the new package?

tkf commented 5 years ago

That sounds like a good plan.

Setfield can just re-export everything from the new package while keeping old @set!. I think Setfield can live as-is as long as possible. But maybe you can emit some warning from (e.g.) __init__ if you want to notify people.

cstjean commented 5 years ago

Now that packages are identified by uuid, it's a shame that you couldn't just rename the repo and keep the same uuid. But I don't think that would work, right?

tkf commented 5 years ago

It's not possible ATM but there is a discussion about it: https://github.com/JuliaLang/julia/issues/33047