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

Include type definitions #25

Open
estollnitz opened this issue Jan 26, 2020 · 2 comments
Open

Include type definitions #25

estollnitz opened this issue Jan 26, 2020 · 2 comments
Labels

Comments

@estollnitz
Copy link
Contributor

Type definitions for the FOLD library would allow for static type checking as well as intellisense in code editors. This could be accomplished either by providing a .d.ts type definition file for the existing code, or by implementing FOLD in TypeScript.

@mayakraft
Copy link
Contributor

just worked on a Swift project where i had to define the structure like this. it got me thinking about which entries inside the arrays are allowed to be null/undefined. referring to the 2.0 feature strict null checks. also can relate this to the new 1.2 spec #30 which makes a point that 3 arrays allow null values.

here is the swift definition. the way swift works is anything followed by a ? can be undefined (nil). so [String]? is an array which may not exist (null) but its contents MUST be a string, where [Double?]? means the array might not exist, and it can include nulls. in the case of FOLD, all top-level entries end with ? because nothing is required (although file_spec might be the closest to "required").

the entries which allow null are currently: edges_faces and vertices_faces and faces_faces, as mentioned in #30 , i think i remember seeing null inside edges_foldAngle exported from Origami Simulator. is that correct, and a behavior ? edges_assignment literally has an undefined (unassigned) type so i wonder if we can say no null values in that array.

here i have file_frames defined recursively, but i expect that to be incorrect. file_frames's type should be similar to FOLD, but exclude some things, like a recursive file_frames, and probably also exclude any file_ entries, but allow frame_ entries. does that sound about right?

struct FOLD: Decodable {
  let vertices_coords: [[Double]]?
  let vertices_vertices: [[Int]]?
  let vertices_edges: [[Int]]?
  let vertices_faces: [[Int?]]?
  let edges_vertices: [[Int]]?
  let edges_assignment: [String]?
  let edges_foldAngle: [Double?]?
  let edges_faces: [[Int?]]?
  let faces_vertices: [[Int]]?
  let faces_edges: [[Int]]?
  let faces_faces: [[Int?]]?
  let file_frames: [FOLD]?

  // metadata
  let file_spec: Double?
  let file_creator: String?
  let file_author: String?
  let file_title: String?
  let file_description: String?
  let file_classes: [String]?
  let frame_author: String?
  let frame_title: String?
  let frame_description: String?
  let frame_unit: String?
  let frame_classes: [String]?
  let frame_attributes: [String]?
}

@qurben
Copy link

qurben commented Nov 29, 2021

This would be really useful. When implementing FOLD in java with just the spec it was sometimes hard to understand what the exact type of a field would be as the spec doesn't differentiate between different kinds of numbers.

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

No branches or pull requests

4 participants