Restricting A Function To Be In Scope of Constructor Method

The code below shows the familiar way of restricting a function to be a
method of a constructed object:

function aConstructor(arg)
{
if (typeof(arg) == "undefined")
return (null);
this.property1 = arg;
this.property2 = aConstantDefinedGlobally;
this.method1 = function (anArg) {
return (this.property1 + this.property2);
};
this.method2 = function (arg1, arg2) {
var aVar = arg1 + this.property1;
// a lot---maybe 100 lines of method code
// .
// .
// .
// .
};
return (this);
}

Method 'method1' and the code manipulating object properties was added to
make it a better example in showing brief bits of code.

Note that method 'method2' is rather long in terms of lines of code.

Suppose for the sake of code readability, the attempt is made to define
the method "external" to the constructor, but that it still be a method of
the object, and not a function in global scope (oh, and another question:
is a function actually a method of the global object?). As so:

function method2(arg1, arg2)
{
var aVar.arg1 + this.property1;
// lots of lines of code follows
}

function aConstructor(arg)
{
if (typeof(arg) == "undefined")
return (null);
this.property1 = arg;
this.property2 = aConstantDefinedGlobally;
this.method1 = function (anArg) {
return (this.property1 + this.property2);
};
this.method2 = method2;
return (this);
}

Of course, this was tried and does not work, with the 'this' object is
function method2 is the global object.

So the question is, how can I set up the code so that method 'method2'
remains a method of the constructor and should not be called as a function
in global scope?

re: Restricting A Function To Be In Scope of Constructor Method

Patient Guy wrote:
<snip>There is no point in doing this in a constructor as a NewExpression
cannot evaluate as a primitive value (including Null). If you try to
return a primitive value from a constructor the result will still be the
object constructed.
There is no point in explicitly returning - this -.
Given the code you show the optimum definition would be:-

function aConstructor(arg){
this.property1 = arg;
}

aConstructor.prototype.method1 = function (anArg) {
return (this.property1 + this.property2);
};

aConstructor.prototype.method2 = function(arg1, arg2){
var aVar.arg1 + this.property1;
// lots of lines of code follows
};

aConstructor.prototype.property2 = aConstantDefinedGlobally;

(with the considerable advantage that the function objects that
represent the methods are only created once and their assignments is
also only made once).
In javascript the - this - value is always, and only, determined by how
a function is called. You have not shown any code that instantiates
objects or calls methods of those objects so your assertions about the -
this -value - are no more than assertions.
There is no indication in your posted code than you have any actual
desire to create methods of the constructor.
You are in control of how you call your code.

Richard.

re: Restricting A Function To Be In Scope of Constructor Method

"Richard Cornford" <Richard@litotes.demon.co.ukwrote in
comp.lang.javascript:
Yes, I have seen this. Probably a more careful reading of the
specification will tell me that when no object is to be instantiated, it
is better to return nothing?


Okay.



This is probably what I am looking for and will test. How well is this
implemented in different environments (browsers) claiming to run
Javascript?



You can see that within the first example of the constructor function I
defined as a method an "external" function (a function in global scope),
or by "external," a function outside the scope of the constructor
function. It was my intention that by defining the external function as a
method of the constructor, that the function would inherit the object
being constructed as 'this,' but this was clearly not the case.

With C++ of course, there is the notation

class::method

which can be used for privileged method definition outside the class
definition. I was just trying to find the Javascript alternative if there
was one.

The first example of the constructor function I gave showed coding that
defined methods to the constructor in which the code was within the
constructor (function) definition.

The example that followed was an explanation of my attempt to define
methods outside the constructor function definition (beyond its braces
'{}') and also restrict the function definition as being a method of the
constructor. I just was unable to find the correct coding for making that
restriction.

re: Restricting A Function To Be In Scope of Constructor Method

Patient Guy wrote:<snip>NewExpression cannot evaluate as a primitive value (including
Undefined).

<snip>It probably is not, but it is how the code you posted should have been
written.
Most browsers that claim to run javascript actually do run javascript.
The context in which a function is declared (or function expression
evaluated) influences its scope chain.
"Defining the external function as a method of the constructor" is
meaningless. You never assigned any functions as methods of the
constructor.
In javascript the - this - value in a function is determined always, and
only, by how a function is called (or a per-call basis).
C++ is not javascript (not even very like javascript).

<snip>"Defined methods to the constructor" is more meaningless than the last
formulation. There is no indication in your posted code than you have
any actual desire to create methods of the constructor.
Apart from the whole "method of the constructor" thing being an apparent
misconception of what a method of an object is, there is nothing in your
post to suggest what it is you are trying to do, just different ways of
failing to do whatever it is.
Pinning down why you want to make "that restriction" is probably the
quickest approach to finding out what you need to know.
<snip>

Richard.

re: Restricting A Function To Be In Scope of Constructor Method

Patient Guy wrote:
[...]As Richard said, the value of the this operator is established by how
the function is called. It always refers to the object that the
function is a method of, so if you want a function's this operator to
point to a particular object, you have to add a property to the object
that references the function, then use it to call the function:

function FuncA (){
this.name = 'functionA';
}

function funcB(){
alert(this.name);
}

var blah = new FuncA();
blah.funcB = funcB;
blah.funcB(); // Shows 'functionA'


The call method is another option:

funcB.call(blah); // Shows 'functionA'


[...]
Then why not just declare it as a property of the function or (more
efficiently) as a property of its prototype:

function FuncA (){
this.name = 'functionA';
}

FuncA.prototype.funcB = function(){
alert(this.name);
}

var blah = new FuncA();
blah.funcB(); // Shows 'functionA'

If you mean declared and added from outside the function's scope (it
may not be global, it could be within the scope of some other function)
and not available at all to other functions, then I think it's not
possible. So called "private" methods can only be added from within
the function's own scope - otherwise, they wouldn't be characterised as
"private".


--
Rob

re: Restricting A Function To Be In Scope of Constructor Method

Patient Guy wrote:A brief answer:
You can't do it in JavaScript because of a specification bug (because
of well-thought engine mechanics, because of bad implementations of
totally right specifications, because of ... - you really choose the
best from the list or fill your own one: do not start yet another
discussions :-)

Because of this ... phenomenon an external (declared in the Global
scope) function is just an external function no fricking matter what,
even if you made it to be a member of a custom object.
(ECMA specs are telling the same in much more details and by using many
savvy words, but the above sentence really contains all info you really
need to get the idea).



A medium-length answer:
External functions know nothing about custom objects they appertain to
and there is no way to educate them by the conventional ways. But:

a) Unless you are using JScript.NET or planning to use your script in
JScript.NET later: you can augment the function object to hold some
extra info. (JScript.NET if compiled or/and run in quick mode doesn't
allow function augmentation and it will break with error).

b) Functions do not know if and what custom objects do they appertain
to, but they can point *sometimes* to the object-caller over
arguments.caller property. Unfortunately there were security issues
with this property and it is not consistent across modern browsers. It
is either removed all together or partially blocked. It also says
"null" most of the time, and most of the time it says it at the time
when you'd like to hear something completely else :-)

By choosing or by combining both ways And by accepting more narrow set
of supported environments you can emulate in external functions (with
an acceptable level of "trust-wordiness"):


1) Static protected method of a singleton:

<script>
function method1() {
// a lot of code
// and finally:
if (method1.owner) {
window.alert(method1.owner.name);
}
}

function myConstructor() {
if (myConstructor.$instance) {
return myConstructor.$instance;
}
else {
myConstructor.$instance = this;
this.name = 'myObject';
this.method1 = method1;
this.method1.owner = this;
}
}

var obj = new myConstructor();
obj.method1();
</script>


2) Static protected method constructor of a class constructor. That was
I guess what you called "in the scope of constructor method"

<script>
function method1() {
window.alert('The Glory and the mISERY of JavaScript...');
}
method1.toString = function() {
if ((arguments.caller)
&&(arguments.caller === myConstructor)) {
return method1;
}
else {
return window.alert('Error');
}
}

function myConstructor() {
this.method1 = method1;
}

var obj = new myConstructor();
obj.method1();
method1();
</script>

You noticed of course that this method is still only "half-protected".
It will refuse to participate in any constructions unless they led by
myConstructor. You may add to the last check
.... ||(myConstructor.isPrototypeOf(arguments.caller))
to allow not only myConstructor but also its derivates, but it gets a
bit shaky.

At the same time it still can be called as a stay-alone function.
Unfortunately this is only as far as JavaScript goes. Up to you to make
sure that any calls would be useless/harmless outside of the class
constructor (or start to cook with function-wrappers to call your
method but it gets too much ugly to discuss - yet technically
possible).



Long answer:
All of the above was about some abstract JavaScript running within the
engine to only purpose to run. It is not true for the absolute majority
of real cases. In real cases you usually run your scripts to accept
user input and to alter graphics context in some way based on this
input. It means that you almost always need to communicate with DOM and
your scripts actually just a bridge between calculations/requests and
user display. By taking MDI-centric approach it is always possible to
represent your model as certain interface elements (form elements,
images, SVG/VML graphics, tables etc.) and certain behaviors you need
to add into it. By using behaviors ("bindings" by Mozilla) you
eliminate all and every problems with incontinence of "this" and lack
of scope modifiers in standard JavaScript. In behaviors your original
code works as an object factory creating a separate instance for each
bound element. This instance is running in its own separate scope
completely independent from the Global scope. The "this" in such
instance and its methods always points to this individual scope (==
current instance scope) and this scope is not accessible from the
Global scope by any means other then public method defined for the
bound element.
All this may lead to an hysteric from a person who learned JavaScript
by the Books of ECMA only :-) But in fact it is very flexible and
convenient. Unfortunately it currently covers FF, IE, NN and Camino
only (currently good enough for me, but may be not good enough for
you).

re: Restricting A Function To Be In Scope of Constructor Method

VK wrote:<snip>What an utterly pointless load of rubbish. As you clearly still don't
understand how the - this - keyword works in javascript it would be a
better idea for you to keep quiet on the subject so you can avoid
making it obvious to everyone else.

Richard.

re: Restricting A Function To Be In Scope of Constructor Method

Richard Cornford wrote:I do understand how does "this" work in JavaScript, but I prefer to
talk about it in terms "what I can do and what I can't" rather than in
terms of "what I can't do and here 1000 words explaining why, and
another 1000 words explaining why it must be this way and 100-500 words
add-on explaining that my current needs should never appear if my
brains would work in a semi-normal way" :-))

We can start a topic like "this keyword in JavaScript" to discuss the
problem. I assure you that will learn a lot of new and interesting (and
I readily accept that the same will apply to me either).

re: Restricting A Function To Be In Scope of Constructor Method

VK wrote:Which does not explain why you have posted 1000 words of incoherent
gibberish.
You would not learn anything, as you have failed to understand any of
the many expiations of the behaviour of the - this - keyword in
javascript that you have seen. I would learn nothing as I already
understand the subject to the extent that it is possible.

Richard.

re: Restricting A Function To Be In Scope of Constructor Method

In article <1157633826.351437.100700@p79g2000cwp.googlegroups .com>, VK
<schools_ring@yahoo.comwrites<snip>

You obviously don't know what the word "bug" means.

John
--
John Harris

re: Restricting A Function To Be In Scope of Constructor Method

John G Harris said the following on 9/7/2006 3:24 PM:VK is lucky to know his name in the mornings.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

re: Restricting A Function To Be In Scope of Constructor Method

John G Harris wrote:<quote>A brief answer:
You can't do it in JavaScript because of a specification bug (because
of well-thought engine mechanics, because of bad implementations of
totally right specifications, because of ... - you really choose the
best from the list or fill your own one: do not start yet another
discussions :-)

Because of this ... phenomenon <snip>
</quote>

