You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@trans My apologies if I've stepped on your toes with the recent set of changes. I wanted to fix tests, get as many PRs merged and updated, and at least start to get some of these issues sorted out.
I think what you've done with facets is amazing.
To be brief:
We need to agree on a MVP for facets - what is valuable and what is baggage. As an examples: standard/facets/yaml.rb, standard/facets/argvector.rb.
We need to agree on a timeline for a 4.0.0 release
We need to sort out how much stuff needs to be tidied up/removed for 4.0.0 release.
I'd like to suggest that anything in facets that is done significantly better by a dedicated gem is ripe for removal.
I'd like to suggest that anything that is supported out of the box by 2.0.0+ should definitely be removed. Already started on this.
I'd like to suggest that functionality that is of questionable value is removed (e.g. File#yaml?).
I'd like to suggest that complex things which have a poor level of testing (e.g. argvector) and are additionally of little use, are removed.
I'd like to suggest that existing functionality, where it makes sense, is refactored to use keyword arguments. Already started on this in some areas.
I'd like to suggest that code that adds significant new functionality is ripe for removal. cattr and mattr being an example, which can be easily achieved using a slightly different syntax.
I'd like to suggest that trivial functions and aliases are removed if they are not adding anything (e.g. cgi/esc.rb).
I'd like to suggest that require 'facets' is profiled. How long to load and how much memory? We should aim to be very light by default, even if it goes against the original premise of the library, the idea of facets being extensions is ideal for lots of gem authors. But adding to the run-time cost is going to be a big pain point.
The text was updated successfully, but these errors were encountered:
Ideally, 4.0.0 should be a lean, mean release, that can stand the test of time, as 3.x has already. The goal, IMHO, is to fill in the gaps of the standard library, not significantly extend it. If we can reduce the surface area a bit, it will be easier to maintain too.
@trans My apologies if I've stepped on your toes with the recent set of changes. I wanted to fix tests, get as many PRs merged and updated, and at least start to get some of these issues sorted out.
I think what you've done with facets is amazing.
To be brief:
standard/facets/yaml.rb
,standard/facets/argvector.rb
.I'd like to suggest that anything in facets that is done significantly better by a dedicated gem is ripe for removal.
I'd like to suggest that anything that is supported out of the box by 2.0.0+ should definitely be removed. Already started on this.
I'd like to suggest that functionality that is of questionable value is removed (e.g. File#yaml?).
I'd like to suggest that complex things which have a poor level of testing (e.g. argvector) and are additionally of little use, are removed.
I'd like to suggest that existing functionality, where it makes sense, is refactored to use keyword arguments. Already started on this in some areas.
I'd like to suggest that code that adds significant new functionality is ripe for removal.
cattr
andmattr
being an example, which can be easily achieved using a slightly different syntax.I'd like to suggest that trivial functions and aliases are removed if they are not adding anything (e.g. cgi/esc.rb).
I'd like to suggest that
require 'facets'
is profiled. How long to load and how much memory? We should aim to be very light by default, even if it goes against the original premise of the library, the idea of facets being extensions is ideal for lots of gem authors. But adding to the run-time cost is going to be a big pain point.The text was updated successfully, but these errors were encountered: