Camel case for package's name?

[favba]

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]

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]

Do you have a new name in mind?

• Accessors.jl (although, according to https://en.wikipedia.org/wiki/Mutator_method, accessor only means getter)
• Mutators.jl (as Wikipedia suggests)
• Setters.jl (although this is just a half of the story)
• GetSet.jl (very/too direct name)

[jw3126]

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

[tkf]

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]

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

[jw3126]

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

[jw3126]

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]

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]

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]

It's not possible ATM but there is a discussion about it: JuliaLang/julia#33047