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

Placeholder name, eg %name #274

Open
pie6k opened this issue Aug 2, 2022 · 9 comments
Open

Placeholder name, eg %name #274

pie6k opened this issue Aug 2, 2022 · 9 comments
Labels
follow-on proposal Discussion about a future follow-on proposal

Comments

@pie6k
Copy link

pie6k commented Aug 2, 2022

I wanted to propose adding an optional placeholder name to the syntax and ask you what do you think about it?

Example:

const fileName = "file.txt";

fileName
  |> addServerPath(%) // `/path/to/server/file.txt`
  |> convertToUrl(%filePath) // `http://server.com/path/to/file.txt`
  |> await fetchFile(%fileUrl) // some node file object
  |> await saveFile(%fileHandler, "downloads")

As seen, in the pipe steps we add the name of the placeholder. It is optional and has 0 impact on how this code works, but makes it easier to read, as we can add the information 'what is the placeholder at this step' so the reader of the code doesn't have to guess it from function names.

@nicolo-ribaudo
Copy link
Member

Don't comments work for that purpose? I often use them to document what each parameter is when calling a function, regardless of pipes.

const fileName = "file.txt";

fileName
  |> addServerPath(%) // `/path/to/server/file.txt`
  |> convertToUrl(/* filePath */ %) // `http://server.com/path/to/file.txt`
  |> await fetchFile(/* fileUrl */ %) // some node file object
  |> await saveFile(/* fileHandler */ %, "downloads")

@pie6k
Copy link
Author

pie6k commented Aug 4, 2022

Of course this can be addressed with comments, but placeholder could be a nice "baked in" way to do that.

A bit similar to why we give variables good names if possible before writing a comment.

@VitorLuizC
Copy link

This probably was discussed in #91.

@aloisdg
Copy link

aloisdg commented Aug 5, 2022

A bit similar to why we give variables good names if possible before writing a comment.

If you have good function names, you may not need to give variables names at all.

@pie6k
Copy link
Author

pie6k commented Aug 6, 2022

A bit similar to why we give variables good names if possible before writing a comment.

If you have good function names, you may not need to give variables names at all.

True, but also quite subjective. What do you feel is the reason against placeholder names? In the end you don't have to use them if you don't want to

@aloisdg
Copy link

aloisdg commented Aug 7, 2022

I don't have any reason against placeholder name, because I don't oppose it. It may not be needed but I would say that it is not a bad thing either.

@shuckster
Copy link

This probably was discussed in #91.

Also in #203, with the OPs example here.

@lazarljubenovic
Copy link

Isn't avoiding giving the name 90% of the choice to use |> though? This would make parsing harder (and I assume slower), and would be one more thing to teach. I have a feeling like a simple comment is more useful here, even a "normal" one at the end of the line, like you'd do it now when chaining things like map and filter.

Also, IDEs are very likely to give an inline hint for the argument name right after % anyway, so it will pretty much look exactly like OP's example in practice.

@jeremyjacob
Copy link

Just use a list of const declarations in this case, no?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
follow-on proposal Discussion about a future follow-on proposal
Projects
None yet
Development

No branches or pull requests

8 participants