Be pedantic, sarcastic, nasty, rude, furious, tricky, shifty, ironic
and many many other things you like (if friendly is not an option). But
please don't be silly.

re: Restricting A Function To Be In Scope of Constructor Method

VK wrote:Uhmm... Just noticed that I grabbed the word for another tune (about
the source dump and functions acting as properties). Should put some
order on my files...

For your case it is the same (using caller property) but much simplier,
no need to override toString method, just put the caller check right
into your function.

Yet you are saying bye-bye to Opera in either case, and if you really
go for it (which is not always an option), then better use behaviors
right away.

re: Restricting A Function To Be In Scope of Constructor Method

VK wrote:<snip>You wrote the words "a specification bug", and you even re-quoted them.
If you knew what a bug was you would not have assembled that sequence of
words (except maybe if insane, which had yet to be ruled out).

Richard.

re: Restricting A Function To Be In Scope of Constructor Method

VK wrote:Why don't you give this up as you have been corrected for miss-applying
access modifier terminology often enough to make it clear that you don't
understand what they mean. Not that that 'sentence' makes any sense.
If this is supposed to be "static" why is it being assigned as a
property of the instance?
And if it is supposed to be "static" why is it being called as a method
of the instance?
Another loose aggregation of words where sentences might be expected.

<snip>LOL

Richard.

re: Restricting A Function To Be In Scope of Constructor Method

Richard Cornford wrote:I don't know.... Wouldn't an inadvertent contradiction constitute a
"specification bug"? (Granted that VK's application of the term is insane.)

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

re: Restricting A Function To Be In Scope of Constructor Method

In article <dS1Mg.126$344.42@newsfe12.lga>, John W. Kennedy
<jwkenne@attglobal.netwritesIt is indeed possible for a design/specification decision to be wrong.
For instance, using two-digit year numbers in a language invented in the
1990s was an act of insanity that can rightly be called a bug.

However, merely disagreeing with a designer's choice does not make it a
bug. This is what VK does not understand.

John
--
John Harris

re: Restricting A Function To Be In Scope of Constructor Method

John W. Kennedy wrote:By taking an iconified look to each and any *written* specification
(rule, regulation, law) it indeed can be only someone's non-compliance
to the written - therefore *ideal* - model. In the programming aspect
it requires to define a bug as "a system (dis)behavior non-conforming
to the provided specifications for the given system". With such
definition the term "specification bug" indeed doesn't have any sense.

The question is: is it possible for a system to contain an obvious bug
yet do not have a "bug" as it was defined above? I will use again the
"street lights" sample - it comes from the very first programming books
illustrating the idea of right and wrong algorithms.

Let's imagine that the company A Specs, Inc. produced a regulation for
crossing the street by pedestrians:
"When seeing the red light, stop; when seeing the green light - go".
Let's imagine now that the company B Soft, Inc. has to write a program
for some experimental robot-pedestrian using the A Specs, Inc.
regulation (it becomes a block-schema for the program in such case). In
JavaScript that could be:

function mover(lightSeen) {
if (lightSeen == constGreen) {
walkAcross();
}
else if (lightSeen == constRed) {
stayStill();
}
else {
undefinedSitiationHandler();
}
}

Does this program contain a bug as it was defined at the beginning? No
it doesn't - it strictly follows the document from A Specs, Inc. Yet it
does contain a bug you'll discover as soon as you move your robot on
the street. On the first red light it will stop and it will stay until
your restart it. The algorithm is wrong: it doesn't define what to do
after stopped on the red light. A functional subroutine must be
something like:

function mover(lightSeen) {
if (lightSeen == constGreen) {
walkAcross();
}
else if (lightSeen == constRed) {
stayStill();
}
else {
undefinedSitiationHandler();
}
setTimeout('visualPerceiver()',1000);
}

with the perceiver called every second and the result sent to mover().
We had to extend our program beyond the specs. We've got a
*specification bug* we had to compensate in our program.

At the same time as another option B Soft, Inc. may program the robot
exactly as it is said, put all claims on A Specs, Inc. and wait for
better specs to arrive. If new specs are too long to arrive and do not
loose customers, B Soft, Inc. may attach to the robot a timer to reset
the system if it stays on the same place longer than say 20 sec. It is
not a violation/extension of existing specs, as they do not define when
and why would we need to reset the robot. If updated specs never
arrive, there will be generations of robots with the "timer fix". New
engineers coming to B Soft, Inc. will take this as granted.

"it stops and doesn't move - it's OK!
We have a reset timer"

"<thisrefuses to point to what we need - it's OK!
this.self / var self = this solves the problem"

Coming back to our moutons :-)
I see the incontinence of <thisas a bug. At the same time - and I'm
sure that Mr.Cornford will gladly prove it once over again - it doesn't
contradict any of the current ECMAScript engine specifications.
Expression is expressing, production chain is producting, blah-blah,
blah... everything tip-top. :-)

