[RFC] Mojo::File

[sri]

There's a lot of File::* modules we use in Mojolicious (File::Basename, File::Spec, File::Find,

File::Copy, File::Path...). Their use is pretty decentralized at the moment, even though we've

already written our own little extensions like Mojo::Util::files/slurp/spurt.

So, i've been thinking that maybe it would make sense to encapsulate all that stuff a bit in a

new object, which i've called Mojo::File in the (still unfinished) proof-of-concept branch.

    https://github.com/kraih/mojo/compare/mojo_file

Since i'm still on the fence about this proposal, the final decision will depend entirely on

feedback from the community (that's you!). Let me know what you think.

--

sebastian

[sri]

I know, there's no documentation, so it might be a bit hard to judge. The tests should

give you an idea of what functionality to expect though.

    https://github.com/kraih/mojo/compare/mojo_file#diff-f1d42fe079b984a3be6f542691890baaR1

The ultimate goal is to turn file system interactions into fun little one-liners, like this one,

which lists files recursively.

    path('/etc')->list_tree->grep('is_file')->join("\n")->say

--

sebastian

[Tobias Oetiker]

> On 2 Jan 2017, at 20:35, sri <kra...@gmail.com> wrote:
> [...]

> So, i've been thinking that maybe it would make sense to encapsulate all that stuff a bit in a new object, which i've called Mojo::File in the (still unfinished) proof-of-concept branch.
>
> https://github.com/kraih/mojo/compare/mojo_file
>
> Since i'm still on the fence about this proposal, the final decision will depend entirely on feedback from the community (that's you!). Let me know what you think.

I like the idea, as it will allow for optimizations further down the line by replacing existing implementations with our own, without affecting the code that is using the Mojo::File functions ...

cheers
Tobi

[Stefan Adams]

On Mon, Jan 2, 2017 at 1:35 PM, sri <kra...@gmail.com> wrote:

encapsulate all that stuff a bit in a new object

I like this.  It gives me a single spot to understand file-based operations and it allows me to see a uniform interface.

[Stefan Adams]

Why not a Mojo::File interface for:

L38 | has tmpdir => sub { $ENV{MOJO_TMPDIR} || File::Spec->tmpdir };

[sri]

I like the idea, as it will allow for optimizations further down the line by replacing existing implementations with our own, without affecting the code that is using the Mojo::File functions ...

Funny you bring up optimizations. One of my main concerns has been the object-oriented

API, and especially the cost of instantiating so many objects. There are a few hot-spots, like

the Morbo file checker, where the difference could be significant.

    https://github.com/kraih/mojo/compare/mojo_file#diff-bf69c09402d7c06fb7bc3c8165e20dacR19

I'd really appreciate some testing there, since my time is a bit limited at the moment.

--

sebastian

[sri]

L38 | has tmpdir => sub { $ENV{MOJO_TMPDIR} || File::Spec->tmpdir };

Mojo::Asset::File has some very special and kinda unique needs (more than this line)... and

i'm very unsure about how much of it to push into Mojo::File.

--

sebastian

[M. Aaron Bossert]

Well, "Tommy likey!" ...it has my vote...

Get Outlook for iOS

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious...@googlegroups.com.
To post to this group, send email to mojol...@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[sri]

I know, there's no documentation, so it might be a bit hard to judge.

There is now also some documentation.

    https://github.com/kraih/mojo/commit/e25c05814a80aad838c60a4a5f4d4d7474c3cffb

Even though i'm still not sure if it should be added to Mojolicious.

--

sebastian 

[Stefan Adams]

On Sat, Jan 7, 2017 at 12:41 PM, sri <kra...@gmail.com> wrote:

Even though i'm still not sure if it should be added to Mojolicious.

Well I think it's fantastic and I know I'll use it all the time!

I certainly cannot speak to the impact it will have on Mojo core.

[sri]

Putting it up for a vote, everybody is welcome to participate.

    https://github.com/kraih/mojo/pull/1028

--

sebastian

[sri]

Putting it up for a vote, everybody is welcome to participate.

And it passed the vote! \o/

--

sebastian 

[Stefan Adams]

On Mon, Jan 9, 2017 at 12:02 PM, sri <kra...@gmail.com> wrote:

And it passed the vote! \o/

That was the highest vote count I've seen!  Smashing success!!  It was really great to see a lot of people weighing in.  Such user participation is really great for the project and for the community!

[sri]

Smashing success!!  It was really great to see a lot of people weighing in.  Such user participation is really great for the project and for the community!

Yes, indeed! And Mojo::File has now been released to CPAN with Mojolicious 7.15.

--

sebastian

[Andrey Khozov]

Are there any plans for adding Mojo::File::remove_tree method, opposite to make_path?

-- 

Andrey Khozov

[sri]

Are there any plans for adding Mojo::File::remove_tree method, opposite to make_path?

Right now the only plan is to support the things we need in core Mojolicious. Everything else will depend on sensible proposals and votes.

--

sebastian