Replacing 'new'?

Discussion in 'Javascript' started by optimistx, Sep 22, 2009.

  1. optimistx

    optimistx Guest

    Some people call operator new as 'syntactic sugar', i.e. it can be replaced
    with some other code. Which code exactly?

    E.g.

    function A(b){
    this.b = b;
    this.m = function(){
    alert('m');
    }
    }

    var a1= new A('b');
    a1.m();

    //Is the following code equivalent, and if not, why not?

    function B(b){
    this.b = b;
    this.m = function (){
    alert('m');
    }
    var that = this;
    function inner(){
    return that;
    }
    return inner();
    }

    var a1 = B('b');
    a1.m();

    (quick test in firefox gave the same alert in both).

    Better(!) ways to achieve the same as with new-operator?

    The new-operator gives a non-callable new object (i.e. not a
    function), but inner-function above can be modified to give
    functions, too. There might be other possibilities with inner
    compared to new.

    Can the use of new-operator create accidental leaking closures as
    inner-functions could?

    If one can get rid of using new, is it possible to get rid of
    using 'this' also? (why should one want to do that? Only
    curious...).
    optimistx, Sep 22, 2009
    #1
    1. Advertising

  2. On 22 ÓÅÎ, 10:10, "optimistx" <> wrote:
    > Some people call operator new as 'syntactic sugar', i.e. it can be replaced
    > with some other code. Which code exactly?
    >
    > E.g.
    >
    > function A(b){
    > š this.b = b;
    > š this.m = function(){
    > š š alert('m');
    > š }
    >
    > }
    >
    > var a1= new A('b');
    > a1.m();
    >
    > //Is the following code equivalent, and if not, why not?
    >
    > function B(b){
    > š this.b = b;
    > š this.m = function (){
    > š š alert('m');
    > š }
    > švar that = this;
    > šfunction inner(){
    > š š return that;
    > š }
    > š return inner();
    >
    > }
    >
    > var a1 = B('b');
    > a1.m();
    >
    > (quick test in firefox gave the same alert in both).
    >
    > Better(!) šways to achieve the same as with new-operator?
    >
    > The new-operator gives a non-callable new object (i.e. not a
    > function), but inner-function above can be modified to give
    > functions, too. There might be other possibilities with inner
    > compared to new.
    >
    > Can the use of new-operator create accidental leaking closures as
    > inner-functions could?
    >
    > If one can get rid of using new, is it possible to get rid of
    > using 'this' also? (why should one want to do that? Only
    > curious...).



    The function object contains (beside other) three important
    components. If to describe that in pseudo-code, it looks like this:

    ----------------------------------------
    F = new NativeObject();

    F.[[Class]] = "Function"

    ..... // other properties

    F.[[Call]] = callObject // ÏÂßÅËÔ ×ÙÚÏ×Á

    F.[[Construct]] = internalConstructor // ÏÂÝÉÊ ×ÓÔÒÏÅÎÎÙÊ ËÏÎÓÔÒÕËÔÏÒ

    ..... // other properties

    // prototype of objects created by this function F
    __objectPrototype = {};
    __objectPrototype.constructor = F // {DontEnum}
    F.prototype = __objectPrototype
    ----------------------------------------

    So, for creating of objects is responsible internal [[Construct]]
    property, which is common constructor for all objects (exactly this
    [[Construct]] method gets new memory and creates object).

    Then, to *initialize* object internal [[Call]] method is called,
    passing *this* value as new created object by [[Construct]] method.

    [[Construct]] itself in pseudo-code looks lile this:

    ----------------------------------------
    F.[[Construct]](initialParameters):

    O = new NativeObject();

    // internal [[Class]] property - "Object", simple object
    O.[[Class]] = "Object"

    // get the object on which points
    // at *this moment* F.prototype
    var __objectPrototype = F.prototype;

    // if __objectPrototype - is object, then:
    O.[[Prototype]] = __objectPrototype
    // else:
    O.[[Prototype]] = Object.prototype;
    // where O.[[Prototype]] - is prototype of the new object

    // initialization of new object
    // by call F.[[Call]]; passes:
    // as "this" value - new object - O,
    // parameters are the same as initialParameters for F
    R = F.[[Call]](initialParameters); this === O;
    // where R - is the *result* of [[Call]] (return statement)

    // if R is object
    return R // that the trick which can say that *new* - is only "sugar"
    // else
    return O
    ----------------------------------------

    If it would be possible to change prototype of the object explicitly
    (i mean sure - but specification), the *new* expression will be really
    only "syntactic sugar":

    function A() {
    this.a = 10;
    }
    A.prototype.test = function () {}
    alert(this.a);
    ;
    var a = new A();
    a.test(); // 10

    The same:

    function A() {
    var newObject = {a: 10};
    newObject.__proto__ = A.prototype;
    return newObject;
    }
    A.prototype.test = function () {}
    alert(this.a);
    ;
    var a = A();
    a.test(); // 10

    // or even with *new*, no matter
    // as by algorithm [[Call]] will return "R"
    // as object, so passed "this" value will be
    // ignored
    var b = new A();
    b.test(); // 10

    For now, standard says nothing about changing of prototype of the
    object, only some realizations provide property such as .__proto__.

    And about your examples:

    > var a1= new A('b');
    > var a1 = B('b');


    "this" value in the second call will points on global object, so when
    you call "a1.m();", "this.m" refers on global.m (in DOM, window.m).
    Dmitry A. Soshnikov, Sep 22, 2009
    #2
    1. Advertising

  3. optimistx

    RobG Guest

    On Sep 22, 4:10 pm, "optimistx" <> wrote:
    > Some people call operator new as 'syntactic sugar', i.e. it can be replaced
    > with some other code. Which code exactly?


    This has been gone over a number of times here, search for "Crockford
    beget" and "Lasse Reichstein Nielsen Clone".

    >
    > E.g.
    >
    > function A(b){
    > this.b = b;
    > this.m = function(){
    > alert('m');
    > }
    >
    > }
    >
    > var a1= new A('b');
    > a1.m();
    >
    > //Is the following code equivalent, and if not, why not?
    >
    > function B(b){
    > this.b = b;
    > this.m = function (){
    > alert('m');
    > }
    > var that = this;
    > function inner(){
    > return that;
    > }
    > return inner();
    >
    > }
    >
    > var a1 = B('b');
    > a1.m();


    The difference is when you try inheritance. In the first case, a1 has
    an internal [[prototype]] property that references A.prototype. If you
    want to add or change inherited properties, you can do that by adding
    or changing the properties of A.prototype.

    In the second case, B's this keyword will be a reference to the global
    object and you have effectively created properties of that object.
    There is no opportunity for inheritance other than adding or modifying
    properties of the global object itself (i.e. no inheritance at all).

    alert(a1 == window); // true


    > (quick test in firefox gave the same alert in both).


    Insufficient testing will not reveal the errors of your assumptions.
    Better to understand what you are doing so you can test them properly.


    > Better(!) ways to achieve the same as with new-operator?


    Better by what criterion? That it doesn't use the new operator? Nor
    does:

    var a1 = window;

    That must be "best" by your yardstick.


    > The new-operator gives a non-callable new object (i.e. not a
    > function), but inner-function above can be modified to give
    > functions, too. There might be other possibilities with inner
    > compared to new.


    Native constructors will always return an Object object by default -
    that is how they are specified to behave. They must create a native
    Object object (ECMA-262 13.2.2). Constructors provided by the host
    environment can return whatever they like.

    When you create a new native function object, its [[prototype]]
    property *must* reference Function.prototype - there is nothing you
    can do about that, it has properties DontEnum, DontDelete, ReadOnly.
    However, you can augment it with new properties but all instances of
    Function inherit them. Or you can augment the function object itself
    (but there is no inheritance doing that).


    > Can the use of new-operator create accidental leaking closures as
    > inner-functions could?


    Closures, of themselves, don't necessarily cause memory leaks. IE had
    issues with memory leaks and circular references involving DOM
    elements (usually created by closures), but those issues have mostly
    been solved. It's considered a good strategy to avoid circular
    references anyway. There are likely other memory leaks in various
    browsers, research and testing should be on-going.


    > If one can get rid of using new,


    It depends on what you mean by "get rid of". The cure may be worse
    than the disease, there is no point in avoiding the use of the new
    operator just because someone told you not to like it. Do you actually
    have a reason?

    > is it possible to get rid of
    > using 'this' also?


    Its use can likely be avoided, but why?

    > (why should one want to do that? Only
    > curious...).


    Do some research, propose a strategy for "getting rid of it" and state
    why you think it's a superior alternative.


    --
    Rob
    RobG, Sep 22, 2009
    #3
  4. On Tue, 22 Sep 2009 at 00:09:37, in comp.lang.javascript, RobG wrote:
    >On Sep 22, 4:10 pm, "optimistx" <> wrote:
    >> Some people call operator new as 'syntactic sugar', i.e. it can be replaced
    >> with some other code. Which code exactly?

    >
    >This has been gone over a number of times here, search for "Crockford
    >beget" and "Lasse Reichstein Nielsen Clone".

    <snip>

    This is a bit misleading. Both beget and clone use 'new' to create the
    object.

    Of course, lots of people won't know that because they are unable to
    understand their favourite library :)

    John
    --
    John Harris
    John G Harris, Sep 22, 2009
    #4
  5. optimistx

    RobG Guest

    On Sep 23, 5:56 am, John G Harris <> wrote:
    > On Tue, 22 Sep 2009 at 00:09:37, in comp.lang.javascript, RobG wrote:
    > >On Sep 22, 4:10 pm, "optimistx" <> wrote:
    > >> Some people call operator new as 'syntactic sugar', i.e. it can be replaced
    > >> with some other code. Which code exactly?

    >
    > >This has been gone over a number of times here, search for "Crockford
    > >beget" and "Lasse Reichstein Nielsen Clone".

    >
    >   <snip>
    >
    > This is a bit misleading. Both beget and clone use 'new' to create the
    > object.


    Yes, because that is usually the best way to imlpement inhertiance. If
    the OP does reasearch the topics suggested, hopefully she or he will
    be more informed about the issues involved.

    An alternative to the new operator (though not a particularly good
    one) is to use a for..in loop to copy properties from a template
    object to a new object in much the same way as "extend" functions work
    in some libraries.


    > Of course, lots of people won't know that because they are unable to
    > understand their favourite library :)


    How many users of Prototype.js understand Class.create? :-(


    --
    Rob
    RobG, Sep 23, 2009
    #5
  6. optimistx

    JR Guest

    On Sep 22, 3:10 am, "optimistx" <> wrote:
    > Some people call operator new as 'syntactic sugar', i.e. it can be replaced
    > with some other code. Which code exactly?
    >
    > E.g.
    >
    > function A(b){
    >   this.b = b;
    >   this.m = function(){
    >     alert('m');
    >   }
    >
    > }
    >
    > var a1= new A('b');
    > a1.m();
    >


    Maybe (?):

    var someObj = {
    a: function (b) {
    this.b = b;
    return this;
    },

    say: function () {
    window.alert(this.b);
    }
    };

    someObj.a('Hi, Dude!').say(); // returns 'Hi, Dude!'

    > If one can get rid of using new, is it possible to get rid of
    > using 'this' also? (why should one want to do that? Only
    > curious...).


    It's very difficult to get (totally) rid of 'this' keyword. Check
    Douglas Crockford's website about the 'new' keyword.

    Cheers,
    JR
    JR, Sep 23, 2009
    #6
  7. optimistx

    JR Guest

    On Sep 22, 10:24 pm, JR <> wrote:
    > On Sep 22, 3:10 am, "optimistx" <> wrote:
    >
    >
    >
    > > Some people call operator new as 'syntactic sugar', i.e. it can be replaced
    > > with some other code. Which code exactly?

    >
    > > E.g.

    >
    > > function A(b){
    > >   this.b = b;
    > >   this.m = function(){
    > >     alert('m');
    > >   }

    >
    > > }

    >
    > > var a1= new A('b');
    > > a1.m();

    >
    > Maybe (?):
    >
    > var someObj = {
    >   a: function (b) {
    >     this.b = b;
    >     return this;
    >   },
    >
    >   say: function () {
    >     window.alert(this.b);
    >   }
    >
    > };
    >
    > someObj.a('Hi, Dude!').say(); // returns 'Hi, Dude!'


    Or:

    var a1 = someObj.a('Hi, Dude!');
    a1.say(); // returns 'Hi, Dude!'

    Cheers,
    JR
    JR, Sep 23, 2009
    #7
  8. On 23 Ñен, 06:10, Stefan Weiss <> wrote:
    > On 23/09/09 03:24, JR wrote:
    >
    >
    > I personally use factory methods when I need 1-10 objects, and
    > proper constructors with |new| when I expect to create a lot of objects.


    Do you think there's a big difference? - in one case (via constructor)
    same object will be returned as "this", in other one (via "factory") -
    u return this object yourself. If would be a legal ability to set
    prototype dynamicaly to objects (such as in commont prototypical
    theory), but not only using __proto__ of some realization, then
    there's no any difference at all.

    > I hardly ever use inheritance in the sense it's normally used; I use
    > mixins instead.


    Delegation is quite good in case of memory usage - one copy of method
    for all objects (but, such idiom is fits JS to dynamic-class based
    languages - state is in objects, methods are in "class"). And about
    mixins - extension of objects with new characteristics is not a mixin
    such as e.g. in Ruby, where mixin creates a _link_ to module (in other
    words - creates a new additional "prototype" for delegation, and
    extending module itself will affect on all objects mixed that module),
    but not copies all the properties to some objects - and again eats
    more memory. In case of methods, sure, it will be the reference to the
    same method in "mixin"-object, but properties (slots) will be own.

    /ds
    Dmitry A. Soshnikov, Sep 23, 2009
    #8
  9. optimistx

    optimistx Guest

    Stefan Weiss wrote:
    > function makeMeASandwich () {
    >
    > var tomato, lettuce, ...
    >
    > function bite () { ... }
    >
    > ...
    >
    > return {
    > bite: bite,
    > ....
    > };
    > }
    >
    > var sandwich = makeMeASandwich();
    > sandwich.bite();
    >
    > Some advantages of this approach are privacy, better encapsulation and
    > modularity, and the ability to refer to the object's properties and
    > methods without using |this| (inside makeMeASandwich). The downside is
    > increased memory usage, compared to creating objects with a
    > constructor whose .prototype already has a bite() method. In many
    > cases, the difference won't matter, but when you need lots of
    > objects, it can become noticable.


    A fascinating example, without this and without new, and there really was a
    sandwich to bite :). I played with that trying to
    access the prototype of the function makeMeASandwich to store a method
    there, but could not invent
    a way, at least not in 10 minutes.Is it impossible or awkward ( or both...)?
    optimistx, Sep 23, 2009
    #9
  10. On 23 Ñен, 15:41, Stefan Weiss <> wrote:
    > On 23/09/09 08:57, Dmitry A. Soshnikov wrote:


    > the resulting objects could each have
    > their own copies of methods, instead of referencing common function
    > objects from a prototype.


    Is there any sense in this? Yep, there's one - 'cause objects in ES
    are fully mutable, we can make _own_ individual characteristics
    (properties/methods) for _some_ objects in constructor (e.g. by
    condition - for some objects create additional method, for some - do
    not). Any other sense?

    > Some advantages of this approach are privacy, better encapsulation and
    > modularity


    Ah, that's btw the big (and unfortunately, widespread) mistake - to
    use encapsulation only for encapsulation.

    Encapsulation in it's main goal is _data abstraction_, but no _data
    hiding_. And such "private" and "protected" modifiers provided by some
    OOP-realizations - are just and only useful *syntactic sugar* (no
    more, mo less) to help _the programmer_ to build more abstract system.

    The wrong understanding of encapsulation (such as "the malicious
    hacker wants to write data directly into my field, but not via
    setter") is the reason of really non-useful and ugly non-abstract
    structures when create getter/setter just for simple:

    function A() {

    var _a; // "private"

    this.getA = function _getA() {
    return _a;
    };

    this.setA = function _setA(a) {
    _a = a;
    };

    }

    That's really bosh and delirium. There's no any reason do so, calling
    such stuff as "privileged" (wth?;) Just, as you correctly mentioned -
    increasing of memory usage.

    > and the ability to refer to the object's properties and
    > methods without using |this| (inside makeMeASandwich).


    is this a good reason to make for 1000 objects 1000 own slots?

    P.S.> but, btw, specification has optimization suggestion - joined
    objects (13.1.2), when [[Scope]] property is identical of two
    functions, realization could use the same function object, but in case
    of creating methods in constructor in hardly achieved, 'cause
    activation object of constructor can has every call different values,
    so [[Scope]] of internal functions will be different.

    /ds
    Dmitry A. Soshnikov, Sep 23, 2009
    #10
  11. On 23 Ñен, 19:05, Stefan Weiss <> wrote:

    Yeah, thx, for examples and explanations, I know about this stuff (and
    the reasons 'caused this struff).

    > In JS, I could prefix the method name with an underscore, but that's justan
    > unenforcable convention


    btw, to keep in mind that "that's not allowed" - is often the most
    useful encapsulation; but, sure, *syntactic sugar* as private,
    protected, public - is useful features (that's why there where
    suggested).

    But encapsulation itself is not related to private and protected: e.g.
    it could be simple function which *encapsulates* (please, pay
    attention, that i don't use *hides* word) some complex calculations
    making usage of it - *abstract* (yeah, for user it can be not so
    important *how* this function (e.g Math.round(...)) is written, he/she
    just uses it).

    > Now checkSlices() is accessible to any user of my Sandwich. I'd rather
    > hide it, because I may want to change it later


    Yes, sure, but saying that, you again think about encapsulation in
    "security" reason, afraid that some can change something that you
    don't wanna be changed. If someone wants to change encapsulating data
    - he will do it. Just opens your source code and make this method
    public. The reason is - user needs it. More than, as you know, such
    "encapsulated vars" is not 100% hidden - using eval in some
    implementation (e.g SpiderMonkey up to 1.7) we can pass calling
    context to evaluate and get the needed variable object in needed scope
    chain:

    function A() {
    var _a;
    function _getA() {
    return a;
    }
    return {
    getA: _getA
    };
    }

    var x = new A;
    print(x.getA()); // 10
    eval('_a = 100', x.getA); // as "_a" in [[Scope]] of x.getA
    print(x.getA()); // 100

    > and _checkSlices() would still be visible on each sandwich.


    Here's a good example how encapsulation is made in Python: there
    __private and _protected fields are made by this underscore name
    convention and are not accessible from the outside. But from the other
    hand, Python just renames such fields to _ClassName__privateField -
    and by this name, this property is already accessible from the
    outside. The reason? Again, programmer (doesn't matter who - author or
    user) wants by himself to get encapsulated data. And if will be some
    errors after that - responsible for that is fully programmer, but not
    "damn! someone again changed my field :(" or "what a typo!".

    class A(object):

    def __init__(self):
    self.__a = 10 # private

    def get_a(self):
    return self.__a

    a = A() # instance
    a.__a # error, __a is private
    a.get_a() # 10, it's ok
    a._A__a # renamed private which is public now, also 10

    Or in Ruby - from one hand there private and protected, but from the
    other hand - there're also
    methods .instance_variable_get, .instance_variable_set, .send, and so
    on, which allow access to encapsulated data. The reason again?
    Programmer or user doesn't afraid that someone will do directly with
    his data, he just wants to get that data in a program by some needed
    reason.

    But sure, common simple interface to the outside - is a good solution,
    and private and public sugar is useful *sugar* in some OOP-
    realizations. I wanted to say about exactly JS, that there's now big
    need to make that own methods in constructor for that. Encapsulation
    should be treated as *abstraction helper* which helps to build systems
    more clear. And if there's no this *sugar* as private and protected,
    keeping in mind that "that's not allowed" and maybe using some naming
    conventions as underscore - is quite good encapsulation. At least,
    you'll not eat much memory.

    > Or I could use a closure to store the private information:


    Or in your example, just use wrapped context when creating prototype -
    in any case checkSlices method is common:

    function Sandwich () {
    this.upperSlice = Bread.getSlice();
    this.lowerSlice = Bread.getSlice();
    }

    Sandwich.prototype = (function () {

    // initialization context

    function checkSlices () {
    if (this.upperSlice.size != this.lowerSlice.size) {
    throw new BreadException();
    }
    }
    function bite () {
    checkSlices();
    // reduce sandwich size
    }
    checkSlices();

    // prototype:
    return {
    constructor: Sandwich,
    bite: bite
    };

    })();

    var aSandwich = new Sandwich;


    > 1000 objects will always need 1000 "slots"


    I meant that 1000 objects will have in it's own properties always new
    function but with identical code; sure, that useless in meaning of
    memory usage.


    > For example, I would use it to implement a ticker or other widgets, but
    > I wouldn't use it to model points on a canvas or rows in a table.
    >


    Yeah, sure, your choice, i just wanted you to notice main
    encapsulation principle, and do not think that if you put something
    into private area, everything will be always OK from this moment.
    Nope, if user will want to change it - he will - repeat, just will
    open your source and change private to public. But if programmer is
    _understands_ what he does - there's no big need *in JS* to eat so
    much memory creating closured methods in constructor.

    In other systems, where, again repeat, there's that *sugar* (private,
    protected), sure it very useful, 'cause helps to build more *abstract*
    systems.

    /ds
    Dmitry A. Soshnikov, Sep 23, 2009
    #11
  12. optimistx

    JR Guest

    On 23 set, 10:25, "optimistx" <> wrote:
    > Stefan Weiss wrote:
    > >  function makeMeASandwich () {

    >
    > >      var tomato, lettuce, ...

    >
    > >      function bite () { ... }

    >
    > >      ...

    >
    > >      return {
    > >         bite: bite,
    > >         ....
    > >      };
    > >  }

    >
    > >  var sandwich = makeMeASandwich();
    > >  sandwich.bite();

    >
    > > Some advantages of this approach are privacy, better encapsulation and
    > > modularity, and the ability to refer to the object's properties and
    > > methods without using |this| (inside makeMeASandwich). The downside is
    > > increased memory usage, compared to creating objects with a
    > > constructor whose .prototype already has a bite() method. In many
    > > cases, the difference won't matter, but when you need lots of
    > > objects, it can become noticable.

    >
    > A fascinating example, without this and without new, and there really wasa
    > sandwich to bite :).  I played with that trying to
    > access the prototype of the function makeMeASandwich to store a method
    > there, but could not invent
    > a way, at least not in 10 minutes.Is it impossible or awkward ( or both....)?


    Then tell me how many 'new' sandwiches can you create with this
    'fascinating example'? I think only one.

    --
    JR
    JR, Sep 23, 2009
    #12
  13. Dmitry A. Soshnikov wrote:
    > On 23 Ñен, 19:05, Stefan Weiss <> wrote:
    >> Now checkSlices() is accessible to any user of my Sandwich. I'd rather
    >> hide it, because I may want to change it later

    >
    > Yes, sure, but saying that, you again think about encapsulation in
    > "security" reason, afraid that some can change something that you don't
    > wanna be changed. If someone wants to change encapsulating data - he will
    > do it. Just opens your source code and make this method public.


    Not necessarily. Think about how Google Maps v2 code is served, for example.

    > The reason is - user needs it.


    The user will seldom be aware of it if the documentation does not mention
    it, and maybe not even then. Besides, the user is likely to write their own
    code before they mess with existing objects. YMMV.

    > More than, as you know, such "encapsulated vars" is not 100% hidden -
    > using eval in some implementation (e.g SpiderMonkey up to 1.7) we can
    > pass calling context to evaluate and get the needed variable object in
    > needed scope chain:


    In languages as dynamical as these nothing can be really hidden if the
    implementation allows to circument its Specification's lexical restrictions.
    However, there is no harm in trying, when deemed necessary, in order to
    prevent things that should not happen under normal circumstances. To make
    life easier for both the implementor and the user of the code.

    I cannot agree with you here. Encapsulation is not only a means of
    providing structure; from the start it has been also a means of hiding
    implementation details from user access. That can provide a means of
    maintaining data integrity over the lifetime of an object.

    Suppose you have a property that should only assume allowed values. The
    only way you can (try to) enforce its data integrity in implementations of
    ECMAScript (up to Ed. 3) is to have a setter for it that checks whether the
    new value is in the allowed range. Without the implementation providing
    native supports for setters (newer ones do, but that is not cross-browser
    yet or even backwards-compatible), you have to resort to using a closure:
    the setter accesses a property defined in another execution context (the
    constructor's) and reproduces that execution context on call.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Sep 23, 2009
    #13
  14. optimistx

    optimistx Guest

    JR wrote:
    > Then tell me how many 'new' sandwiches can you create with this
    > 'fascinating example'? I think only one.


    Interesting question. If one is restricted not to use any data outside the
    function (not even
    with arguments) one might think that the returned object is exactly the same
    object every time.

    How could one find out?

    I made a small test at

    http://www.24.fi/optimistx/clj/sandwiches.htm

    Every generated object contained a random weight and an id (could be
    undefined also). All
    objects were pushed to an array.

    They were different.

    100 000 sandwiches took about 60M bytes, about 600 bytes each, and
    generating them took less than 5 seconds. The example on the page generates
    20 000 sandwiches. You may
    look at the test even when hungry.

    I tend to forget always that assigning an object (object reference) to a new
    variable does not
    copy the object to a new location:

    var a = {key1:1, key2:2}
    var b = a;

    a.key1 = 3;
    alert(b.key1); // gives 3
    optimistx, Sep 23, 2009
    #14
  15. On 23 Ñен, 23:07, Thomas 'PointedEars' Lahn <PointedE...@web..de>
    wrote:
    > Dmitry A. Soshnikov wrote:
    > > On 23 Ñен, 19:05, Stefan Weiss <> wrote:
    > >> Now checkSlices() is accessible to any user of my Sandwich. I'd rather
    > >> hide it, because I may want to change it later

    >
    > > Yes, sure, but saying that, you again think about encapsulation in
    > > "security" reason, afraid that some can change something that you don't
    > > wanna be changed. If someone wants to change encapsulating data - he will
    > > do it. Just opens your source code and make this method public.

    >
    > Not necessarily.  Think about how Google Maps v2 code is served, forexample.


    Doesn't matter - loaded code could be changed if needed. But sure,
    nobody will do so, it's just in theory.

    >
    > > The reason is - user needs it.

    >
    > The user will seldom be aware of it if the documentation does not mention
    > it, and maybe not even then.  Besides, the user is likely to write their own
    > code before they mess with existing objects.  YMMV.


    Sure, and from this point of view, even also doesn't matter how will
    be some property exists - in public mode or in private - "user will
    seldom be of it". I remind, i'm talking from the position of ES and
    creating methods in constructor. But about private properties in other
    OOP-realizations, i repeat, i think it's useful "abstraction layer" -
    for to make less object relation mistakes (if the are).

    > > More than, as you know, such "encapsulated vars" is not 100% hidden -
    > > using eval in some implementation (e.g SpiderMonkey up to 1.7) we can
    > > pass calling context to evaluate and get the needed variable object in
    > > needed scope chain:

    >
    > In languages as dynamical as these nothing can be really hidden if the
    > implementation allows to circument its Specification's lexical restrictions.
    >  However, there is no harm in trying, when deemed necessary, in order to
    > prevent things that should not happen under normal circumstances.  To make
    > life easier for both the implementor and the user of the code.
    >


    >  Encapsulation is not only a means of
    > providing structure; from the start it has been also a means of hiding
    > implementation details from user access.  That can provide a means of
    > maintaining data integrity over the lifetime of an object.
    >


    Your talking about access level and its modificators - private,
    protected, public. But, encapsulation - is not only that features.
    Vice versa, that access level features is *extension* of encapsulation
    meaning. Take, again, simple function, mentioned above as
    encapsulation entity. This function *encapsulates* details of its
    implementation from the user. That's encapsulation from the start.
    Increasing of abstraction. And than, after all that - access level
    where suggested, as increasing of encapsulation - *to help* the
    *programmer* build more abstract systems with *controlled*
    relationship of the objects.

    > Suppose you have a property that should only assume allowed values.  The
    > only way you can (try to) enforce its data integrity in implementations of
    > ECMAScript (up to Ed. 3) is to have a setter for it that checks whether the
    > new value is in the allowed range.  Without the implementation providing
    > native supports for setters (newer ones do, but that is not cross-browser
    > yet or even backwards-compatible),


    The main goal of setter - is *abstraction*. Yeah, sure, the one most
    useful feature of the setter is validation of incoming data. But also
    - it makes complex computations, can use other object in it and so on
    - that *is abstraction*! When you use someElement.innerHTML = '...' -
    you just *abstractly* (the most popular word here ;) say: "now html of
    this element is being that one". And in innerHTML setter will be
    checks, validations, parsing, building and modifying tree and many
    other things that are *abstracted* from you - for that you can
    concentrate on programming of higher level.

    > you have to resort to using a closure:
    > the setter accesses a property defined in another execution context (the
    > constructor's) and reproduces that execution context on call.


    yeah, thx, i know that.

    /ds
    Dmitry A. Soshnikov, Sep 23, 2009
    #15
  16. optimistx

    RobG Guest

    On Sep 23, 11:25 pm, "optimistx" <> wrote:
    > Stefan Weiss wrote:
    > >  function makeMeASandwich () {

    >
    > >      var tomato, lettuce, ...

    >
    > >      function bite () { ... }

    >
    > >      ...

    >
    > >      return {
    > >         bite: bite,
    > >         ....
    > >      };
    > >  }

    >
    > >  var sandwich = makeMeASandwich();
    > >  sandwich.bite();

    >
    > > Some advantages of this approach are privacy, better encapsulation and
    > > modularity, and the ability to refer to the object's properties and
    > > methods without using |this| (inside makeMeASandwich). The downside is
    > > increased memory usage, compared to creating objects with a
    > > constructor whose .prototype already has a bite() method. In many
    > > cases, the difference won't matter, but when you need lots of
    > > objects, it can become noticable.

    >
    > A fascinating example,


    It is a well known pattern, explained by Douglas Crockford here:

    <URL: http://www.crockford.com/javascript/private.html >

    Crockford's example is in the context of a constructor, so it uses
    both 'this' and 'new'. There are many other examples, search the web
    or the archives for "module pattern" (use the advanced search, the
    standard search is crap):

    <URL:
    http://groups.google.com/groups/sea...javascript&as_usubject=&as_uauthors=&safe=off
    >



    > without this and without new, and there really was a
    > sandwich to bite :).


    And without inheritance[1]. Each time makeMeASandwich is called, the
    object it returns has its own copy of every method and data item added
    by the "constructor". It implements the concepts of public, private an
    privileged members, but leaves out inheritance.

    1. strictly, there is inheritance from Object.prototype, but that is a
    consequence of the default environment, not the code pattern.


    --
    Rob
    RobG, Sep 24, 2009
    #16
  17. optimistx

    RobG Guest

    On Sep 24, 11:01 am, Stefan Weiss <> wrote:
    > On 24/09/09 01:20, RobG wrote:
    >
    > > And without inheritance[1]. Each time makeMeASandwich is called, the
    > > object it returns has its own copy of every method and data item added
    > > by the "constructor". It implements the concepts of public, private an
    > > privileged members, but leaves out inheritance.

    >
    > > 1. strictly, there is inheritance from Object.prototype, but that is a
    > > consequence of the default environment, not the code pattern.

    >
    > I saw that as a drawback, too,


    Presumably you mean the lack of inheritance. It is not a "drawback"
    of the module pattern per se: it neither enforces or precludes
    inheritance.

    I was pointing out that while the OP's requirement was to implement
    some form of inheritance, the example provided doesn't do that.


    --
    Rob
    RobG, Sep 24, 2009
    #17
  18. On 24 Ñен, 02:08, Stefan Weiss <> wrote:

    > The reason why I
    > want to keep the hypothetical checkSlices() function from being exposed
    > as a "public" method is that I need to be able to change its
    > implementation, or remove it entirely, without worrying about any other
    > code which may use my object.


    yep, that's a good reason, and actually main reason (sure i agree in
    here) - you *abstracts* realization of your system by not worrying
    other programmers use your system concentrate on details of
    implementation, but thinking about more creative tasks on which the
    system (you wrote) was written. When, e.g. you create UI window, you
    already think in *abstractions* of UI system, thinking and speaking in
    its terminology, its ideology. And don't think that its just graphical
    pixels written at least on assembler (or anything else, no matter) -
    this part has been abstracted from you by creator of this UI system.

    > If they don't see the method, they won't
    > be tempted to use it, and won't be affected by its change or removal.
    >


    Sure and certainly, i repeat again that i think access levels
    (private, protected and so on) - is really useful features that
    increase encapsulation (abstraction of the system), please don't think
    that i'm telling - "no, access levels is delirium and don't needed",
    nope. I repeat, that i'm telling only in context of ES and creating
    methods in constructor.

    But users, again - if they need - will change your private access
    level if they will be needed that. Even if they don't see that method
    first. That's not the reason. The reason is that you mentioned above
    (with not worrying users to think about implementation), but this one
    - is not the reason.

    > Responsible users won't call myObject.dataSource.send("raw query")
    > directly, but IMO the dataSource has no place in myObject's API.
    >


    sure, again i repeat, external API controlled by access level *sugar*
    - is a good helper of more abstract and stable system. And one repeat
    - i'm telling about ES and creating such methods in constructor and
    think that's not needed (only if encapsulation is treated in wrong
    sense - as security reasons).

    > That won't work. Look at what |this| in checkSlices refers to.
    >


    Gee, thought you'll find out that's a typo, i copy-pasted it from your
    code. But, anyway, thx for correction ;) Sure, there should be:

    function bite () {
    checkSlices.call(this);
    // reduce sandwich size
    }


    On 24 Ñен, 03:20, RobG <> wrote:

    > Crockford's ...


    > ... concepts of ... private an
    > privileged members


    Do you think this terminology is good for object's own-methods having
    access to lexical context? Unfortunately, many folks on forums
    arguing using this "privileged members" terminology as it's own and
    exact for JS, thinking and truly believing that it's true.
    Dmitry A. Soshnikov, Sep 24, 2009
    #18
  19. Dmitry A. Soshnikov wrote:
    > On 23 Ñен, 23:07, Thomas 'PointedEars' Lahn <PointedE...@web..de>
    > wrote:
    >> Dmitry A. Soshnikov wrote:
    >>> On 23 Ñен, 19:05, Stefan Weiss <> wrote:
    >>>> Now checkSlices() is accessible to any user of my Sandwich. I'd rather
    >>>> hide it, because I may want to change it later
    >>> Yes, sure, but saying that, you again think about encapsulation in
    >>> "security" reason, afraid that some can change something that you don't
    >>> wanna be changed. If someone wants to change encapsulating data - he will
    >>> do it. Just opens your source code and make this method public.

    >> Not necessarily. Think about how Google Maps v2 code is served, for example.

    >
    > Doesn't matter - loaded code could be changed if needed. But sure,
    > nobody will do so, it's just in theory.


    Yes, your arguments seem to have little to do with practical experience, really.

    >>> More than, as you know, such "encapsulated vars" is not 100% hidden -
    >>> using eval in some implementation (e.g SpiderMonkey up to 1.7) we can
    >>> pass calling context to evaluate and get the needed variable object in
    >>> needed scope chain:

    >> In languages as dynamical as these nothing can be really hidden if the
    >> implementation allows to circument its Specification's lexical restrictions.
    >> However, there is no harm in trying, when deemed necessary, in order to
    >> prevent things that should not happen under normal circumstances. To make
    >> life easier for both the implementor and the user of the code.

    >
    >> Encapsulation is not only a means of
    >> providing structure; from the start it has been also a means of hiding
    >> implementation details from user access. That can provide a means of
    >> maintaining data integrity over the lifetime of an object.

    >
    > Your talking about access level and its modificators - private,
    > protected, public.


    Not only.

    > But, encapsulation - is not only that features.


    I know.

    > Vice versa, that access level features is *extension* of encapsulation
    > meaning. Take, again, simple function, mentioned above as
    > encapsulation entity. This function *encapsulates* details of its
    > implementation from the user. That's encapsulation from the start.


    No. Encapsulation means that instead of having data and functionality
    separate, an entity (object) encapsulates functionality that operate its
    specific data.

    > Increasing of abstraction. And than, after all that - access level
    > where suggested, as increasing of encapsulation - *to help* the
    > *programmer* build more abstract systems with *controlled*
    > relationship of the objects.


    Nonsense. There are no levels of encapsulation.

    >> Suppose you have a property that should only assume allowed values. The
    >> only way you can (try to) enforce its data integrity in implementations of
    >> ECMAScript (up to Ed. 3) is to have a setter for it that checks whether the
    >> new value is in the allowed range. Without the implementation providing
    >> native supports for setters (newer ones do, but that is not cross-browser
    >> yet or even backwards-compatible),

    >
    > The main goal of setter - is *abstraction*.


    Not to me.


    PointedEars
    --
    Danny Goodman's books are out of date and teach practices that are
    positively harmful for cross-browser scripting.
    -- Richard Cornford, cljs, <cife6q$253$1$> (2004)
    Thomas 'PointedEars' Lahn, Sep 24, 2009
    #19
  20. On 24 Ñен, 13:12, Thomas 'PointedEars' Lahn <PointedE...@web..de>
    wrote:
    > Dmitry A. Soshnikov wrote:
    > > On 23 Ñен, 23:07, Thomas 'PointedEars' Lahn <PointedE...@web..de>
    > > wrote:
    > >> Dmitry A. Soshnikov wrote:
    > >>> On 23 Ñен, 19:05, Stefan Weiss <> wrote:
    > >>>> Now checkSlices() is accessible to any user of my Sandwich. I'd rather
    > >>>> hide it, because I may want to change it later
    > >>> Yes, sure, but saying that, you again think about encapsulation in
    > >>> "security" reason, afraid that some can change something that you don't
    > >>> wanna be changed. If someone wants to change encapsulating data - he will
    > >>> do it. Just opens your source code and make this method public.
    > >> Not necessarily.  Think about how Google Maps v2 code is served, for example.

    >
    > > Doesn't matter - loaded code could be changed if needed. But sure,
    > > nobody will do so, it's just in theory.

    >
    > Yes, your arguments seem to have little to do with practical experience, really.
    >


    Are you interesting only in applied, practical level? If core
    principles are not interesting to you, don't be worry ;)

    > > But, encapsulation - is not only that features.

    >
    > I know.
    >


    Good than.

    > > Vice versa, that access level features is *extension* of encapsulation
    > > meaning. Take, again, simple function, mentioned above as
    > > encapsulation entity. This function *encapsulates* details of its
    > > implementation from the user. That's encapsulation from the start.

    >
    > No.  Encapsulation means that instead of having data and functionality
    > separate, an entity (object) encapsulates functionality that operate its
    > specific data.
    >


    What "No"? The description you gave (combination of data and
    functionality) - *is* one description and meaning of *abstraction*.
    Here you right - but just with alternative terminology.

    > > Increasing of abstraction. And than, after all that - access level
    > > where suggested, as increasing of encapsulation - *to help* the
    > > *programmer* build more abstract systems with *controlled*
    > > relationship of the objects.

    >
    > Nonsense.  There are no levels of encapsulation.
    >


    Please, don't mixing up terminology. I didn't say "abstraction is
    divided into levels", I mentioned that what u mean - is just useful
    suggestion to make relationship of the objects more abstract and
    controlled. And only for *programmers*.

    >> The main goal of setter - is *abstraction*.

    >
    > Not to me.
    >


    As you wish, but i didn't come exactly to you ;) But glad to have
    conversation with anyone interested in ES.

    /ds
    Dmitry A. Soshnikov, Sep 24, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jay Nabonne
    Replies:
    6
    Views:
    2,170
    Jay Nabonne
    Jan 19, 2005
  2. Mark P

    replacing operator new

    Mark P, Apr 20, 2006, in forum: C++
    Replies:
    2
    Views:
    279
    Mark P
    Apr 21, 2006
  3. Rob Meade

    Replacing - and not Replacing...

    Rob Meade, Apr 5, 2005, in forum: ASP General
    Replies:
    5
    Views:
    273
    Chris Hohmann
    Apr 11, 2005
  4. Replies:
    4
    Views:
    198
  5. Replies:
    2
    Views:
    448
    Thomas 'PointedEars' Lahn
    Mar 11, 2008
Loading...

Share This Page