Is there an existing proposal for this?
This feature does not exist in the latest version
Proposal
This is the primary issue which will have various sub-issues attached to it given the scope and importance of this feature.
Kipper is as far as transpiled web languages go a very locked-down language with, as of v0.12.1, no ability to properly import or use external libraries or preexisting code. While this makes sense given the state of Kipper and how it has largely been developed as a proof of concept, it now should expand to actual useful programming in the web and desktop space. This entails many different features, but primarily means at the start the added support for JavaScript libraries and import of existing code from the JavaScript ecosystem.
To achieve this a compatibility layer needs to be constructed which handles the various use cases as well as errors that can arise during development with external files.
The rough idea for such a compatibility layer is fairly simple:
- Any imported data will be dynamic and marked as
any (This means Kipper will not perform external code analysis). However the types can be specified after the import as explained below.
- For the given imported elements or even the entire imported file scope the datatype can be specified using a
declare external statement.
- Data checks can either happen statically/as imports are assigned a type, or they can happen dynamically, simply put "check as we go" for performance reasons.
- JavaScript types, i.e. Kipper types wrapping JavaScript elements, will be wrapped using
JS<T>. (For the sake of compatibility, Kipper will not add meta properties to the imported elements)
- Dynamic types, i.e. types which will be checked as you go on, will be marked with
Volatile<T>. This means the type is not going to be checked for full validity, but only the properties and elements used in expressions and similar.
Exact behaviour / changes you want
Going to be determined as the features are properly planned out and implemented.
Is there an existing proposal for this?
This feature does not exist in the latest version
Proposal
This is the primary issue which will have various sub-issues attached to it given the scope and importance of this feature.
Kipper is as far as transpiled web languages go a very locked-down language with, as of v0.12.1, no ability to properly import or use external libraries or preexisting code. While this makes sense given the state of Kipper and how it has largely been developed as a proof of concept, it now should expand to actual useful programming in the web and desktop space. This entails many different features, but primarily means at the start the added support for JavaScript libraries and import of existing code from the JavaScript ecosystem.
To achieve this a compatibility layer needs to be constructed which handles the various use cases as well as errors that can arise during development with external files.
The rough idea for such a compatibility layer is fairly simple:
any(This means Kipper will not perform external code analysis). However the types can be specified after the import as explained below.declare externalstatement.JS<T>. (For the sake of compatibility, Kipper will not add meta properties to the imported elements)Volatile<T>. This means the type is not going to be checked for full validity, but only the properties and elements used in expressions and similar.Exact behaviour / changes you want
Going to be determined as the features are properly planned out and implemented.