Therefore for me it's a specification bug ("specification error" by
Douglas Crockford) and I call it this way, whether one likes it or not.
Respectively I define a bug more widely as "a fault or defect in a
system or machine". In comparison to the discussed definition given at
the beginning of this post it doesn't fixate on "by specs or against of
them".

re: Restricting A Function To Be In Scope of Constructor Method

VK wrote:Isn't a document that contains a contradiction inevitably non-specific,
and so not a specification in any sense but being named such?
That would be an insane specification; as it tales time to cross a road
and the lights can change almost instantaneously stopping would be a
very unwise response to seeing a red light at any point between
commencing to cross a road and completing the process.
<snip>We have a poor specification.
No, we reject the specification and return it to its author(s) for
correction. Possibly suggesting that "do not commence crossing a road
when a red light can be seen" as a safer and clearer alternative in this
context.

<snip>The - this - keyword - always refers to what it is specified as
referring to. It is neither unexpected nor undesirable that whatever it
does refer to will be non-relevant in some code, and that other means
will be needed to make references that re relevant.
If a specific object cannot be accessed through the - this - keyword
then accessing it through the scope chain is a completely reasonable
alternative.
And still, despite repeated requests, you refuse to explain what
"incontinence" is supposed to mean. The - this - keyword is completely
constant and predictable in its behaviour.
More likely I would point out that all implementations follow the
specification so any programmer considering using - this - can know with
certainty exactly what will be referred to be - this - in their own
code. This is a situation that allows programming using javascript.
Gibberish.
Because you cannot cope with reality, but that is mostly a consequence
of your not understanding javascript even to the extent of not knowing
what the code you write is supposed to do.
Believing that specifying alternative behaviour for the - this - keyword
may have been preferable is reasonable.
Yes, you have never let being told that the statements you make are
false, nonsense, incoherent, incomprehensible, etc, etc, influence your
decision to make them.
So a faulty memory chip is a "bug"?
The more you write the more I see why you are the worst programmer I
have ever encountered, and the more I suspect that insanity is the only
possible explanation.

Richard.

re: Restricting A Function To Be In Scope of Constructor Method

In article <1157816400.428974.176710@b28g2000cwb.googlegroups .com>, VK
<schools_ring@yahoo.comwrites

<snip><snip>

Could you say, clearly and in not many words and with no irrelevant
examples, what this incontinence is.

John
--
John Harris

re: Restricting A Function To Be In Scope of Constructor Method

John G Harris wrote:The evidence suggests that he cannot.


Richard.

re: Restricting A Function To Be In Scope of Constructor Method

John G Harris wrote:That really was discussed N times in this newsgroup, and I believe that
you were participant of at least few of the relevant thread. But maybe
my progressing insanity (so properly diagnosed by Ph.D. Cornford :-)
affecting my memory either.

In the requested minimum of words:
"incontinence of <this>" refers to a set of situations when - due to
ECMAScript engine specification bugs - <thispoints to the expected
object at the moment of initialization/assignment but does point or may
point to a unexpected object a step later.

