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

sharables - "type" field (instance / function / schema / view) #276

Closed
maxbates opened this issue May 14, 2014 · 4 comments
Closed

sharables - "type" field (instance / function / schema / view) #276

maxbates opened this issue May 14, 2014 · 4 comments

Comments

@maxbates
Copy link
Contributor

Add a field on set() to add a field primitive which differentiates between the four major data types

should also be in schema, e.g. function would encapsulate function, module, and subclasses of each

@maxbates
Copy link
Contributor Author

I have run into this before, and it looks like this will play into several of the features we’ve been talking about — it is sometimes difficult to determine the type of an object (at least on the client), because of all the subclasses etc.

It would be nice if there was an easier way to at least determine the type (Instance, Function, Sharable, View, etc.) of an object immediately, without having to do sequential get()s of the parent schemas.

E.g.

  • in determining the editor to use
  • in tokenization, to determine if a function was selected and the next autocompletion should be filtered based on argument type
  • in conversion, limiting to certain schemas + subclasses, or minimally to instances
  • in typeaheads, filtering to a type rather than specific schema

@jcaucb
Copy link
Contributor

jcaucb commented May 14, 2014

We shouldn't store that primitive variable in the database; we can add it programmatically during construction of the JSON.

@maxbates maxbates changed the title sharables - "primitive" field (instance / function / schema / view) sharables - "type" field (instance / function / schema / view) May 27, 2014
@maxbates
Copy link
Contributor Author

moving this to higher priority - simplifies several features and its an easy fix

@maxbates
Copy link
Contributor Author

deferring to #428 and incorporation of #426

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

2 participants