Intercept instanceof

R

Robert

Hi,

Is it possible to intercept a call to "instanceof" and return something
different? I wanted to see if it was possible to implement something
like multiple inheritance, especially to use instanceof where a
component extends an object and implements some listener interface too
for a MVC architecture.
 
D

David Mark

Hi,

Is it possible to intercept a call to "instanceof" and return something
different? I wanted to see if it was possible to implement something
No.

like multiple inheritance, especially to use instanceof where a
component extends an object and implements some listener interface too
for a MVC architecture.
 
R

Robert

Thomas said:

I have seen your popular examples before of course :)

Anyway, I figured a reasonable way to implement it. I can't use
instanceof, but it is not too bad.

I will do something like this now...

function IMyListener()
{
}

IMyListener.prototype.event = function() {};
IMyListener.__INTERFACE = true;

And when I validate arguments and expect an interface I call an
isImplementation that checks whether the argument object implements all
the methods of an interface.

I still can't use instanceof, which is too bad, but till now I just need
it for arguments validation anyway.
 
V

VK

Anyway, I figured a reasonable way to implement it. I can't use
instanceof, but it is not too bad.

I will do something like this now...

function IMyListener()
{

}

IMyListener.prototype.event = function() {};
IMyListener.__INTERFACE = true;

And when I validate arguments and expect an interface I call an
isImplementation that checks whether the argument object implements all
the methods of an interface.

For a particular property check all along the inheritance chain there
is boolean ('property' in object). So you need only
IMyListener.prototype.event = function() {};
and later then
if ('event' in objectInstance) {
// OK
}

For instanceof and constructor topis in Javascript I regularly
suggest
http://blogs.msdn.com/ericlippert/archive/2003/11/06/53352.aspx
by Eric Lippert
 
T

Thomas 'PointedEars' Lahn

VK wrote/zu Deiner Priorität-Alpha-1-Nachricht von Sternzeit 22.01.2008 21:31:
For a particular property check all along the inheritance chain there
is boolean ('property' in object). So you need only
IMyListener.prototype.event = function() {};
and later then
if ('event' in objectInstance) {
// OK
}

Utter nonsense, any object may have an `event' property. Consider `window'
in MSHTML for a start.
For instanceof and constructor topis in Javascript I regularly
suggest
http://blogs.msdn.com/ericlippert/archive/2003/11/06/53352.aspx
by Eric Lippert

That it is your recommendation is by itself already a good reason to avoid
that resource, however then the author provides sufficient evidence himself
that he has not understood how the prototype chain works with the following
example code:

var Animal = new Object();
// ...
Reptile.prototype = Animal;

If he had instead used the clone() methods suggested here to include the
prototype object of the constructor in the prototype chain instead of a
specific Object object, he would have had no problem determining that the
`constructor' property would yield the correct value.


PointedEars
 
R

Robert

VK said:
For a particular property check all along the inheritance chain there
is boolean ('property' in object). So you need only
IMyListener.prototype.event = function() {};
and later then
if ('event' in objectInstance) {
// OK
}

I don't understand what you are trying to say.
 
V

VK

I don't understand what you are trying to say.

Truly I don't understand what are you currently doing neither. In Java
interfaces are used to work around the model limitation preventing
multiple inheritance. These are abstract classes one has to attach to
and redefine in the object instance. Respectively instanceof operator
had been patched there so say on
myClass extends someClass implements Runnable, MouseListener {...}
later (myClassInstance instanceof Runnable) is true which is
semantically and technically plain b.s. - myClassInstance instanceof
myClass and Object but no way of Runnable: yet this convenience patch
will stay in use.

Javascript doesn't have abstract constructors not it needs interfaces
for multiple inheritance. All you may care about is:
1) does obj have this particular object in its chain?
2) does this particular object has needed property/method
3) (sometimes occasionally) is this particular object located at the
specific point of the chain?

Respectively for this you have:

// anywhere along of the chain
boolean ('property' in obj)

// at this specific place of chain
boolean obj.hasOwnProperty('property');

// Prototype study
boolean someObject.isPrototypeOf(otherObject)

// Syntax sugar for Javers and C++'ers
// over prototype study
boolean (someObject instanceof otherObject)

Actually you need only the first three for Javascript itself, and I
tried to show how to use the first one of them. Of course you are free
to use instanceof wrapper as well: no real technical harm, just as any
syntax sugar it may be misleading by presenting things not in the way
they really are.
 
V

VK

I don't understand what you are trying to say.

Truly I don't understand what are you currently doing neither. In Java
interfaces are used to work around the model limitation preventing
multiple inheritance. These are abstract classes one has to attach to
and redefine in the object instance. Respectively instanceof operator
had been patched there so say on
myClass extends someClass implements Runnable, MouseListener {...}
later (myClassInstance instanceof Runnable) is true which is
semantically and technically plain b.s. - myClassInstance instanceof
myClass and Object but no way of Runnable: yet this convenience patch
will stay in use.

Javascript doesn't have abstract constructors not it needs interfaces
for multiple inheritance. All you may care about is:
1) does obj have this particular object in its chain?
2) does this particular object has needed property/method
3) (sometimes occasionally) is this particular object located at the
specific point of the chain?

Respectively for this you have:

// anywhere along of the chain
boolean ('property' in obj)

// at this specific place of chain
boolean obj.hasOwnProperty('property');

// Prototype study
boolean someObject.isPrototypeOf(otherObject)

// Syntax sugar for Javers and C++'ers
// over prototype study
boolean (someObject instanceof otherObject)

Actually you need only the first three for Javascript itself, and I
tried to show how to use the first one of them. Of course you are free
to use instanceof wrapper as well: no real technical harm, just as any
syntax sugar it may be misleading by presenting things not in the way
they really are.
 
V

VK

For a particular property check all along the inheritance chain there
Utter nonsense, any object may have an `event' property. Consider `window'
in MSHTML for a start.

Can you grasp a difference between an approach suggestion and a
turnkey solution? It can be as many necessary checks as needed, OP
simply doesn't provide enough data to code all of them - plus sure he
can easily do it himself.
That it is your recommendation is by itself already a good reason to avoid
that resource, however then the author provides sufficient evidence himself
that he has not understood how the prototype chain works

ROTFL
The maker of JScript and WSH engine doesn't know how does the engine
works... Lucky we have Thomas here handy. :)

First of all Eric Lippert does know it; secondly even if he didn't
know: the engine works in the way he did it, not in the way Thomas or
anyone else may think about it. Do you have any particular complains
of prototype inheritance violations in JScript?
with the following
example code:

var Animal = new Object();
// ...
Reptile.prototype = Animal;

Please _read_ the article, not just look at it. There are some
convoluted code blocks in there with questionable practicality:
because the article explains the theory of .prototype and .constructor
properties in Javascript, it is not some code snippet with comments.
 
T

Thomas 'PointedEars' Lahn

VK said:
Utter nonsense, any object may have an `event' property. Consider `window'
in MSHTML for a start.

Can you grasp a difference between an approach suggestion and a
turnkey solution? [...]

Yes, I can. So, unsurprisingly, your suggestion is a bad one again. Why
don't you simply stop suggesting until you have understood how things work?
That it is your recommendation is by itself already a good reason to avoid
that resource, however then the author provides sufficient evidence himself
that he has not understood how the prototype chain works

ROTFL
The maker of JScript and WSH engine doesn't know how does the engine
works... [...]

If what you say about him is true, apparently he does not know how he was
supposed to implement the language specification. That would explain a
great deal about JScript, though.


PointedEars
 
V

VK

ROTFL
The maker of JScript and WSH engine doesn't know how does the engine
works... [...]

If what you say about him is true, apparently he does not know how he was
supposed to implement the language specification. That would explain a
great deal about JScript, though.

http://blogs.msdn.com/ericlippert/about.aspx
also feel free to check out in Microsoft or ask Eric himself in this
blog, he is a nice guy.

So I guess I have to repeat my question: do you have any theoretical
complains against the prototype inheritance in JScript?
So far from the point of view of the source trust whatever Thomas says
is pointless as long as it contradicts to what Eric says. IMO it is a
reasonable choice for anyone.
 
T

Thomas 'PointedEars' Lahn

VK said:
ROTFL
The maker of JScript and WSH engine doesn't know how does the engine
works... [...]
If what you say about him is true, apparently he does not know how he was
supposed to implement the language specification. That would explain a
great deal about JScript, though.

http://blogs.msdn.com/ericlippert/about.aspx
also feel free to check out in Microsoft or ask Eric himself in this
blog, he is a nice guy.

So I guess I have to repeat my question: do you have any theoretical
complains against the prototype inheritance in JScript?
So far from the point of view of the source trust whatever Thomas says
is pointless as long as it contradicts to what Eric says. IMO it is a
reasonable choice for anyone.

Unsurprisingly, you missed the point completely. Eric's explanation there
is probably correct (I have not read it thoroughly yet, what I read was
enough to see his mistake), however he only observed what he observe because
he did not implement prototype-based inheritance properly in his example
code although he should have known better. What's worse, he attributes this
behavior to a lacking definition in the ECMAScript specification although he
should have known better.


PointedEars
 
V

VK

