Named arguments and inheritance

[Pacific Fox]

Hi all,

haven't posted to this group before, but got an issue I can't work
out... and hoping to get some help here ;-)

I've got a base object that works fine with named arguments when called
on it's own. However when I call the child object I get an error
"[associative array name] has no properties (in firefox)."

I simple test:

Property = function( arg ) {
/**
* Private properties
*/
var name = arg.name; // required, the name of the field

/**
* Priviliged methods, may be invoked publicly and may access private
variables
*/
this.getName = function() {
return name;
}
};

/**
* Class for form field properties, extends property
*/
FormProperty = function( arg ) {
/**
* Inheritance
*/
this.super = Property;
this.super( { name:arg.name } );
this.prototype = new Property;
}
//property = new FormProperty( { name:"myVar" } )
property = new Property( { name:"test" } )
alert( property.getName() );

Un comment //property = new FormProperty( { name:"myVar" } )
to get the error.

Thanks in advance for any help.

[David Golightly]

Pacific Fox wrote:

Hi all,

haven't posted to this group before, but got an issue I can't work
out... and hoping to get some help here ;-)

I've got a base object that works fine with named arguments when called
on it's own. However when I call the child object I get an error
"[associative array name] has no properties (in firefox)."

I simple test:

Property = function( arg ) {
/**
* Private properties
*/
var name = arg.name; // required, the name of the field

/**
* Priviliged methods, may be invoked publicly and may access private
variables
*/
this.getName = function() {
return name;
}
};

/**
* Class for form field properties, extends property
*/
FormProperty = function( arg ) {
/**
* Inheritance
*/
this.super = Property;
this.super( { name:arg.name } );
this.prototype = new Property;
}
//property = new FormProperty( { name:"myVar" } )
property = new Property( { name:"test" } )
alert( property.getName() );

Un comment //property = new FormProperty( { name:"myVar" } )
to get the error.

Thanks in advance for any help.

Your problem is that your base class depends on always getting a valid
object for its argument, and you're not providing it one when you
subclass within the FormProperty constructor. You can't use this
technique to subclass if your base constructor makes assumptions about
always getting valid arguments, because your arguments might not be
available at creation time.

Try this instead:

Property = function() {
// use the arguments collection, an Array-like builtin that
contains the arguments passed into a function
if (arguments[0])
var name = arguments[0].name; // required, the name of the
field
// otherwise, we're subclassing and can skip this

this.getName = function() {
return name;
}
};

FormProperty = function( arg ) {
// use function.apply - it calls function Property using the first
parameter as "this"
// See also
http://developer.mozilla.org/en/docs...Function:apply
Property.apply(this, [arg]);
}
FormProperty.prototype = new Property;
property = new FormProperty( { name:"myVar" } )
alert( property.getName() );

[Pacific Fox]

Correct me if I am wrong, but doesn't that defeat the whole purpose of
named arguments?
David Golightly wrote:

Pacific Fox wrote:

Hi all,

haven't posted to this group before, but got an issue I can't work
out... and hoping to get some help here ;-)

I've got a base object that works fine with named arguments when called
on it's own. However when I call the child object I get an error
"[associative array name] has no properties (in firefox)."

I simple test:

Property = function( arg ) {
/**
* Private properties
*/
var name = arg.name; // required, the name of the field

/**
* Priviliged methods, may be invoked publicly and may access private
variables
*/
this.getName = function() {
return name;
}
};

/**
* Class for form field properties, extends property
*/
FormProperty = function( arg ) {
/**
* Inheritance
*/
this.super = Property;
this.super( { name:arg.name } );
this.prototype = new Property;
}
//property = new FormProperty( { name:"myVar" } )
property = new Property( { name:"test" } )
alert( property.getName() );

Un comment //property = new FormProperty( { name:"myVar" } )
to get the error.

Thanks in advance for any help.

Your problem is that your base class depends on always getting a valid
object for its argument, and you're not providing it one when you
subclass within the FormProperty constructor. You can't use this
technique to subclass if your base constructor makes assumptions about
always getting valid arguments, because your arguments might not be
available at creation time.

Try this instead:

Property = function() {
// use the arguments collection, an Array-like builtin that
contains the arguments passed into a function
if (arguments[0])
var name = arguments[0].name; // required, the name of the
field
// otherwise, we're subclassing and can skip this

this.getName = function() {
return name;
}
};

FormProperty = function( arg ) {
// use function.apply - it calls function Property using the first
parameter as "this"
// See also
http://developer.mozilla.org/en/docs...Function:apply
Property.apply(this, [arg]);
}
FormProperty.prototype = new Property;
property = new FormProperty( { name:"myVar" } )
alert( property.getName() );

[Pacific Fox]

OK, it seems to work, but I don't see how it works as the constructor
for Property does not have any arguments, i'm a bit puzzled...

property = new Property( { name:"myVar" } );

Pacific Fox wrote:

Correct me if I am wrong, but doesn't that defeat the whole purpose of
named arguments?
David Golightly wrote:

Pacific Fox wrote:

Hi all,
>
haven't posted to this group before, but got an issue I can't work
out... and hoping to get some help here ;-)
>
I've got a base object that works fine with named arguments when called
on it's own. However when I call the child object I get an error
"[associative array name] has no properties (in firefox)."
>
I simple test:
>
Property = function( arg ) {
/**
* Private properties
*/
var name = arg.name; // required, the name of the field
>
/**
* Priviliged methods, may be invoked publicly and may access private
variables
*/
this.getName = function() {
return name;
}
};
>
/**
* Class for form field properties, extends property
*/
FormProperty = function( arg ) {
/**
* Inheritance
*/
this.super = Property;
this.super( { name:arg.name } );
this.prototype = new Property;
}
//property = new FormProperty( { name:"myVar" } )
property = new Property( { name:"test" } )
alert( property.getName() );
>
Un comment //property = new FormProperty( { name:"myVar" } )
to get the error.
>
Thanks in advance for any help.

Your problem is that your base class depends on always getting a valid
object for its argument, and you're not providing it one when you
subclass within the FormProperty constructor. You can't use this
technique to subclass if your base constructor makes assumptions about
always getting valid arguments, because your arguments might not be
available at creation time.

Try this instead:

Property = function() {
// use the arguments collection, an Array-like builtin that
contains the arguments passed into a function
if (arguments[0])
var name = arguments[0].name; // required, the name of the
field
// otherwise, we're subclassing and can skip this

this.getName = function() {
return name;
}
};

FormProperty = function( arg ) {
// use function.apply - it calls function Property using the first
parameter as "this"
// See also
http://developer.mozilla.org/en/docs...Function:apply
Property.apply(this, [arg]);
}
FormProperty.prototype = new Property;
property = new FormProperty( { name:"myVar" } )
alert( property.getName() );

[Richard Cornford]

Pacific Fox wrote:

Correct me if I am wrong, but doesn't that defeat the whole purpose of
named arguments?

Javascript does not have named arguments at all. What you are doing is
creating a new object for each function call using an object
literal/initaliser, and assigning values to the named properties of
that object, so the object becomes the single argument to the function
call. This introduces a runtime overhead and results in the creation of
many more objects that are necessary, which, given how low priority
browser garbage collection is, will slow down, for example, IE
considerably.

Richard.

[Richard Cornford]

Pacific Fox wrote:

Hi all,

haven't posted to this group before, but got an issue I can't work
out... and hoping to get some help here ;-)

I've got a base object that works fine with named arguments

Javascript does not have named arguments at all.

when called
on it's own. However when I call the child object I get an error
"[associative array name] has no properties (in firefox)."

That is _absolutely_not_ the error you received (as javascript has no
'associative arrays'). If you want people to help you debug your code
it is a much better idea to post the errors that the code actually
generates (as we all have lots of experience interpreting real error
messages, and very little interest in fictional ones).

I simple test:

Property = function( arg ) {

Why not just use a named Function Declaration instead of this
assignment of the value of a Function Expression? Generaly it is
considered bad practice to be creating properties of the global object
at runtime rather than using pre-declared global variables.

/**
* Private properties
*/
var name = arg.name; // required, the name of the field

/**
* Priviliged methods, may be invoked publicly and may access private
variables
*/
this.getName = function() {
return name;
}
};

/**
* Class for form field properties, extends property
*/
FormProperty = function( arg ) {
/**
* Inheritance
*/
this.super = Property;

The word "super" is a FutureReservedWord in javascript, so it cannot be
used as an Identifier, and so cannot appear in a dot notation property
accessor. Some browsers may put up with this, but it is still
officially a syntax error and will be treated as a syntax error in at
least some environments.

this.super( { name:arg.name } );

Why do this? Why create a new object with a - name - property and give
it the value of the name property of the object passed in as an
argument to the function call when you can just pass the argument
object on to at this point?

this.prototype = new Property;

This is:-

1. The cause of your error, as no argument is being sent to the
Property constructor but it is treating its argument as if it was an
object.

2. Pointless, as the call to this.super (where it has not resulted in a
syntax error) will have added the - getName - method so masked the only
public member of any Property instance created for the prototype.

3. Stupid, because it is certainly not doing what it appears to be
intended to do. When an object is constructed the assignment of the
value of the constructor's prototype property to the new object's
internal [[Prototoype]] property happens before the execution of the
constructor's body code. Thus the first instantiation of an object with
FormProperty will use the default - FormProperty.prototype - value as
its [[Prototype]], the second instance will use the Property object
created during the first instantiation, the third the Property object
created during the second instantiation, and so on. If the prototype
chain had any significance in the defining of any of these objects the
fact that they would all have a different prototype, and particularly
the fact that the first object's prototype was not an instance of the
expected object, would destroy the likeness that is expected when
implementing the 'class' concept in javascript.

4. Doubly stupid because the point of prototype inheritance it to have
may object instances sharing the same prototype, and so sharing single
function objects for its methods (where that is acceptable) and single
default values for its properties. creating a second object with each
object constructed is wasteful.

}
//property = new FormProperty( { name:"myVar" } )
property = new Property( { name:"test" } )
alert( property.getName() );

Un comment //property = new FormProperty( { name:"myVar" } )
to get the error.

Thanks in advance for any help.

Where ever you are learning to write javascript like this is not a good
source of information on the subject.

Richard.

[Richard Cornford]

David Golightly wrote:
<snip>

Your problem is that your base class depends on always getting a
valid object for its argument, and you're not providing it one when you
subclass within the FormProperty constructor. ...

<snip>

Try this instead:

Property = function() {
// use the arguments collection, an Array-like builtin that
contains the arguments passed into a function
if (arguments[0])
var name = arguments[0].name; // required, the name of the
field
// otherwise, we're subclassing and can skip this

this.getName = function() {
return name;
}
};

Wouldn't it be considerably simpler just to ensure that the calls to
the Property constructor were provided with appropriate arguments?
After all the only time it is being called without them is when
assigned to a prototype, so a dummy - name - would be harmless as it
would be masked on real instances.

FormProperty = function( arg ) {
// use function.apply - it calls function Property using the first
parameter as "this"
// See also
http://developer.mozilla.org/en/docs...Function:apply
Property.apply(this, [arg]);

With a single argument (indeed with a known list of arguments. as must
be the case here) the - call - method is more appropriate, and avoids
the overhead of creating an Array object to pass on those arguments.

However, the use of either sacrifices computability with some of the
older of the browsers currently in use. Neither methods were introduced
in JScript prior to IE 6. The technique used in the OP's code achieves
as much as any use of apply/call does (syntax error not withstanding),
leaves the object instances flagged with information about their
'superclass' and is computable with all current browsers.

Richard.

[Pacific Fox]

Thanks, I realize they are not really named arguments (as javascript
does not support that), but I figured anyone else would understand that
as well. I really didn't want to go into a long story about that.

Whatever you want to call it, however you want to see it, it allows to
me to call functions without having to specify every parameter, i.e.
someMethod( "some value", null, null, null, null, null, null, null,
null, null, "and another value" )

If this was on the server side I might have agreed with you, but since
its on the client side I am not going to worry about these few extra
objects. I wish I just got an answer to the problem, instead of going
into whats right and wrong, and best practise and "make myself feel
gooders" ;-)
Richard Cornford wrote:

Pacific Fox wrote:

Correct me if I am wrong, but doesn't that defeat the whole purpose of
named arguments?

Javascript does not have named arguments at all. What you are doing is
creating a new object for each function call using an object
literal/initaliser, and assigning values to the named properties of
that object, so the object becomes the single argument to the function
call. This introduces a runtime overhead and results in the creation of
many more objects that are necessary, which, given how low priority
browser garbage collection is, will slow down, for example, IE
considerably.

Richard.

[Pacific Fox]

Javascript does not have named arguments at all.

http://www.google.com.au/search?hl=e...ve+array&meta=
378,000 results must be wrong to

That is _absolutely_not_ the error you received (as javascript has no
'associative arrays'). If you want people to help you debug your code
it is a much better idea to post the errors that the code actually
generates (as we all have lots of experience interpreting real error
messages, and very little interest in fictional ones).

I included the code below so that individual tests could be run, I even
made the code smaller so that only the relevant items where there,
instead of the 200 lines of code the classes really are.

Why not just use a named Function Declaration instead of this
assignment of the value of a Function Expression? Generaly it is
considered bad practice to be creating properties of the global object
at runtime rather than using pre-declared global variables.

I'm not quite sure I understand. do you mean;

function = argument() {
this.variable = "some value"
}

and pass that to the method call?

The word "super" is a FutureReservedWord in javascript, so it cannot be
used as an Identifier, and so cannot appear in a dot notation property
accessor. Some browsers may put up with this, but it is still
officially a syntax error and will be treated as a syntax error in at
least some environments.

this.super( { name:arg.name } );

Cool, I'll call it superClass from here on.

Why do this? Why create a new object with a - name - property and give
it the value of the name property of the object passed in as an
argument to the function call when you can just pass the argument
object on to at this point?

It was a demonstration to allow anyone interested to see the error...

1. The cause of your error, as no argument is being sent to the
Property constructor but it is treating its argument as if it was an
object.

Here it all starts to make sense, this is what I was after, the object
is created without the arguments. Yes, thanks... Now how to overcome
this.

2. Pointless, as the call to this.super (where it has not resulted in a
syntax error) will have added the - getName - method so masked the only
public member of any Property instance created for the prototype.

I don't understand.

3. Stupid, because it is certainly not doing what it appears to be
intended to do. When an object is constructed the assignment of the
value of the constructor's prototype property to the new object's
internal [[Prototoype]] property happens before the execution of the
constructor's body code. Thus the first instantiation of an object with
FormProperty will use the default - FormProperty.prototype - value as
its [[Prototype]], the second instance will use the Property object
created during the first instantiation, the third the Property object
created during the second instantiation, and so on. If the prototype
chain had any significance in the defining of any of these objects the
fact that they would all have a different prototype, and particularly
the fact that the first object's prototype was not an instance of the
expected object, would destroy the likeness that is expected when
implementing the 'class' concept in javascript.

4. Doubly stupid because the point of prototype inheritance it to have
may object instances sharing the same prototype, and so sharing single
function objects for its methods (where that is acceptable) and single
default values for its properties. creating a second object with each
object constructed is wasteful.

Where ever you are learning to write javascript like this is not a good
source of information on the subject.

I got the code from
http://developer.mozilla.org/en/docs..._the_Hierarchy
which I would think is a reliable source....

But would love to see your solution to this, allowing the base class to
be extended...

[David Golightly]

Well, you're dealing with basically two things here:

1. You want to use named arguments.

2. You want your arguments to be passed to the base constructor. For
this it doesn't matter what your arguments are or whether they're named
or not. Your named arguments are really just another object literal, a
neat hack, but nothing unusual.

I don't really see what you're missing in my solution above. If you're
targeting a browser that doesn't have Function.apply built in, this
provides it for you:
http://www.openjsan.org/doc/a/ad/ada...ion/apply.html

If you still don't want to use Function.apply, all you've got to do is:

change the line reading
var name = arg.name; // required, the name of the field
to
if (arg) var name = arg.name; // required, the name of the
field

The point is, you're getting an error thrown because your base
constructor assumes that it's always getting arguments. Relax that
assumption, and you're fine.

[Richard Cornford]

Pacific Fox wrote:

Thanks, I realize they are not really named arguments (as javascript
does not support that), but I figured anyone else would understand that
as well.

Not a good assumption. Attaching inappropriate terminology to
javascript directly leads to many misconceptions and disappointed
expectations for people who are just learning the language (like you
are). "Named arguments" implies that the mechanics are handled
internally and efficiently by the implementation, that is a long way
from the case. While calling what you are doing what it is; creating a
new object instance as a vehicle for passing argument with each
function call, gives the reader a better understanding of what is going
on, and the implications of doing it.

I really didn't want to go into a long story about that.

Whatever you want to call it, however you want to see it, it allows to
me to call functions without having to specify every parameter,

You don't have to specify every parameter is javascript. You just have
to specify every parameter up to and including the last one that must
be included.

i.e.
someMethod( "some value", null, null, null, null, null, null, null,
null, null, "and another value" )

Think about that for a moment. The vast bulk of functions have 3 or
fewer parameters, and the vast bulk of function calls must provide an
argument for each parameter. Designing functions to take optional
arguments is very much the exception, and even when it is done the
designer gets to judge the likelihood of any particular parameter being
omitted and so arrange their parameters such that the right most is the
one most likely to be omitted in practice, the one to its left if next
most likely to be omitted and so on.

Thus you proposed example, with 10 optional arguments and the one being
provided being the one least likely to be provided really is a very
exceptional case. And in such a very exceptional case a little extra
writing to provide values for the otherwise unused arguments does not
seem that arduous.

But rather than that you would address this really exceptional case by
imposing the runtime overhead of creating a new object for each and
every function call. That is disproportionate to the point of being
stupid.

If this was on the server side I might have agreed with you, but since
its on the client side I am not going to worry about these few extra
objects.

Those "few extra objects" are going to add up. Its one new object per
function/method/constructor call, and the more complex your code
becomes the more function/method/constructor calls you will make.

I wish I just got an answer to the problem, instead of going
into whats right and wrong, and best practise and "make myself feel
gooders" ;-)

<snip>

If you are satisfied to write code that barely works.

Richard.

[Richard Cornford]

Pacific Fox wrote:

>Javascript does not have named arguments at all.

http://www.google.com.au/search?hl=e...ve+array&meta=
378,000 results must be wrong to

And the relationship between "named arguments" and 'associative arrays'
is?

But yes, there are no associative arrays in javascript no matter how
widely the story is put about that there are. You can tell that there
are no associative arrays in javascript by proposing a formal
definition of what an associative array is that excludes things that
are definitely not associative arrays (such as the Java Vector class).
You will find that any such definition also excludes the javascript
object.

>That is _absolutely_not_ the error you received (as javascript
has no 'associative arrays'). If you want people to help you
debug your code it is a much better idea to post the errors
that the code actually generates (as we all have lots of experience
interpreting real error messages, and very little interest in fictional
ones).

I included the code below so that individual tests could be run, I even
made the code smaller so that only the relevant items where there,
instead of the 200 lines of code the classes really are.

You still gave a false report of the error message.

>Why not just use a named Function Declaration instead of this
assignment of the value of a Function Expression? Generaly it is
considered bad practice to be creating properties of the global object
at runtime rather than using pre-declared global variables.

I'm not quite sure I understand. do you mean;

function = argument() {
this.variable = "some value"
}

No, that would be a syntax error. I meant a FunctionDeclaration, which
is why I said that.

and pass that to the method call?

Doing what?

<snip>

>Why do this? Why create a new object with a - name - property
and give it the value of the name property of the object passed
in as an argument to the function call when you can just pass
the argument object on to at this point?

It was a demonstration to allow anyone interested to see the error...

Not needlessly creating an extra object at that point would not have
changes the error.

>1. The cause of your error, as no argument is being sent to the
Property constructor but it is treating its argument as if it was an
object.

Here it all starts to make sense, this is what I was after, the object
is created without the arguments. Yes, thanks... Now how to overcome
this.

You overcome it by stopping doing it.

>2. Pointless, as the call to this.super (where it has not resulted in a
syntax error) will have added the - getName - method so masked the only
public member of any Property instance created for the prototype.

I don't understand.

Every property that could be inherited from the prototype was assigned
in the 'superclasses' constructor, so the object would have the
properties directly assigned to it, and so the corresponding properties
of the objects on the prototype chain would not be being used (so need
not be there).

>3. Stupid, because it is certainly not doing what it appears to be
intended to do. When an object is constructed the assignment of the
value of the constructor's prototype property to the new object's
internal [[Prototoype]] property happens before the execution of the
constructor's body code. Thus the first instantiation of an object with
FormProperty will use the default - FormProperty.prototype - value as
its [[Prototype]], the second instance will use the Property object
created during the first instantiation, the third the Property object
created during the second instantiation, and so on. If the prototype
chain had any significance in the defining of any of these objects the
fact that they would all have a different prototype, and particularly
the fact that the first object's prototype was not an instance of the
expected object, would destroy the likeness that is expected when
implementing the 'class' concept in javascript.

4. Doubly stupid because the point of prototype inheritance it to have
may object instances sharing the same prototype, and so sharing single
function objects for its methods (where that is acceptable) and single
default values for its properties. creating a second object with each
object constructed is wasteful.

Where ever you are learning to write javascript like this is not a good
source of information on the subject.

I got the code from
http://developer.mozilla.org/en/docs..._the_Hierarchy

Oh no you didn't. You may have got a confused notion of one way in
which javascript can parallel class hierarchies in Java but what
appears on that page in no way suggests the code your wrote. There are,
for example, no instances of a constructor's - prototype - property
being set from inside a constructor.

which I would think is a reliable source....

I would not be that optimistic, but if you don't understand what you
are reading there its relative reliability becomes moot.

But would love to see your solution to this, allowing the base class to
be extended...

But if I posted you code wouldn't I risk doing it to make myself feel
good?

Richard.

[VK]

Pacific Fox wrote:

I've got a base object that works fine with named arguments when called
on it's own. However when I call the child object I get an error
"[associative array name] has no properties (in firefox)."

I simple test:

Property = function( arg ) {
/**
* Private properties
*/
var name = arg.name; // required, the name of the field

/**
* Priviliged methods, may be invoked publicly and may access private
variables
*/
this.getName = function() {
return name;
}
};

/**
* Class for form field properties, extends property
*/
FormProperty = function( arg ) {
/**
* Inheritance
*/
this.super = Property;
this.super( { name:arg.name } );
this.prototype = new Property;
}
//property = new FormProperty( { name:"myVar" } )
property = new Property( { name:"test" } )
alert( property.getName() );

Un comment //property = new FormProperty( { name:"myVar" } )
to get the error.

Thanks in advance for any help.

You problem is that you mixing two types of constructors: object
constructor (the most regular one) and constructor constructor
(factory). In your code Property is a constructor factory returning new
constructor instance - while you are trying to use it as a regular
object constructor.

<html>
<head>
<title>Checkboxes</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

<script type="text/javascript">

function Property() {
return (
function(arg) {
var name = arg.name;
this.getName = function() {
return name;
}
});
}

function FormProperty(arg) {
this.privProperty = new Property;
this.privProperty( { name:arg.name } );
}

property = new FormProperty( { name:"myVar" } )
alert( property.getName() );
</script>

</head>

<body>
</body>
</html>

[Richard Cornford]

VK wrote:

Pacific Fox wrote:

>I've got a base object that works fine with named arguments when called
on it's own. However when I call the child object I get an error
"[associative array name] has no properties (in firefox)."

I simple test:

Property = function( arg ) {
/**
* Private properties
*/
var name = arg.name; // required, the name of the field

/**
* Priviliged methods, may be invoked publicly and may access
private variables
*/
this.getName = function() {
return name;
}
};

/**
* Class for form field properties, extends property
*/
FormProperty = function( arg ) {
/**
* Inheritance
*/
this.super = Property;
this.super( { name:arg.name } );
this.prototype = new Property;
}
//property = new FormProperty( { name:"myVar" } )
property = new Property( { name:"test" } )
alert( property.getName() );

Un comment //property = new FormProperty( { name:"myVar" } )
to get the error.

Thanks in advance for any help.

You problem is that you mixing two types of constructors: object
constructor (the most regular one) and constructor constructor
(factory). In your code Property is a constructor factory returning new
constructor instance - while you are trying to use it as a regular
object constructor.

You really do talk a lot of nonsense.

<snip>

function Property() {
return (
function(arg) {
var name = arg.name;
this.getName = function() {
return name;
}
});
}

function FormProperty(arg) {
this.privProperty = new Property;
this.privProperty( { name:arg.name } );
}

<snip>

The issue of 'subclassing' is inherent in the question; this rubbish is
not only insanely designed but has also removed the Property 'class'
(and any notion of 'subclassing') entirely.

Richard.

[VK]

You problem is that you mixing two types of constructors: object

constructor (the most regular one) and constructor constructor
(factory). In your code Property is a constructor factory returning new
constructor instance - while you are trying to use it as a regular
object constructor.

You really do talk a lot of nonsense.

About the difference between
1) constructor returning new object instances of some kind
2) constructor returning constructor to produce new object instances of
some kind
?

