Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

functor gem extraction #167

Open
anithri opened this issue Feb 22, 2015 · 6 comments
Open

functor gem extraction #167

anithri opened this issue Feb 22, 2015 · 6 comments

Comments

@anithri
Copy link
Contributor

anithri commented Feb 22, 2015

I think the functor and all it's attendant pieces and parts should be extracted into a separate gem.

I've been making a start at updating the tests and qed demos of facets. Right now I think all of the following are true:

  1. facets is too big. testing is working, but is brittle. the documentation is incomplete and features like
    functor get lost in the shuffle. Effort is required to get there.
  2. Splitting up facets will be hard. the topic and scope make a perfect vision for what should be included : enhancements to the core classes and std-lib. It just happens that that ends up being 100's of methods on dozens of classes. This is a hard problem that that would have to be addressed as the single goal of a 4.0 to 5.0 effort.
  3. functor doesn't seem to follow the core vision of the project. This is useful functionality, but only exists in facets because some of the facets enhancements.
  4. functor could stand easily as it's own gem and would likely benefit from attention.
@trans
Copy link
Member

trans commented Feb 23, 2015

Actually I have been considering this for Functor too. I even started to do it some time ago (see Functor), but came across a few functor-dependent methods that I felt torn about --not wanting to remove them from facets. Can't recall off-hand what they were, but NilClass#ergo is a good example. So I am not 100% sure. I guess we could split it off and facets could still depend on the functor gem for those few methods -- at least that would be a start. I really had hoped Matz would have brought the anonymous delegator idea into Ruby proper by now :-(

How about we do this. Lets compile a list of all the methods that depend on Functor, and then we can look them over and decide for sure.

Btw, I split up Facets once before. It was very hard. But out of the split up I got some reasonably successful projects, such as Hashery, ANSI and Radix, plus a few less notable projects such as Instance, Platypus and Mixers. So I am not against the idea of spinning things off, it just has to be very clear cut and able to stand on it's own.

Keep in mind though, by it's very nature Facets is going to be on the large side. it is a collection after all. But I think I've managed to keep her pretty tight despite that. I mean, I have had plenty of people dump dozens upon dozens of methods in my lap that they they wanted to see included in facets and I've had to meticulously weed through and decide which are worthy, and most do not make the cut. Even so I fully expect there are at least a few methods in there that could be trimmed to further tighten her up.

@anithri
Copy link
Contributor Author

anithri commented Feb 23, 2015

# file in /lib that contain Functor or functor
core/facets/string/linear.rb
core/facets/string/file.rb
core/facets/functor.rb
core/facets/enumerator/fx.rb
core/facets/symbol/as_s.rb
core/facets/enumerable/recursively.rb
core/facets/enumerable/ewise.rb
core/facets/enumerable/per.rb
core/facets/enumerable/apply.rb
core/facets/enumerable/accumulate.rb
core/facets/enumerable/every.rb
core/facets/hash/recursively.rb
core/facets/hash/data.rb
core/facets/kernel/as.rb
core/facets/kernel/tap.rb
core/facets/kernel/respond.rb
core/facets/kernel/ergo.rb
core/facets/kernel/try.rb
core/facets/kernel/not.rb
core/facets/kernel/meta.rb
core/facets/module/method_space.rb
core/facets/array/recursively.rb
standard/facets/against.rb
standard/facets/ostruct.rb

@trans
Copy link
Member

trans commented Feb 23, 2015

So what do you think? Should all of those methods be removed from facets and put in a functor gem? If so how would that gem be organized -- same as facets, e.g. core/functor/string/linear? I have to admit that I feel kind of funny about removing some of them.

@anithri
Copy link
Contributor Author

anithri commented Feb 23, 2015

Could we put it in something like a facets-plus which would be to contain methods that do have some external dependency. facets-plus could include the original facets, and we could setup the api to be identical regardless of which set you have installed?

@trans
Copy link
Member

trans commented Feb 23, 2015

I'd rather just have the separate functor project. I did some work on it today. I'm thinking for now Facets can just depend on functor gem for the Functor class. Later on we can worry about whether to remove the methods from facets or not (and if so add a deprecation warning for a while to give people a heads up).

@anithri
Copy link
Contributor Author

anithri commented Feb 24, 2015

works for me. Let me know if you want anything done for that otherwise I'll plug away at the tests and demos

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants