You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All of the above return simply the root Sugar object. The reason for this is that modules are simply packages for convenience, and may define methods for different types. For example, the enumerable package defines methods on both Array and Object that share common code. Other modules are es5, es6, and es7, which define polyfills, as well as inflections and language, which define extra methods on String that are complex, and not desirable in most contexts.
The proposal here is to simplify this so that require('sugar/array') would return Sugar.Array instead of Sugar. This would unfortunately mean that sugar/enumerable would either have to not exist any more, or continue to return the global Sugar object, which could be confusing. Alternatively, modules could continue to exist, but simply as their npm package names (sugar-enumerable, etc), and just be collections of like methods, but no longer carry any meaning in Sugar itself.
I'm considering different approaches and open to input here.
The text was updated successfully, but these errors were encountered:
Sugar currently allows requiring by "module", however all modules return the global object:
All of the above return simply the root
Sugar
object. The reason for this is that modules are simply packages for convenience, and may define methods for different types. For example, theenumerable
package defines methods on bothArray
andObject
that share common code. Other modules arees5
,es6
, andes7
, which define polyfills, as well asinflections
andlanguage
, which define extra methods onString
that are complex, and not desirable in most contexts.The proposal here is to simplify this so that
require('sugar/array')
would returnSugar.Array
instead ofSugar
. This would unfortunately mean thatsugar/enumerable
would either have to not exist any more, or continue to return the globalSugar
object, which could be confusing. Alternatively, modules could continue to exist, but simply as their npm package names (sugar-enumerable
, etc), and just be collections of like methods, but no longer carry any meaning in Sugar itself.I'm considering different approaches and open to input here.
The text was updated successfully, but these errors were encountered: