Open pdeffebach opened 3 years ago
Do you have an idea for a better name? Essentially this is something like @dfscope
but it seems like a not a very nice name.
Maybe @withcols
is good?
Might be too late to switch at this point. And we seem to be the largest user of @with
.
Maybe just @withdf
? then @with
could be deprecated with a clearly announced plan for removal, e.g.:
I would say @withcols
rather than @withdf
, I think.
OK. This is a minor thing.
Well, it's minor but if we decide to do it it would be the last change we make before 1.0, or a 0,7-esque pre-breaking release.
How should I figure out if I should go for it? Should I just go ahead?
So maybe you can comment why you prefer @withcols
over @withdf
?
My thinking about @withdf
is that we kind-of put df
in the scope.
I understand your for @withcols
is that we kind-of put columns in the scope.
Right?
The benefit of @withdf
is that it is a bit shorter to type and it is more clear that it is related to DataFrames.jl.
The user will write @withcols df begin
... so @withcols
reads like a sentence, "With the columns of df
...". @withdf
is redundant because the user will write @withdf df begin ...
. Also we've generally avoided using the term df
in DataFrames functions, in favor of more descriptive names.
OK. Let us go for @withcols
Wait one final problem with @withcols
. Right now you can do @withcols df @byrow begin
, and for consistency with rtransform
etc. we might want to have an @rwith
for doing things by row. Maybe this will be called @withrows
. That in turn, breaks the consistency with @rselect
, @rtransform
etc.
Maybe we are being overly defensive? There are no seriously competing packages using @with
right now.
I think we should wait until someone actually files an issue for a conflict with @with
to make this change.
OK - I am ok to keep @with
. The uses you have noted are not likely to be conflicting.
Sounds good. I have filed #278 and cc'd Mason. Hopefully it will be on everyone's radar at least and worry about re-naming later.
StaticModules.jl has a macro
@with
defined, and Infiltrator.jl is (maybe) defining a@with
.Ultimately
@with
just seems like too general a name for a macro that is so data-frames specific. It's also hard to imagine aWith.jl
package we could base this on because@with
creates an anonymous function whereas a type-stable object can get by with just alet
block.