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

Remove the optional arguments to absolute`() #10

Open
nex3 opened this issue Dec 1, 2015 · 3 comments
Open

Remove the optional arguments to absolute`() #10

nex3 opened this issue Dec 1, 2015 · 3 comments
Labels
next-breaking-release Issues that are worth doing but need to wait for a breaking version bump type-enhancement A request for a change that isn't a bug
Milestone

Comments

@nex3
Copy link
Member

nex3 commented Dec 1, 2015

The absolute() function supports six optional arguments, in the same manner as join(). These arguments are rarely used in practice, and are an odd divergence from path's usual style of functions that do a single job. They also presumably add a small amount of overhead in the very common case of making a single path absolute. Once we decide to make a release with breaking changes, it should remove these arguments.

@nex3 nex3 added the type-enhancement A request for a change that isn't a bug label Dec 1, 2015
@nex3 nex3 added this to the 2.0.0 milestone Dec 1, 2015
@jddeep
Copy link

jddeep commented Feb 22, 2020

@nex3 Is the issue still relevant? Could I work on this?

@nex3
Copy link
Member Author

nex3 commented Feb 24, 2020

This is a question for the current maintainer of the package.

@natebosch natebosch added the next-breaking-release Issues that are worth doing but need to wait for a breaking version bump label Feb 24, 2020
@natebosch
Copy link
Member

Here is one usage:
https://github.com/flutter/flutter/blob/e2dcdb60e327f80d414d3d1e72e2863bf4c9252c/packages/flutter_tools/lib/src/commands/update_packages.dart#L1103

This could be replaced with path.absolute(path.join(arg1, arg2)).

My opinion is that we should go ahead and do this change along with null safety, but I don't have strong feelings. @jakemac53 @kevmoo - do you have any thoughts?

@jddeep - I do think this is still relevant - it's probably not something I'd recommend trying to take on. The change itself is easy, however the real work comes from getting the breaking change version bump shepherded through our core ecosystem and we won't be able to accept PRs on this until we're prepared to do that work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
next-breaking-release Issues that are worth doing but need to wait for a breaking version bump type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

3 participants