When I originally created dojo/kernel, I essentially ported the dojo bootstrap
(dojo/_base/loader/bootstrap) without putting much more thought into it.

However, looking at all the work that's been done to use proper, minimal
dependencies and looking at the base modules returning proper values makes me
think that dojo/_base/kernel isn't quite right. For example, it seems that
things like dojo.get/setObject and certainly dojo.mixin should go into
dojo/_base/lang. In particular, when writing a modern AMD module, it seems odd
to have to depend on dojo/_base/kernel to get access to dojo.mixin.

Today dojo/_base/kernel

1. defines dojo, dijit, dojox objects.
2. defines the scopemap
3. mixes the configuration into the dojo object
4. defines dojo.version
5. guarantees the console
6. defines dojo.deprecated/experimental
7. defines dojo.eval, get/setObject, exists, mixin, _mixin.

It seems to me that #7 belongs in lang. But maybe history and other
expectations won't allow this move.

What do others think?

Thanks,
Rawld

Search Discussions

  • Ben hockey at Jul 13, 2011 at 12:41 pm
    i agree that it seems more natural to move #7 into lang. i've caught
    myself a number of times assuming that those existed in lang already
    only to find out that they were in kernel. so my natural expectation is
    that they would be in lang.

    i don't think we have any reason not to put them in lang. the only
    consequence is that we would need to update dependencies to properly use
    lang rather than kernel. this is low risk but could be extremely time
    consuming to find all the references.

    in general i think we may still have some dark corners wrt using the
    right deps. dijit still has a number of '..' type deps that i think
    should be replaced with '../main' or more granular dijit/_base deps and
    i gave up keeping track of the current state of dojox deps. i figured
    that i'd try and update any dojox modules as i find problems and
    personally have need for them but until then if they aren't "broken" for
    anyone then i won't try to fix them.

    ben...
    On 7/13/2011 12:25 PM, Rawld Gill wrote:
    When I originally created dojo/kernel, I essentially ported the dojo bootstrap
    (dojo/_base/loader/bootstrap) without putting much more thought into it.

    However, looking at all the work that's been done to use proper, minimal
    dependencies and looking at the base modules returning proper values makes me
    think that dojo/_base/kernel isn't quite right. For example, it seems that
    things like dojo.get/setObject and certainly dojo.mixin should go into
    dojo/_base/lang. In particular, when writing a modern AMD module, it seems odd
    to have to depend on dojo/_base/kernel to get access to dojo.mixin.

    Today dojo/_base/kernel

    1. defines dojo, dijit, dojox objects.
    2. defines the scopemap
    3. mixes the configuration into the dojo object
    4. defines dojo.version
    5. guarantees the console
    6. defines dojo.deprecated/experimental
    7. defines dojo.eval, get/setObject, exists, mixin, _mixin.

    It seems to me that #7 belongs in lang. But maybe history and other
    expectations won't allow this move.

    What do others think?

    Thanks,
    Rawld
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bryan Forbes at Jul 13, 2011 at 1:11 pm
    I was getting ready to write the list about and thankfully I checked
    before starting writing. Comments inline.

    ben hockey wrote:
    i agree that it seems more natural to move #7 into lang. i've caught
    myself a number of times assuming that those existed in lang already
    only to find out that they were in kernel. so my natural expectation is
    that they would be in lang.
    I agree. I don't know how many times I've tried to use mixin from lang.
    i don't think we have any reason not to put them in lang. the only
    consequence is that we would need to update dependencies to properly use
    lang rather than kernel. this is low risk but could be extremely time
    consuming to find all the references.
    I wonder how many modules are using these 6 functions and have also
    included lang. It might not be as time consuming as you'd think (this is
    a wild speculation).
    in general i think we may still have some dark corners wrt using the
    right deps. dijit still has a number of '..' type deps that i think
    should be replaced with '../main' or more granular dijit/_base deps and
    i gave up keeping track of the current state of dojox deps. i figured
    that i'd try and update any dojox modules as i find problems and
    personally have need for them but until then if they aren't "broken" for
    anyone then i won't try to fix them.
    My initial reason for wanting to email the list about this was the
    NodeList extensions requiring "./main" instead of using granular
    dependencies. This isn't a big problem for something like NodeList-fx,
    but NodeList-traverse doesn't need "./_base/fx" brought in from "./main"
    to operate. I hesitate to propose this, but perhaps we should stick to
    the rule that most, if not all, modules in dojo (the directory, not the
    toolkit) should refrain from requiring "./main". If I remember right,
    DojoX has this rule.

    -Bryan
    ben...
    On 7/13/2011 12:25 PM, Rawld Gill wrote:
    When I originally created dojo/kernel, I essentially ported the dojo bootstrap
    (dojo/_base/loader/bootstrap) without putting much more thought into it.

    However, looking at all the work that's been done to use proper, minimal
    dependencies and looking at the base modules returning proper values makes me
    think that dojo/_base/kernel isn't quite right. For example, it seems that
    things like dojo.get/setObject and certainly dojo.mixin should go into
    dojo/_base/lang. In particular, when writing a modern AMD module, it seems odd
    to have to depend on dojo/_base/kernel to get access to dojo.mixin.

    Today dojo/_base/kernel

    1. defines dojo, dijit, dojox objects.
    2. defines the scopemap
    3. mixes the configuration into the dojo object
    4. defines dojo.version
    5. guarantees the console
    6. defines dojo.deprecated/experimental
    7. defines dojo.eval, get/setObject, exists, mixin, _mixin.

    It seems to me that #7 belongs in lang. But maybe history and other
    expectations won't allow this move.

    What do others think?

    Thanks,
    Rawld
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Ben hockey at Jul 13, 2011 at 1:23 pm

    On 7/13/2011 1:11 PM, Bryan Forbes wrote:
    My initial reason for wanting to email the list about this was the
    NodeList extensions requiring "./main" instead of using granular
    dependencies. This isn't a big problem for something like NodeList-fx,
    but NodeList-traverse doesn't need "./_base/fx" brought in from
    "./main" to operate. I hesitate to propose this, but perhaps we should
    stick to the rule that most, if not all, modules in dojo (the
    directory, not the toolkit) should refrain from requiring "./main". If
    I remember right, DojoX has this rule. -Bryan
    +1 we (rawld and i) discussed this before
    (http://permalink.gmane.org/gmane.comp.web.dojo.devel/15231). there's
    likely no need for any library code to reference main directly. its
    more of a convenience for client code. i have no objection to this rule
    ...with a disclaimer that we can make exceptions for exceptional
    circumstances (although i don't foresee any).

    ben...
  • Bryan Forbes at Jul 13, 2011 at 1:46 pm

    ben hockey wrote:
    On 7/13/2011 1:11 PM, Bryan Forbes wrote:
    My initial reason for wanting to email the list about this was the
    NodeList extensions requiring "./main" instead of using granular
    dependencies. This isn't a big problem for something like NodeList-fx,
    but NodeList-traverse doesn't need "./_base/fx" brought in from
    "./main" to operate. I hesitate to propose this, but perhaps we should
    stick to the rule that most, if not all, modules in dojo (the
    directory, not the toolkit) should refrain from requiring "./main". If
    I remember right, DojoX has this rule. -Bryan
    +1 we (rawld and i) discussed this before
    (http://permalink.gmane.org/gmane.comp.web.dojo.devel/15231). there's
    likely no need for any library code to reference main directly. its
    more of a convenience for client code. i have no objection to this rule
    ...with a disclaimer that we can make exceptions for exceptional
    circumstances (although i don't foresee any).
    I don't foresee any either. An argument could be made that the size of
    the dependency lists will be larger, but if that is a concern you should
    be doing a build which will take care of the dependency list size (and I
    hate saying that a build will solve problems). There's also an added
    benefit that lookups happen faster on objects with fewer properties on
    them which means looking up a function from the `dojo` object will be
    slower than the granular module that you can require. For instance:

    dojo/someModule.js:
    ===================
    declare(["./main", "./_base/array"], function(dojo, array){
    return {
    someOftenCalledFunction1: function(arr){
    return dojo.map(arr, function(item){
    dojo.forEach(item, function(subItem){
    // do something really neat here
    });
    });
    },
    someOftenCalledFunction2: function(arr){
    return array.map(arr, function(item){
    array.forEach(item, function(subItem){
    // do something really neat here
    });
    });
    }
    };
    });

    `someOftenCalledFunction1` will be slower than
    `someOftenCalledFunction2` because it is referencing the array functions
    from the `dojo` object rather than the `array` object. How much slower
    will depend on how many modules have added properties to the `dojo`
    object. Granted, the speed improvements will be on the millisecond
    level, but imagine that almost every module of a large application uses
    `dojo/someModule` (think dojo.declare). We don't want the toolkit being
    the bottleneck of an application.

    --
    Bryan Forbes
    http://www.reigndropsfall.net

    GPG Fingerprint
    3D7D B728 713A BB7B B8B1 5B61 3888 17E0 70CA 0F3D
  • Colin Snover at Jul 13, 2011 at 1:49 pm
    Inline.
    On 13/07/2011 12:11, Bryan Forbes wrote:
    i don't think we have any reason not to put them in lang. the only
    consequence is that we would need to update dependencies to properly use
    lang rather than kernel. this is low risk but could be extremely time
    consuming to find all the references.
    I wonder how many modules are using these 6 functions and have also
    included lang. It might not be as time consuming as you'd think (this is
    a wild speculation).
    It is pretty easy to find these function calls, but a little time
    consuming just by virtue of how many files there are to change. I?ve
    been doing work converting dojox stuff to baseless AMD, which involves
    doing exactly this kind of thing. I try to monitor changesets but am
    pretty bad at it, so if/when this change is made, could you send a note
    here or to me directly saying it?s done? I have some uncommitted patches
    on <http://bugs.dojotoolkit.org/ticket/12863> that I?ll need to update
    when that happens.
    6. defines dojo.deprecated/experimental
    7. defines dojo.eval, get/setObject, exists, mixin, _mixin.
    It is weird to me that deprecated/experimental are in kernel, though I?m
    not exactly sure where else is more appropriate. I agree with everyone
    so far that has said that #7 should go to lang.

    On a related note, it is also weird to me that pub/sub stuff is in
    dojo/_base/connect; I guess it is because it relies on the connect code,
    but that seems like a lot of extra dependency for anyone that just needs
    pub/sub (since connect also pulls in dojo/on and dojo/mouse). Also,
    dojo/_base/connect returns dojo.connect, which means the only way to
    access pub/sub stuff is through the dojo object, which is incorrect. I
    think this should really be fixed before 1.7.

    Regards,

    --
    Colin Snover
    http://zetafleet.com
  • Eugene Lazutkin at Jul 13, 2011 at 1:37 pm
    IIRC, the reasons for #7 in the kernel are purely historical --- all
    those functions were used in the bootstrap code at some time, and for
    those reasons were added to a bootstrap file directly, rather than
    lang.js. The thinking was that it can facilitate micro-kernel builds
    without "unnecessary" links to other modules.

    I think this reason is not valid now. Most probably they should be moved
    to lang.js. At least it sounds more logical to me.

    Cheers,

    Eugene

    PS: Countless times I looked for them in lang.js while debugging, or
    trying to find their inline docs. :-)
    On 7/13/11 11:25 AM, Rawld Gill wrote:
    When I originally created dojo/kernel, I essentially ported the dojo
    bootstrap (dojo/_base/loader/bootstrap) without putting much more
    thought into it.

    However, looking at all the work that's been done to use proper,
    minimal dependencies and looking at the base modules returning proper
    values makes me think that dojo/_base/kernel isn't quite right. For
    example, it seems that things like dojo.get/setObject and certainly
    dojo.mixin should go into dojo/_base/lang. In particular, when
    writing a modern AMD module, it seems odd to have to depend on
    dojo/_base/kernel to get access to dojo.mixin.

    Today dojo/_base/kernel

    1. defines dojo, dijit, dojox objects. 2. defines the scopemap 3.
    mixes the configuration into the dojo object 4. defines dojo.version
    5. guarantees the console 6. defines dojo.deprecated/experimental 7.
    defines dojo.eval, get/setObject, exists, mixin, _mixin.

    It seems to me that #7 belongs in lang. But maybe history and other
    expectations won't allow this move.

    What do others think?

    Thanks, Rawld
  • Bill Keese at Jul 20, 2011 at 1:59 am
    Oh I guess this implies that modules using dojo.experimental() or
    dojo.deprecated() will still need to include dojo/_base/kernel?

    I want to start converting dijit to baseless, so if I don't here from you
    soon I'm going to [temporarily] add dojo.eval, get/setObject, exists, mixin,
    _mixin to the return value from lang.js. Then you can check in the rest of
    the conversion (actually moving the function definitions) later.

    On Thu, Jul 14, 2011 at 1:25 AM, Rawld Gill wrote:

    When I originally created dojo/kernel, I essentially ported the dojo
    bootstrap
    (dojo/_base/loader/bootstrap) without putting much more thought into it.

    However, looking at all the work that's been done to use proper, minimal
    dependencies and looking at the base modules returning proper values makes
    me
    think that dojo/_base/kernel isn't quite right. For example, it seems that
    things like dojo.get/setObject and certainly dojo.mixin should go into
    dojo/_base/lang. In particular, when writing a modern AMD module, it seems
    odd
    to have to depend on dojo/_base/kernel to get access to dojo.mixin.

    Today dojo/_base/kernel

    1. defines dojo, dijit, dojox objects.
    2. defines the scopemap
    3. mixes the configuration into the dojo object
    4. defines dojo.version
    5. guarantees the console
    6. defines dojo.deprecated/experimental
    7. defines dojo.eval, get/setObject, exists, mixin, _mixin.

    It seems to me that #7 belongs in lang. But maybe history and other
    expectations won't allow this move.

    What do others think?

    Thanks,
    Rawld
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110720/c4baddb1/attachment.htm
  • Rawld Gill at Jul 20, 2011 at 6:05 am
    dojo.setObject, getObject, exists, mixin, _mixin have been moved from
    dojo/_base/kernel to dojo/_base/lang. I updated all of dojo and dijit. Tests
    seem OK.

    Expect errors in dojox and demos...I'm leaving that to project owners.

    Thanks,
    Rawld

    On Tuesday 19 July 2011 22:59:15 Bill Keese wrote:
    Oh I guess this implies that modules using dojo.experimental() or
    dojo.deprecated() will still need to include dojo/_base/kernel?

    I want to start converting dijit to baseless, so if I don't here from you
    soon I'm going to [temporarily] add dojo.eval, get/setObject, exists,
    mixin, _mixin to the return value from lang.js. Then you can check in
    the rest of the conversion (actually moving the function definitions)
    later.
    On Thu, Jul 14, 2011 at 1:25 AM, Rawld Gill wrote:
    When I originally created dojo/kernel, I essentially ported the dojo
    bootstrap
    (dojo/_base/loader/bootstrap) without putting much more thought into it.

    However, looking at all the work that's been done to use proper, minimal
    dependencies and looking at the base modules returning proper values
    makes me
    think that dojo/_base/kernel isn't quite right. For example, it seems
    that things like dojo.get/setObject and certainly dojo.mixin should go
    into dojo/_base/lang. In particular, when writing a modern AMD module,
    it seems odd
    to have to depend on dojo/_base/kernel to get access to dojo.mixin.

    Today dojo/_base/kernel

    1. defines dojo, dijit, dojox objects.
    2. defines the scopemap
    3. mixes the configuration into the dojo object
    4. defines dojo.version
    5. guarantees the console
    6. defines dojo.deprecated/experimental
    7. defines dojo.eval, get/setObject, exists, mixin, _mixin.

    It seems to me that #7 belongs in lang. But maybe history and other
    expectations won't allow this move.

    What do others think?

    Thanks,
    Rawld
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedJul 13, '11 at 12:25p
activeJul 20, '11 at 6:05a
posts9
users6
websitedojotoolkit.org

People

Translate

site design / logo © 2022 Grokbase