split path in unix and windows

[Tieske]

as suggested by @tst2005 here: https://github.com/Tieske/Penlight/pull/331#issuecomment-667939801

instead of the path functions operating on the current system (either Windows or Unix), create 2 namespaces; path.unix and path.windows that implement their respective versions, and set the system one as the default.

Questions;

• is this breaking?
• does thsi require the application to understand the platform difference? idea was probably that it would be transparent to the aplication...

[alerque]

As long as the original function name was linked to the platform specific function and Penlight was doing the platform detection I don't see why this would be breaking or require any understanding on the part of the application. The primary place it would make a difference is ease of testing Penlight itself, and that seems like a win.

[tst2005]

@Tieske if you like one of my idea ... maybe you will be interested by the others ... 2 years ago, I made some experimentation on a forked Penlight humoristically named litepain. I was pretty sure my approach will only usefull for me, but maybe I'm wrong.

• What is cool in Penlight ?
• There are plenty of usefull code !
• What is sucks in Penlight ?
• If you only need one small function/feature you need to get the whole projet. I see some projet copy/paste the function of feature inside he projet. I think this way to do is bad, because there is no channel for futur update of this part of code!

My experimentation was :

• analyse the dependencies

• make a try with pl.path to split each function(or feature) in one "standalone" sub-module file. See the result : https://github.com/tst2005/lua-litepain/tree/litepain/lua/lp/path Each sub-module contain the load of dependencies, his own code, return the function.

• Why do that ?!

• Because I search a way to be able to take part of penlight, build an all-in-one special module file and include this stuff into my own projet. I already made lot of experiments about that...

It will be easier for me if the Penlight's code will be more "pickable". I know it is maybe a hard work... and most of the Penlight users will don't see the différence.

I just spoke about the concept.

Conclusion of my linepain experimentation :

• the main difficulty was not technical, it was to find a good way to generate documentation (where to put the ldoc block).
• there is some f*cking hard case where module a cross loaded, cross-dependencies ... I try some experiementation, but it seems not the best clean way...

I'm still open for discuss.

Enjoy!

[Tieske]

This issue is relevant I think: https://github.com/lunarmodules/LDoc/issues/387

normalization depends on the use case;

• do 2 paths point to the same file?
• should it be normalized against existing paths? (currently on windows it becomes lowercase, should it normalize to the actual existing path segments as they exist on disk?)
• target file systems might be case (in)sensitive; so different from the running platform