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

split path in unix and windows #332

Open
Tieske opened this issue Aug 3, 2020 · 3 comments
Open

split path in unix and windows #332

Tieske opened this issue Aug 3, 2020 · 3 comments

Comments

@Tieske
Copy link
Member

Tieske commented Aug 3, 2020

as suggested by @tst2005 here: #331 (comment)

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
Copy link
Member

alerque commented Aug 3, 2020

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
Copy link
Contributor

tst2005 commented Aug 7, 2020

@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
Copy link
Member Author

Tieske commented Feb 6, 2023

This issue is relevant I think: lunarmodules/ldoc#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

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

No branches or pull requests

3 participants