Closed eric-brechemier closed 12 years ago
I actually ended with a more limited subset for TV, due to restrictions of this platform: the lack of support for function.apply() makes use of variable number of arguments more cumbersome:
https://github.com/eric-brechemier/lime-starter-kit/blob/master/lab/js/define.js
I was hoping this would just be managed by the loader specifying what parts of AMD it supports. For instance, the almond API shim has a list of constraints that limit the types of AMD modules it supports.
The amdjs tests also have an opt-in of different levels, so that an implementation can prove some AMD conformance without having to implement all of it.
Otherwise, I think it is too difficult to try to reflect in the spec a list of values that indicate level of conformance, and then even harder to communicate those values.
I would rather see loaders suggest using different types of tools/optimizers to format the input modules into the types that are usable by a particular loader.
I am going to mention @unscriptable here so he gets notified of the comment, he expressed getting notifications of new tickets, but we do not seem to be getting them, so trying to manually trigger a notification.
I am going to close this for now, but we can reopen if we need to after further discussion.
Thanks for the detailed answer.
I am now experimenting with a new approach, an intermediate layer to facilitate the migration from static code to dynamic code using AMD: https://github.com/eric-brechemier/scopeornot
The idea is to define an API compatible with AMD but without requiring any compliance. The implementation of scope() can be selected to migrate modules slowly, first using a static implementation which does not manage dependencies and expects scripts to be defined in the correct order, before switching to a dynamic implementation which handles dependencies at a later step.
I would like to implement a subset of AMD for Static Module Definition (SMD).
I have two use cases in mind:
I have developed a partial implementation of AMD for the first use case here: https://github.com/eric-brechemier/lb_js_scalableApp/blob/master/src/amd/define.js
I plan to develop a more limited implementation for the LIME Starter Kit project, using a subset of JavaScript, for TV sets: https://github.com/eric-brechemier/lime-starter-kit
I feel like 3 areas of the code are oversized for a basic implementation:
I would suggest to define a property, define.amd0 or define.smd, for basic implementations that claim only support for:
Modules using the basic syntax may still be loaded by full-featured AMD script loaders. It may be possible to convert (most of) existing modules to the basic syntax in optimization tools.