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

Change JSTuple #36

Open
jbracker opened this issue Apr 24, 2013 · 0 comments
Open

Change JSTuple #36

jbracker opened this issue Apr 24, 2013 · 0 comments

Comments

@jbracker
Copy link
Member

Right now JSTuple looks like this:

class Sunroof o => JSTuple o where
  type Internals o
  match :: (Sunroof o) => o -> Internals o
  tuple :: Internals o -> JS t o

This ensures that you create Sunroof type that accompanies your Internals type and by that create a proper abstraction of your new record.

An alterntive to this approach would be to do something like this:

instance JSTuple v where
  type TupleOf v
  match :: Sunroof (TupleOf v) => TupleOf v -> v
  tuple :: Sunroof (TupleOf v) => v -> JS t (TupleOf v)

Like this you are not obligated to create a custom Sunroof type. You can just reuse a type like JSObject as encoding of your record. It would still leave you the possibility to create your own Sunroof type. The ability to reuse a type like JSObject would also allow implementing different interpretations of the same object and by that providing some sort of inheritance mechanism as it is used in JavaScript all the time. Also this might give a possiblility to do type safe inspection of exisiting types by exposing their attributes as a record, although that is already possible by creating proper bindings for the attr combinator.

Though I do not have a good example of this and of course there is a risk that people do garbage with this like misusing type like JSDate.

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

No branches or pull requests

1 participant