Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Vladimir Starkov
    @iamstarkov
    @Milannist are you still not using bem-tools or enb for building your project?
    Ilya Rogov
    @ilyar

    Please kick me!

    demo

    /* global modules:false */
    modules.define('singleton', ['inherit'], function (provide, inherit, Singleton) {
    
        /**
         * @abstract
         * @class Singleton
         */
        Singleton = inherit( /** @lends Singleton.prototype */ {
    
            /**
             * Must be implemented by subclass
             * @constructor
             * @private
             */
            __constructor: function () {}
    
    
        }, /** @lends Singleton */ {
    
            /**
             * Instance stores a reference to the Singleton
             * @private
             */
            _instances: [],
    
            /**
             * Get the Singleton instance if one exists or create one if it doesn't
             * @param c
             * @returns {*}
             */
            getInstance: function (c) {
    
                if (!this._instances[c]) {
                    this._instances[c] = new c;
                }
    
                return this._instances[c];
            }
        });
    
        provide(Singleton);
    
    });
    Alexander Savin
    @apsavin
    @ilyar, why not
    modules.define('my-singleton', function (provide) {
        var MySingleton = function(){};
        provide(new MySingleton());
    });
    Sergey Berezhnoy
    @veged
    @ilyar describe more what you wanna achieve — otherwise I +1 with @apsavin ;-)
    Ilya Rogov
    @ilyar
    /**
    * Usage singleton
    * @link http://jsfiddle.net/ilyar/8A5AB/
    */
    modules.define('my-singleton', ['inherit', 'singleton'], function (provide, inherit, Singleton, MySingleton) {
    
        /** @class MySingleton */
        MySingleton = inherit(Singleton, /** @lends MySingleton.prototype */ {
    
            /**
             * @constructor
             * @private
             */
            __constructor: function () {
                this._property = null;
            },
    
            setProperty: function (property) {
                this._property = property;
            },
    
            getProperty: function () {
                return this._property;
            }
    
        }, /** @lends MySingleton */ {
    
            getInstance: function () {
                return this.__base(this);
            }
    
        });
    
        provide(MySingleton);
    
    });
    
    modules.require(['my-singleton'], function (mySingleton) {
        var singleA = mySingleton.getInstance();
        var singleB = mySingleton.getInstance();
        alert(singleA === singleB)
    });
    Ilya Rogov
    @ilyar
    @veged I want to hear criticism of the implementation of the Singleton pattern.
    Sergey Berezhnoy
    @veged

    @ilyar I can't catch the point, why you need such separate block? you can simple use approach which suggested by @apsavin or use inherit in similar manner

    also, implement of getInstance method for my-singleton looks unnecessary

    Andrew Balakirev
    @jifeon
    I think there is some misunderstanding here. @ilyar do you understand that the code inside define always runs only once?
    Ilya Rogov
    @ilyar
    @veged @apsavin @jifeon Thank you!
    Vladimir Starkov
    @iamstarkov
    block A mustdeps block B, block B nodeps block A. Who wins?
    Sergey Berezhnoy
    @veged
    @matmuchrapna by default -- nodeps
    Vladimir Starkov
    @iamstarkov
    @veged that's mean final deps will be empty?
    Sergey Berezhnoy
    @veged
    @matmuchrapna it can depend on concrete code (in case of some priorities) — can you show example?
    Vladimir Starkov
    @iamstarkov
    desktop.bundles/index/block/A/A.deps.js // ({ mustDeps: [{ block: 'B' }])
    desktop.bundles/index/block/B/B.deps.js // ({ noDeps: [{ block: 'A' }])
    I want to see deps for block A
    Sergey Berezhnoy
    @veged
    for which bemdecl?
    Vladimir Starkov
    @iamstarkov
    for A bemdecl
    Sergey Berezhnoy
    @veged
    if only A block appear — it should be without B deps
    you can test it
    maybe it vary for different tools and versions
    but in my general understanding it should be just A, because we have noDeps between A and B
    so the semantic of noDeps is to delete dependency link between entities
    and noDeps have the top most priority
    Vladimir Starkov
    @iamstarkov
    in my mind there are to options:
    1. final deps list wll be empty
    2. final deps will contain only B block
    I didn't guess, right?
    Sergey Berezhnoy
    @veged
    ouch! I miss read your example :-( in your case second file (B.deps.js) have no impact at all
    B noDeps A means that if you have anywhere B mustDeps A it's gonna be deleted
    if you have A mustDeps B there is nothing to delete with B noDeps A
    Vladimir Starkov
    @iamstarkov
    Where I can read about nodeps mechanism?
    Vladimir Starkov
    @iamstarkov
    I have not find any spec about deps on bem.info
    Vsevolod Strukchinsky
    @floatdrop
    Some part of docs about (should|must|no)Deps is here - http://ru.bem.info/tools/bem/bem-tools/depsjs/
    Docs says:
    noDeps cancels dependencies on lower redefinition levels, preserving them only to the level the noDeps property is defined upon
    But what is lower level of definition?
    Is is works this way? A mustDeps B + A noDeps C + B mustDeps C = A B?
    Or it should only affect levels, but not inheritance in same level of definitions?
    Sergey Berezhnoy
    @veged
    noDeps cancel dependencies — it means that A mustDeps B + A noDeps B = A
    more real example — if you have library with some dependency between particular two blocks you can delete it (exactly) on your project level throughout noDeps
    so noDeps doesn't mean that you "delete block from result" but means that you "remove particular dependency link between particular blocks" (actually it's work not only for block but for any BEM-entities: blocks, elems, modifiers)
    Vsevolod Strukchinsky
    @floatdrop
    Why documentation mentions lower redifinition level?
    Sergey Berezhnoy
    @veged
    it means lower in order of build: usually you have something like "core lib", "project level", "page level"
    so the page level is lowest one and so on
    but you can also use noDeps in same level — they will have top most priority among mustDeps/shouldDeps
    Vladimir Starkov
    @iamstarkov
    now I don't understand noDeps at all.
    Sergey Berezhnoy
    @veged
    it's much more ease then you can think about :-) it's just a rollback for particular dependency declaration — if you decl A->B you can later say "no, cancel deps A->B" — thats it!
    Vladimir Starkov
    @iamstarkov
    at build bem tools have graph of blocks with should and must connections to other blocks in graph. So if block1 connect to block2 with should or must connection, then if block2 have block1 in noDeps then all block1's connections to block2 cancelled?
    Sergey Berezhnoy
    @veged
    and do not take in mind any levels stuff — it gonna be intuitive if you start to decl what you want
    Vladimir Starkov
    @iamstarkov
    am i right with prev question?
    Sergey Berezhnoy
    @veged
    if b2 have noDeps to b1 it doesn't affect any b1 deps b2
    Vsevolod Strukchinsky
    @floatdrop
    does it affects dependencies in upper levels of declaration (for example bem-core)?
    Sergey Berezhnoy
    @veged
    b2 noDeps b1 affects only b2 *Deps b1