<http://www.crockford.com/javascript/private.htmlwill get you on hold
of the most known one. After you are done and if willing to continue
we'll move on ontimer calls.

re: Restricting A Function To Be In Scope of Constructor Method

VK wrote:The question ahs certainly been asked many times, but you never manage
to answer it.

<snip>In a language that determines the value for - this - always, and only,
by how a function is called the - this - value should be expected to
differ depending on how a function is called, and so not necessarily be
the same at the point where a function is defined (and/or assigned) and
the point where it is called. Indeed the - this - value could not even
be assumed to be the same if the same function is called in two
different ways.

It may also be worth mentioning that as - this - in the global
execution context refers to the global object the implication of your
desire that - this - refer to the same value when a function is called
as when it is initialised/assigned is that in constrictors defined in
the global scope, and methods assigned to their prototypes in the
global scope (as they normally are), and as all inner functions must
then be declared/evaluated inside these global functions, is that -
this - would always refer to the global object inside all constructors,
methods and functions. Effectively making the - this - value worthless.

But once again all you are saying here is that because you do not
understand how the - this - value works you are incapable of expecting
it to refer to the values it does refer to, and in not being abler to
expect what you get you see what you get as in some sense
"incontinence", rather then the consistent product of predictable
mechanical logic that it actually is.

The - this - keyword always points to the 'expected' object, you just
need to understand the mechanism before you can have the correct
expectation. That may be beyond you personally, but that has no
implications for the language (or anyone else's ability to understand
it).
You mean the things where string arguments are evaluated in the global
scope and function reference arguments are called as values, giving
completely predictable values for - this - in those contexts?

Richard.

re: Restricting A Function To Be In Scope of Constructor Method

Richard Cornford wrote:Richard, it is a mute point, we tried it before. To even discuss "what
is wrong" it is needed first to agree that there is something wrong
around. In application to an ECMAScript-compliant behavior in order to
agree that something is wrong around it is necessary first to accept
that something can ever be wrong with official specifications.
This is why some agreement on the bug definition was a necessary lemma
to move on ("lemma" in the sense that it is not practically so
important, but it allows to prove other practical things later).

Your definition of a "bug" and "official specification" simply exclude
any existence possibility of problems like the one with <this>. That is
going to be another chain of my samples and your detailed explanations
why it is fully conforming to the existing specs (which is the point I
am not arguing with).

re: Restricting A Function To Be In Scope of Constructor Method

VK wrote:There is something wrong around; your expectations differ from reality
("may point to a unexpected object").
On the contrary, not corresponding with the specification is virtually
the only criteria that could be applied if trying to declare that
something is wrong with "ECMAScript-compliant behaviour".
Gibberish.
Your "problems like the one with <this>" have existence, but it is an
existence limited to the inside of your head. Everyone else can lean to
have expectations about the - this - value that correspond with reality.
For you your misconceptions is more significant than reality and so for
you the - this - value will often be unexpected. Neither the
specification nor the implementations are at fault in that.
Gibbering incoherently is a symptom of mental illness.

Richard.

re: Restricting A Function To Be In Scope of Constructor Method

In article <1157835079.875710.266290@h48g2000cwc.googlegroups .com>,
Richard Cornford <Richard@litotes.demon.co.ukwrites<snip>

Good heavens! So that's what he's trying to say. Well, well!

Does he object to ordinary function calls, such as a.b.c(), or to new
expressions, such as new Thing() ?

John
--
John Harris

re: Restricting A Function To Be In Scope of Constructor Method

John G Harris wrote:<snip>It is unlikely that VK has any sort of expressible concept of what he
objects to. The vague suggestion that - this - should always refer to
the same object inside a function call as it refers to when the function
is created ends up with - this - always referring to the global object,
which hardly expands its usefulness. Probably his mind doesn't go beyond
"I want it to be exactly how I think it should be at any pint I wish to
use it, and everything else is wrong".

A proposal sufficiently logically consistent that it could even be
implemented is about the last thing that would be expected of VK.

Richard.