Eric's explanation there
is probably correct (I have not read it thoroughly yet <snip>

So maybe you read it first and then we can discuss all his mistakes?
If any found it will be sure possible to counter-proof them with some
experimental code.
 
T

Thomas 'PointedEars' Lahn

Nice distortion job.
So maybe you read it first and then we can discuss all his mistakes?
If any found it will be sure possible to counter-proof them with some
experimental code.

You are an idiot. Probably someone has called you so before.


PointedEars
 
V

VK

Eric's explanation there
is probably correct (I have not read it thoroughly yet <snip>
[/QUOTE]

Nice distortion job.[/QUOTE]

Why "distortion job"? I just follow your own suggestion "quote only
what is relevant for your post". The relevant part is that you didn't
read the article you are trying to criticize, anything else is
irrelevant. :) :-|
You are an idiot. Probably someone has called you so before.

Extremely productive argument. So I guess you don't have any
theoretical complains against prototype inheritance as implemented in
JScript engine. Well, this branch of discussion may be closed then?
 
R

Robert

VK said:
Why "distortion job"? I just follow your own suggestion "quote only
what is relevant for your post". The relevant part is that you didn't
read the article you are trying to criticize, anything else is
irrelevant. :) :-|


Extremely productive argument. So I guess you don't have any
theoretical complains against prototype inheritance as implemented in
JScript engine. Well, this branch of discussion may be closed then?

Thank you guys for making me laugh this morning :D
 
R

Robert

VK said:
Truly I don't understand what are you currently doing neither.

Ah ok, that would explain it.
But I understand what you are trying to say now.
Instead of using instanceof and checking the "type" of an object, I
should use property checking.
And that is basically what I do now. I check if the object has all the
properties defined in the interface.

In Java
interfaces are used to work around the model limitation preventing
multiple inheritance. These are abstract classes one has to attach to
and redefine in the object instance. Respectively instanceof operator
had been patched there so say on
myClass extends someClass implements Runnable, MouseListener {...}
later (myClassInstance instanceof Runnable) is true which is
semantically and technically plain b.s. - myClassInstance instanceof
myClass and Object but no way of Runnable: yet this convenience patch
will stay in use.

I would be very annoyed if Java or any language would force me to use
different operators to test if it extends/implements a class or an
interface.
myClassInstance instanceof Runnable
makes perfect sense to me.
Javascript doesn't have abstract constructors

Actually I do. I throw an AbstractException in constructors for things I
regard as interfaces.
not it needs interfaces
for multiple inheritance. All you may care about is:
1) does obj have this particular object in its chain?
2) does this particular object has needed property/method
3) (sometimes occasionally) is this particular object located at the
specific point of the chain?

It may not be needed in the same sense that inheritance is not needed,
but I also desire a test if an object has all properties as defined in
another prototype. It may not be full-proof but it suffices.

A hypothetical example to demonstrate this:

function IDragListener()
{
}
IDragListener.prototype.dragDropEnd = function(event) {};
IDragListener.prototype.dragEnter = function(event) {};
IDragListener.prototype.dragExit = function(event) {};
IDragListener.prototype.dragOver = function(event) {};


function SpecialComponent()
{
var list = new ArrayList();

this.addListener = function(listener)
{
validate(arguments, [IDragListener]);
list.add(listener);
}

function fireDragEnterEvent()
{
var it = list.iterator();
while (it.hasNext())
{
var listener = it.next();
listener.dragEnterEvent(new DragEvent());
}
}
}

So I could make a test in each fire method to test if the added listener
has that particular property.
However I prefer to test it during adding the listener. I reality this
is actually only done in a debug mode. Doing it like this enables me to
find the error in an earlier stage and takes less code.
 
V

VK

The posted code is still not sufficient to understand the model,
because IMO it is not functional:
validate(arguments, [IDragListener]);
cannot tell you anything useful about dragDropEnd, dragEnter etc.
because these methods have nothing to do with IDragListener so this
constructor has no idea about them:
('dragDropEvent' in IDragListener) === false
As it was stressed out in the linked article, "The object which is
assigned to the prototype property of the constructor is the prototype
of the instance." Thus for IDragListenerInstance all drag methods will
be available by default, but not to the constructor. If I am any close
to what are trying to do - and sorry in advance if mistaken - you are
trying to keep the usual for you programming pattern with abstract
interfaces later extended in classes and with frozen (encapsulated)
object instances. This programming pattern is totally alien to
Javascript but for the time saving sake you may then use Prototype.js
wrapper over the native behavior. This library was intentionally
written to enforce "C++ look-and-feel" on Javascript. Some unevitable
internal clumsiness of code and some productivity/memory loss is
compensated by not having to switch the programming pattern back and
forth.

While staying on the lower level, you may use something like:

function IDragListener()
{
this.dragDropEnd = IDragListener.dragDropEnd;
this.dragEnter = IDragListener.dragEnter;
this.dragExit = IDragListener.dragExit;
this.dragOver = IDragListener.dragOver;
}

IDragListener.dragDropEnd = function(event) {};
IDragListener.dragEnter = function(event) {};
IDragListener.dragExit = function(event) {};
IDragListener.dragOver = function(event) {};

This way you are getting "kind of class" where you can both
1) create new instances
var obj = new IDragListener;
2) query IDragListener constructor for particular "interfaces"
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,781
Messages
2,569,619
Members
45,316
Latest member
naturesElixirCBDGummies

Latest Threads

Top