Skip to content
This repository was archived by the owner on Jun 15, 2023. It is now read-only.

Print attributes without the @bs prefix #230

Merged
merged 4 commits into from
Jan 14, 2021
Merged

Conversation

IwanKaramazow
Copy link
Contributor

before

@bs.val
@bs.module

after

@val
@module

Exceptions:

  • @bs.open
  • @bs.pipe.send

@pckilgore
Copy link

This is generally very cool and good but could it be all-or nothing across annotations? Having a consistently inferior syntax is better than an inconsistent-occasionally nicer syntax (which is already a massive issue with existing *.re code that must share a codebase with any .res for the foreseeable future).

@IwanKaramazow IwanKaramazow changed the base branch from master to poly-var-syntax January 11, 2021 07:22
@IwanKaramazow
Copy link
Contributor Author

IwanKaramazow commented Jan 11, 2021

@pckilgore can you explain yourself more? I included all annotations, except for @bs.send.pipe because of the latter being deprecated and only there for backwards compatibility. @open also doesn't have any compiler support, cf. @bs.open

@pckilgore
Copy link

Even a deprecated construct might be supported for years. Unless there's a technical reason to not convert to @send.pipe, @bs.send.pipe is going to look like invalid syntax, or cause folks to think that something might be wrong with the parser because it usually rewrites those things. And to the extent discouraging usage of send.pipe is a goal, I would suggest the compiler would be a nice and explicit place to handle that, as it can provide context and explanation vs. inconsistent inferred behavior.

@bs.open doesn't matter much to me if it's invalid syntax entirely (that is, @open is invalid). I suppose I'm a bit curious why it was called out in that case?

@IwanKaramazow IwanKaramazow changed the base branch from poly-var-syntax to master January 12, 2021 06:14
@ryyppy
Copy link
Member

ryyppy commented Jan 12, 2021

@pckilgore we will document the bs.send.pipe and bs.open as deprecated attributes in our syntax widget, so ppl will still have a chance to understand what those are for, or why they are printed differently.

The compiler will also most likely print a deprecation warning at some point? \cc @bobzhang

@pckilgore
Copy link

I suppose I'm still curious why not treat them consistently and obviate any possible confusion (and also avoid the need to clutter the documentation with information that will be irrelevant to most).

@IwanKaramazow
Copy link
Contributor Author

IwanKaramazow commented Jan 14, 2021

It's ok here and won't cause a lot of confusion. The documentation will contain both versions any way.
The printed code will look a bit less cryptic in the same sense that when a user writes let (x) = ((1) + (2)), the formatter outputs let x = 1 + 2.

Regarding the @bs.open, there's still an open issue that needs to be tackled first #185

@IwanKaramazow IwanKaramazow merged commit 3081360 into master Jan 14, 2021
@IwanKaramazow IwanKaramazow deleted the attributes-prefix branch January 14, 2021 06:00
IwanKaramazow pushed a commit that referenced this pull request Feb 28, 2021
Fixes #292

Prints `@bs.send` as `@send` and `@bs.inline` as `@inline`

Followup of #230
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants