Switch to use independent classes to represent each state of parsing is succeed or not about bread-n-butter HOT 6 CLOSED

Using .isOK() method is not common in JS either. And you have to look at the prototype to see the method exists.

As you mentioned, it requires looking up to the prototype and the cost developers pay will be mostly same as using plain object (or higher because of console logging issue). Thank you for sharing your thoughts on this. You can close this issue. 👍

from bread-n-butter.

Hi @minamorl!

Thanks for reading 😄

I used to have classes for everything, but I changed the design.

New style

if (result.type === "ParseOK") {
  // ...
}

Old style

if (result.isOK()) {
  // ...
}

Alternative Old Style

if (result instanceof bnb.ParseOK) {
  // ...
}

I thought that using a type with | and no methods was easier to understand. If
it is a class instead, people will want various methods on it, I think.

I decided to only use classes for things that needed methods for readability
(Parser and Context).

You can see the old design with classes here: https://github.com/wavebeem/bread-n-butter/tree/a2f1fd9d143fa3a9541bc83c627b09e8b213ad3d/src

from bread-n-butter.

Thanks for quick and detailed reply. I read those old code and understand why you choose current design. In TypeScript world, that works perfectly I guess.

My concern is that people who use the ES as it is are not given the benefit of types. It might be a niche for a use case but from that point of view I prefer the old style. How do you think? :)

from bread-n-butter.

I think the new style is easier for plain JS users for a few reasons:

• Using instanceof is not common in JS.
• Using .isOK() method is not common in JS either. And you have to look at the prototype to see the method exists.
• Using .type === should be easy to discover by looking at console.log(result) output.

I like both styles, but I think plain Object style will be easier to learn than custom classes.

from bread-n-butter.

Hi @wavebeem,
Why not defining a type guard, which could be useful for both Typescript and Javascript users?

function isParseOK<T>(result: ParseOK<T> | ParseFail): result is ParseOK<T> {
  return result.type === "ParseOK"
}

EDIT: This is actually totally useless because both types contain type which is discriminent…

As a side note, I wanted to tell you that I just successfully ported a small Parsimmon-based project to BnB… 😄

from bread-n-butter.

@sveyret

EDIT: This is actually totally useless because both types contain type which is discriminent…

Yeah I initially thought about making one of these, but you don't need it as you found out 😄

As a side note, I wanted to tell you that I just successfully ported a small Parsimmon-based project to BnB… 😄

Oh cool! If you have any thoughts or feedback, please open an Issue and tell me 😄

from bread-n-butter.