Replacing 'new'?

[optimistx]

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...).

 

[Dmitry A. Soshnikov]

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).

 

[RobG]

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.

 

[John G Harris]

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

 

[RobG]

  <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? :-(

 

[JR]

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]

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

 

[Dmitry A. Soshnikov]

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

 

[optimistx]

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...)?

 

[Dmitry A. Soshnikov]

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]

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

 

[JR]

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.

 

[Thomas 'PointedEars' Lahn]

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

 

[optimistx]

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

 

[Dmitry A. Soshnikov]

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 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).

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

 

[RobG]

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.

 

[RobG]

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.

 

[Dmitry A. Soshnikov]

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
}

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.

 

[Thomas 'PointedEars' Lahn]

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.

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.

The main goal of setter - is *abstraction*.

Not to me.


PointedEars

 

[Dmitry A. Soshnikov]

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

I know.

Good than.

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.

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*.

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