That is not a "nonsense" but an important distinction.
"A returns new instances of O; B returns new instance of A able to
return new instances of O".
In your opinion A and B do the same job?

<snip>

function Property() {
return (
function(arg) {
var name = arg.name;
this.getName = function() {
return name;
}
});
}

function FormProperty(arg) {
this.privProperty = new Property;
this.privProperty( { name:arg.name } );
}

<snip>

The issue of 'subclassing' is inherent in the question; this rubbish is
not only insanely designed but has also removed the Property 'class'
(and any notion of 'subclassing') entirely.

It seems that you did not understand what does the code do.

[Richard Cornford]

VK wrote:

>>You problem is that you mixing two types of constructors: object
constructor (the most regular one) and constructor constructor
(factory). In your code Property is a constructor factory returning new
constructor instance - while you are trying to use it as a regular
object constructor.

You really do talk a lot of nonsense.

About the difference between
1) constructor returning new object instances of some kind
2) constructor returning constructor to produce new object instances of
some kind
?

There should be no "constructor" returning a constructor. If a function
is to return a function (even if it is to be used as a constructor
(which yours is not)) then it should not be called using the - new -
operator, and should not be thought of, or spoken of, as a constructor.

That is not a "nonsense" but an important distinction.

It is nonsense as soon as you start talking of "constructor returning
constructor", and such talk may lead people to the even greater folly
of applying the - new - operator to functions that are not being used
to create object instances.

"A returns new instances of O; B returns new instance of A able to
return new instances of O".
In your opinion A and B do the same job?

They are not both constructors.

><snip>

>>function Property() {
return (
function(arg) {
var name = arg.name;
this.getName = function() {
return name;
}
});
}

function FormProperty(arg) {
this.privProperty = new Property;
this.privProperty( { name:arg.name } );
}

<snip>

>The issue of 'subclassing' is inherent in the question; this rubbish is
not only insanely designed but has also removed the Property 'class'
(and any notion of 'subclassing') entirely.

It seems that you did not understand what does the code do.

Does it? Why do you think that then? Are you saying that your code does
contain something that represents a means of creating Property
instances? are you saying there is some reason for using the - new -
operator with your - Property - function? Or that there is some point
in having a reference to a function as - privProperty?

If all is wanted is an ability to augment an object with a closure to
store a name and a method for retreating it wouldn't:-

function addNameInterface(name, obj){
obj.getName = function(){
return name;
};
}
function FormProperty(arg) {
addNameInterface(arg.name, this);
}

- get there quicker, cleaner, more directly and in a lot less code?

Richard.

[VK]

There should be no "constructor" returning a constructor. If a function

is to return a function (even if it is to be used as a constructor
(which yours is not)) then it should not be called using the - new -
operator, and should not be thought of, or spoken of, as a constructor.

Really? Says who? JavaScript function can be used as a simple function
or as a constructor. That is it exactly can be defined at the moment
of the call *only*. The very same function can be used in both ways. If
it's called with "new" keyword then it acts as constructor, otherwise
as a simple function. By just adding
this.property = something;
into function body you don't tranform it in some magic way into
constructor.

"A returns new instances of O; B returns new instance of A able to
return new instances of O".
In your opinion A and B do the same job?

They are not both constructors.

They are: but they are constructing different things.

If all is wanted is an ability to augment an object with a closure to
store a name and a method for retreating it wouldn't:-

function addNameInterface(name, obj){
obj.getName = function(){
return name;
};
}
function FormProperty(arg) {
addNameInterface(arg.name, this);
}

- get there quicker, cleaner, more directly and in a lot less code?

Mostly because it's not what OP was after :-) If I'm mistaken OP will
correct me.

[Richard Cornford]

VK wrote:

>There should be no "constructor" returning a constructor. If a function
is to return a function (even if it is to be used as a constructor
(which yours is not)) then it should not be called using the - new -
operator, and should not be thought of, or spoken of, as a constructor.

Really? Says who? JavaScript function can be used as a simple function
or as a constructor.

But there is no point in calling a function as a constructor (with the
- new - operator) if it returns any object other than the value of the
- this - keyword. Doing so just results in the creation of a
superfluous object and then the throwing away of that object. There is
no need for any other reason for never calling a function that returns
any object other than - this - a constructor, or as a constructor. All
the active effects of doing so would be achieved by just calling it as
a function, and the useless side effects (and associated overheads) are
then avoided, along with the conceptual misdirection following from the
inappropriate use of the - new - operator.

That is it exactly can be defined at the moment
of the call *only*.

And in English?

The very same function can be used in both ways.

Not very effectively, and designing with such an intent would be
perverse.

If it's called with "new" keyword then it acts as constructor,

An object is created as a result, but if that object is never employed
it becomes very questionable whether the function is acting as a
constructor, or should be called as one.

otherwise as a simple function. By just adding
this.property = something;
into function body you don't tranform it in some magic way into
constructor.

What is the "it" you are referring to?

>>"A returns new instances of O; B returns new instance of A able to
return new instances of O".
In your opinion A and B do the same job?

>They are not both constructors.

They are:

No they are not. the latter may be categorised a 'factory' for
constructor instances but it is not a constructor.

but they are constructing different things.

>If all is wanted is an ability to augment an object with a closure to
store a name and a method for retreating it wouldn't:-

function addNameInterface(name, obj){
obj.getName = function(){
return name;
};
}
function FormProperty(arg) {
addNameInterface(arg.name, this);
}

- get there quicker, cleaner, more directly and in a lot less code?

Mostly because it's not what OP was after :-)

I know the OP was not after that, it is a more sensible implementation
of the nonsense code you posted. The OP is interested in subclassing,
for which your code was irrelevant.

If I'm mistaken OP will
correct me.

Richard.

[VK]

Richard Cornford wrote:

But there is no point in calling a function as a constructor (with the
- new - operator) if it returns any object other than the value of the
- this - keyword.

Really? Well, I guess it depends on the chosen coding style. The
following code is polemic (to your statement) so a bit too complicated
to show different options at once:

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

<script type="text/javascript">

function F(arg) {

if (typeof arg != 'string') {
return new Boolean(false);
}

var secret = arg;

this.secret = new Object;

this.secret.getSecret = function() {
window.alert(secret);
}

return this.secret;
}

var f0 = new F(null);
var f1 = new F('foo');
var f2 = new F('bar');

if (f0 != false) {
f0.getSecret();
}

if (f1 != false) {
f1.getSecret();
}

if (f2 != false) {
f2.getSecret();
}
</script>
</head>

<body>
</body>
</html>

[VK]

VK wrote:

The
following code is polemic (to your statement) so a bit too complicated
to show different options at once:

or even like this:

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script>

function F() {
var $ = this;
var private = 'empty'
;
this.setPrivate = function(arg) {
private = arg || 'empty';
return $;
}

this.getPrivate = function() {
return private;
}
}

var f = (new F).setPrivate('foo');
alert(f.getPrivate());
</script>
</head>

<body>
</body>
</html>

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

But there is no point in calling a function as a constructor (with the
- new - operator) if it returns any object other than the value of the
- this - keyword.

Really? Well, I guess it depends on the chosen coding style.

You can chose to program like a halfwit, if you must.

The following code is polemic (to your statement) so a bit too
complicated to show different options at once:

<snip>

function F(arg) {

if (typeof arg != 'string') {
return new Boolean(false);
}

var secret = arg;

this.secret = new Object;

this.secret.getSecret = function() {
window.alert(secret);
}

return this.secret;
}

var f0 = new F(null);
var f1 = new F('foo');
var f2 = new F('bar');

<snip>

And once again you post code without stating what it is supposed to
demonstrate. Presumably the intention was to show that there is some
purpose in treating a function as a constructor when it does not return
the object constructed. If so it fails to achieve that as substituting
the above with:-

function f(arg){
if(typeof arg != 'string'){
return new Boolean(false);
}else{
return ({getSecret:function(){alert(arg);}});
}
}

var f0 = f(null);
var f1 = f('foo');
var f2 = f('bar');

- achieves exactly the same outcome without treating a function that is
not acting as a constructor as if it was a constructor (and again does
so with considerably less code, and less convoluted code.

There is no benefit to writing inefficient, indirect and confusing
code, and being able to is hardly an excluse.

Richard.

[Richard Cornford]

VK wrote:

VK wrote:

>The
following code is polemic (to your statement) so a bit too
complicated to show different options at once:

or even like this:

You blithering idiot: var f = (new F).setPrivate('foo'); _is_ calling a
function that returns the - this - object as a constructor. It is not
relevant to the question of whether functions that do not return the -
this - object should be subject to the - new - operator.

<snip>

function F() {
var $ = this;
var private = 'empty'
;
this.setPrivate = function(arg) {
private = arg || 'empty';
return $;
}

this.getPrivate = function() {
return private;
}
}

Why the needless complexity?

function F() {
var private = 'empty' ;
this.setPrivate = function(arg) {
private = arg || private;
return this;
};
this.getPrivate = function() {
return private;
};
}

- Does the same job.

var f = (new F).setPrivate('foo');

What is the advantage of this indirect construct over the more normal:-

var f = new F;
f.setPrivate('foo');

-or:-

var f;
(f = new F).setPrivate('foo)';

- and not having to return the object instance from the - setPrivate -
method (which should probably be returning an indicator of its success,
if anything at all).

Richard.

[VK]

Richard Cornford wrote:

And once again you post code without stating what it is supposed to
demonstrate.

The flexibility of JavaScript and its readiness to become an antique
vase, a Picasso sculpture or an ugly pot depending on your hands and
your mind. Whoever gets scared of this flexibility she's better run
away calling mommy (drop stupid JavaScript and use some Real Serious
Language like say PHP, C++, Java etc.)
That is not in relation of anyone's post in this thread, just an
overall statement.

[VK]

VK wrote:

The flexibility of JavaScript and its readiness to become an antique
vase, a Picasso sculpture or an ugly pot depending on your hands and
your mind. Whoever gets scared of this flexibility she's better run
away calling mommy (drop stupid JavaScript and use some Real Serious
Language like say PHP, C++, Java etc.)
That is not in relation of anyone's post in this thread, just an
overall statement.

Just got scared to be taken for a regular who managed to learn one
thing only and now considers that thing as the best one just by the
fact of knowing nothing but that.

I speak freely Perl, classical Java (Swing slang is not my cup of tea),
C, VBA. With some minor translation help I speak C++ and C#.
Loose-typed languages are hugely ineffective in comparison with
strictly typed ones by memory usage and run-time code productivity. At
the same time strictly typed languages with encapsulation are deadly
boring and templated. This is the price they had to pay to be the core
of some extremely complicated systems like say computer OS. JavaScript
did not have to pay this price. From one side: doubtfully we'll ever
see a computer OS written on JavaScript; from the other side: relax and
enjoy, guys :-)

[Richard Cornford]

VK wrote:
<snip>

I speak freely Perl, classical Java (Swing slang is not my
cup of tea), C, VBA. With some minor translation help I
speak C++ and C#.

<snip>

There is no point in trying to bullshit us here. We know you are not a
programmer at all, you just aren't rational enough for that.

Richard.

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

>And once again you post code without stating what it is
supposed to demonstrate.

The flexibility of JavaScript ...

<snip>

There are no programming languages that are not flexible enough to allow
people to write stupid, inefficient, inept code out of ignorance of what
the code they are writing is doing. Demonstrating you ability to do that
is of no value.

Richard.

[VK]

There is no point in trying to bullshit us here. We know you are not a

programmer at all, you just aren't rational enough for that.

There is no point in trying to bullshit us here. We know you did not
make
any real money from your knowledge. You are just too rational for that.

That was harsh actually. W-2 for the last year mutual exchange maybe?

>From the other side just hell on your opinion on this matter.

[VK]

VK wrote:

That was harsh actually.

Or did you take
http://message-id.net/<11**********************@f16g2000cwb.googlegroups .com>

and in the particular

Just got scared to be taken for a regular who managed to learn one
thing only and now considers that thing as the best one just by the
fact of knowing nothing but that.

as something addressed to you? In such case damn on you Brits: from all
possible sentence interpretations you will always choose the least
expected one (something in common with Germans btw). I meant myself and
my own words: and nothing else.

[Pacific Fox]

Dear Richard,

You should really learn some manors, the way you respond is just not
correct, you talk like you know everything. And assume everyone is
stupid. FYI I've been working with JavaScript for over 8 years now,
just getting into trying to make it work like some OOP languages.

Now let me see if maybe VK has been able to help me out, it looks like
he is making more sense..

Richard Cornford wrote:

VK wrote:

Richard Cornford wrote:

And once again you post code without stating what it is
supposed to demonstrate.

The flexibility of JavaScript ...

<snip>

There are no programming languages that are not flexible enough to allow
people to write stupid, inefficient, inept code out of ignorance of what
the code they are writing is doing. Demonstrating you ability to do that
is of no value.

Richard.

[John G Harris]

In article <11**********************@e3g2000cwe.googlegroups. com>,
Pacific Fox <ta*******@gmail.comwrites

>Dear Richard,

You should really learn some manors, the way you respond is just not
correct, you talk like you know everything. And assume everyone is
stupid. FYI I've been working with JavaScript for over 8 years now,
just getting into trying to make it work like some OOP languages.

Now let me see if maybe VK has been able to help me out, it looks like
he is making more sense..

<snip>

VK has a habit of saying things that are misleading or plain wrong.
That's what we object to. There are too many confused programmers
already. The world can't afford even more of them.

For instance, there are some nasty traps for the unwary when using
'with'. Did you understand what they are after reading VK's writings on
the subject ?

John
--
John Harris

[Matt Kruse]

Pacific Fox wrote:

Dear Richard,
You should really learn some manors, the way you respond is just not
correct, you talk like you know everything. And assume everyone is
stupid.

While Richard does lack social grace and can come across quite abrasively,
he is one of the most technically knowledgeable people in this group. It's
best to read his postings and learn from his technical insights while
ignoring his "know it all" attitude and simply scanning through his more
verbose ramblings.

Now let me see if maybe VK has been able to help me out, it looks like
he is making more sense..

Doubtful. VK posts here a lot, and does so with wild abandon for technical
accuracy. His errors are often corrected, but he continues to spread the
same ignorance repeatedly. I don't think that he can realistically offer any
value to someone asking for assistance here, and more than likely will do
more harm than good.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[VK]

John G Harris wrote:

VK has a habit of saying things that are misleading or plain wrong.
That's what we object to. There are too many confused programmers
already. The world can't afford even more of them.

So has to leave among two of us? :-) - just kidding...

Truthfully I don't see how my original post could help to OP. I was
going strictly by his original post and I was too concentrated on
private vars and their retrieval in his samples. So I thought he wanted
to implement some kind of inheritable private properties factory.

Later I found his additional post stating:

Whatever you want to call it, however you want to see it, it allows to
me to call functions without having to specify every parameter, i.e.
someMethod( "some value", null, null, null, null, null, null, null,
null, null, "and another value" )

So if I get it right this time, private scope methods were irrelevant
to the case and they just were used as "Lorem ipsum" in the sample. If
OP simply wanted to implement VB-like named arguments, it can be done
right in the constructor w/o any extra functions:

<script type="text/javascript">
function MyObject() {
var i;
var p;
for (i=0; i<arguments.length; ++i) {
for (p in arguments[i]) {
this[p] = arguments[i][p];
}
}
}

var obj1 = new MyObject({'foo':'bar'});
var obj2 = new MyObject({'foo':'bar'},{'bar':'foo'});
alert(obj1.foo);
alert(obj2.bar);
</script>

[VK]

VK wrote:

So if I get it right this time, private scope methods were irrelevant
to the case and they just were used as "Lorem ipsum" in the sample. If
OP simply wanted to implement VB-like named arguments, it can be done
right in the constructor w/o any extra functions:

<snip code>

It can be even further adjusted so it would use provided named
arguments and default values for missing arguments. That gets a bit
consuming but it's a regular price to pay: lesser thinking for a user -
more thinking for the engine :-)

<script type="text/javascript">

function MyObject() {
var DEFAULT = {
'prop1' : 1
, 'prop2' : 2
, 'prop3' : 3
};

var i;
var p;
for (i=0; i<arguments.length; ++i) {
// only for objects
if (typeof arguments[i] == 'object') {
for (p in arguments[i]) {
// one name : one value
this[p] = arguments[i][p]; break;
}
}
}
for (p in DEFAULT) {
// default values for missing arguments
if (!(p in this)) {
this[p] = DEFAULT[p];
}
}
}

var obj = new MyObject({'prop2':'foo'},{'prop3':'bar'});

alert(obj.prop1); // 1
alert(obj.prop2); // foo
alert(obj.prop3); // bar
</script>

[Richard Cornford]

VK wrote:

VK wrote:

>So if I get it right this time, private scope methods
were irrelevant to the case and they just were used as
"Lorem ipsum" in the sample. If OP simply wanted to
implement VB-like named arguments, it can be done right
in the constructor w/o any extra functions:

<snip code>

I see your analysis is up to its usual standard. The OP's question was
about an error produced by trying to call a constructor that required an
object as its argument (because it was interacting which that object
without verifying its existence) without an object as its argument.

That questions has substantially been answered because the various
solutions are: verifying that an object was passed as an argument prior
to treating it as one, or: never calling the constructor without an
object as its argument (and in the case of the posted code not calling
the constructor without an object as its argument by not calling the
constructor to assign a value to another constructor's prototype from
within that second constructor as doing so would not have the desired
result at all if inheritance from the prototype was desired, is
needlessly inefficient and was worthless in this case a no properties of
the resulting object existed that would not be masked by properties
assigned directly to the object).

What you are posting here is irrelevant (though that is normal for you),
and it represents a very dubious notion in the context of implementing
class-style inheritance in javascript as it means that the properties of
the resulting object (rather than just the values of those properties)
depend directly on the arguments passed to the constructor. The result
is a constructor that does not create objects of any single 'type' or
'class' (as conceptually objects of a single class will have the same
properties and methods and just their values will vary between
instances), but instead create an object who's 'class' depends on the
arguments used.

It can be even further adjusted so it would use provided
named arguments and default values for missing arguments.
That gets a bit consuming but it's a regular price to pay:
lesser thinking for a user - more thinking for the engine :-)

One of the consequences of your not comprehending the role of prototypes
in javascript (as was manifest in your bizarre assertion that using
the - new - operator on a constructor and assigning to that
constructor's prototype in the same code was like "trying to speak
French and German at once") is that it leaves you writing the most
phenomenally stupid code:-

<script type="text/javascript">

function MyObject() {
var DEFAULT = {
'prop1' : 1
, 'prop2' : 2
, 'prop3' : 3
};

You realise that that the evaluation of this object literal will result
in the creation of a new, and unique, object with each execution of this
constructor, when each of those objects has the same properties with the
same values? Any strategy that only required one instance of this object
to be created would be superior, and understanding the role of
prototypes in javascript would have allowed you to see a very obvious
strategy for achieving that.

var i;
var p;
for (i=0; i<arguments.length; ++i) {
// only for objects
if (typeof arguments[i] == 'object') {
for (p in arguments[i]) {
// one name : one value
this[p] = arguments[i][p]; break;

Why the break here? Doesn't that mean that each object that appears in
the argument's list can only contribute a single named property, and so
that a distinct object would be needed to pass each and every named
property to the object? It is bad enough to be creating a new object for
each function call, but not letting a single object contribute multiple
named arguments really is daft.

Though passing multiple objects with multiple properties highlights the
issue of whether properties of a later object should be replacing
properties provided on earlier ones, or vica verca. But even if each
argument object can only contribute the first of its properties
enumerated (enumeration sequences is not guaranteed to be consistent in
javascript, either within the same implementation or across
implementations) there is still a possibility that more than one object
may attempt to contribute a value for the same property of the object
being constructed.

}
}
}
for (p in DEFAULT) {
// default values for missing arguments
if (!(p in this)) {
this[p] = DEFAULT[p];
}
}
}

var obj = new MyObject({'prop2':'foo'},{'prop3':'bar'});

alert(obj.prop1); // 1
alert(obj.prop2); // foo
alert(obj.prop3); // bar
</script>

Apart from allowing constructed object instances to share single
instances of function objects as their methods, prototype inheritance
allows for the defaulting of the values of the properties of constructed
objects. This works because, when a property name is resolved against an
object, if the object has a property of the given name itself it is the
value of that property that is the result, but when the object does not
have the property its prototype chain is examined and the value of the
first property on the prototype chain with the corresponding property is
the result (else it is undefined if no objects on the chain have the
named property).

In the same way as all instances of an object share the instances of
function objects on their prototypes they also share the vales of the
other named properties on their prototypes. This becomes the
standard/natural method of defaulting the vales of object properties in
javascript, and is considerably more efficient than the stupid strategy
you use above as it is achieved passively rather than by actively
enumerating the properties of an object and then testing the results:-

function AnObject() {
var i, p, a, len = arguments.length;
for(i = 0;i < len;++i){
if(typeof (a = arguments[i]) == 'object'){
for (p in a) {
this[p] = a[p];
}
}
}
}
/* With:- */
AnObject.prototype = {
prop1:1,
prop2:2,
prop3:3
};
/* OR:-

AnObject.prototype.prop1 = 1;
AnObject.prototype.prop2 = 2;
AnObject.prototype.prop3 = 3;

- depending on whether the value of the prototype's -
constructor - property is needed to remain a reference
to - AnObject -(which generally does not matter).
*/

var obj = new AnObject({'prop2':'foo'},{'prop3':'bar'});

alert('obj.prop1 = '+obj.prop1);
alert('obj.prop2 = '+obj.prop2);
alert('obj.prop3 = '+obj.prop3);

So that is the same outcome with about half the code and no creating of
a new 'defaulting' object with each execution of the constructor and no
need to loop through the properties of that object in the constructor
either. The arguments either contribute a value that is assigned to a
property of the object itself (masking any default value on the
prototype under the same property name) or it does not and any values
already set on the prototype act as the defaults.

You may assert that javascript is flexible enough to let you get away
with stupid implementations, but knowing how javascript works gives you
the opportunity to do things well, and save much time writing pointless
code along the way.

Richard.

[VK]

Richard Cornford wrote:

I see your analysis is up to its usual standard. The OP's question was
about an error produced by trying to call a constructor that required an
object as its argument (because it was interacting which that object
without verifying its existence) without an object as its argument.

Until OP explains *what exactly* his aim was (if he still kept any
desire to discuss his problems on c.l.j. :-) I consider futile to keep
guessing.

[Gary Stephenson]

Has anyone ever seen Richard Cornford and VK in the same room together?

My thesis is that they are one and the same person, and VK is just an alter
ego that Richard invented as a endless source of stupidities in need of
correction. Or perhaps Richard has a true split personality and doesn't
even _know_ that VK is in fact an alter ego ...

In any case, I will definitely rue the day when one or other of these two
stop posting (although I only ever actually read Richard's posts) as I
suspect my learning curve will flatten out considerably as a result.

<0.5wink>'ly yrs,

gary

http://www.oxide.net.au

"VK" <sc**********@yahoo.comwrote in message
news:11**********************@k70g2000cwa.googlegr oups.com...

>
Richard Cornford wrote:

>I see your analysis is up to its usual standard. The OP's question was
about an error produced by trying to call a constructor that required an
object as its argument (because it was interacting which that object
without verifying its existence) without an object as its argument.

Until OP explains *what exactly* his aim was (if he still kept any
desire to discuss his problems on c.l.j. :-) I consider futile to keep
guessing.

[VK]

Gary Stephenson wrote:

In any case, I will definitely rue the day when one or other of these two
stop posting (although I only ever actually read Richard's posts) as I
suspect my learning curve will flatten out considerably as a result.

In such case did you consider to move on reading another newsgroup more
suitable to your learning curve? The Usenet is very big and no one will
get upset (nor notice) if you leave.

If you have a question but you are interested in answer from only one
(two, three) person(s) you know by names then the Usenet is not really
a suitable media for that. Personal e-mail (mailing list) or blog
comments are the right tools for that.