By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,472 Members | 1,204 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,472 IT Pros & Developers. It's quick & easy.

Identifying call of copy of ((){ })();

P: n/a
I have this (the name is fixed by the LMS):

var API_1484_11 = (function() {
// private variables

// private methods

// public methods
return {
get : function() {
if (called via API) {

} else {

}
}
};
})();

and because an older LMS expect a different name I have this

var API = API_1484_11;
The code is effectively identical for both but API has a few subtle
differences that I need to take into account.

Is there a someway to tell if the public methods are called via API or
API_1484_11?

Andrew Poulos
Aug 29 '08 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Andrew Poulos wrote:
>I have this (the name is fixed by the LMS):
The London, Midland and Scottish railway company ceased trading in the
middle of the last century. It is unlikely that they could have dictated
anything relating to browser scripting.

The FAQ advises that acronyms (and particularly TLAs) should not be
posted without explanation unless they are truly unambiguous (and very
few are).
var API_1484_11 = (function() {
// private variables

// private methods

// public methods
return {
get : function() {
if (called via API) {

} else {

}
}
};
})();

and because an older LMS expect a different name I have this

var API = API_1484_11;
The code is effectively identical for both but API has a few subtle
differences that I need to take into account.

Is there a someway to tell if the public methods are called
via API or API_1484_11?
Not at all easily if they are the same object, and certainly not
reliably, efficiently or in a cross-browser manner. The only information
on the subject would be the source code that made the call, and although
in most cases (but certainly not all) - arguments.calleee.toString -
might expose that source code the work needed to extract the information
would be a huge (and pointless) overhead.

It would probably be simpler to wrap the fist object in a second that
implemented an identical public interface and then you could know which
was called based on the identity of the functions that made up the two
interfaces.

If the "code is effectively identical" there is no sense in asking this
question, or implementing any answer you may find.

Richard.

Aug 29 '08 #2

P: n/a
On Aug 29, 2:41*am, Andrew Poulos <ap_p...@hotmail.comwrote:
>
Is there a someway to tell if the public methods are called via API or
API_1484_11?
Nope.
API === API_1484_11 : both point to the very same object and therefore
a call to API.get() is identical to a call to API_1484_11.get().
AFAIK there's no way to tell the name of the "object pointer" used in
the call.
For that I think you're going to need to wrap it with/into two
additional (wrapper) objects.

--Jorge.
Aug 29 '08 #3

P: n/a
On Aug 29, 10:41*am, Andrew Poulos <ap_p...@hotmail.comwrote:
I have this (the name is fixed by the LMS):

var API_1484_11 = (function() {
* *// private variables

* *// private methods

* *// public methods
* *return {
* * *get : function() {
* * * *if (called via API) {

* * * *} else {

* * * *}
* * *}
* *};

})();

and because an older LMS expect a different name I have this

var API = API_1484_11;

The code is effectively identical for both but API has a few subtle
differences that I need to take into account.

Is there a someway to tell if the public methods are called via API or
API_1484_11?
I would keep API as a deprecated interface in your library and
transition to API_1484_11, otherwise you are creating a maintenance
headache.

Your transition plan might be, over a convenient time frame, replace
all calls to API with calls to API_1484_11 as a maintenance
opportunity task (along with testing, etc.). When you've replaced all
calls to API with API_1484_11, get rid of API.
--
Rob
Aug 29 '08 #4

P: n/a
Richard Cornford wrote:
Andrew Poulos wrote:
>I have this (the name is fixed by the LMS):

The London, Midland and Scottish railway company ceased trading in the
middle of the last century. It is unlikely that they could have dictated
anything relating to browser scripting.

The FAQ advises that acronyms (and particularly TLAs) should not be
posted without explanation unless they are truly unambiguous (and very
few are).
Sorry, LMS = Learning Management System
<url: http://en.wikipedia.org/wiki/Learning_management_system >
Specifically I'm referring to Sharable Content Object Reference Model
(SCORM) compliant systems.
>var API_1484_11 = (function() {
// private variables

// private methods

// public methods
return {
get : function() {
if (called via API) {

} else {

}
}
};
})();

and because an older LMS expect a different name I have this

var API = API_1484_11;
The code is effectively identical for both but API has a few subtle
differences that I need to take into account.

Is there a someway to tell if the public methods are called
via API or API_1484_11?

Not at all easily if they are the same object, and certainly not
reliably, efficiently or in a cross-browser manner. The only information
on the subject would be the source code that made the call, and although
in most cases (but certainly not all) - arguments.callee.toString -
might expose that source code the work needed to extract the information
would be a huge (and pointless) overhead.

It would probably be simpler to wrap the fist object in a second that
implemented an identical public interface and then you could know which
was called based on the identity of the functions that made up the two
interfaces.
I'll look into re-wrapping it.
If the "code is effectively identical" there is no sense in asking this
question, or implementing any answer you may find.
Yes you're right, I should have said "almost identical". Before data is
passed to the LMS it needs to be tested against requirements as laid out
in the relevant SCORM specification. The differences between the two
current "standards" are few and small, yet important.

Andrew Poulos
Aug 29 '08 #5

P: n/a
On Aug 29, 4:14 am, Andrew Poulos <ap_p...@hotmail.comwrote:
Richard Cornford wrote:
Andrew Poulos wrote:
I have this (the name is fixed by the LMS):
The London, Midland and Scottish railway company ceased trading in the
middle of the last century. It is unlikely that they could have dictated
anything relating to browser scripting.
The FAQ advises that acronyms (and particularly TLAs) should not be
posted without explanation unless they are truly unambiguous (and very
few are).

Sorry, LMS = Learning Management System
<url:http://en.wikipedia.org/wiki/Learning_management_system>
Specifically I'm referring to Sharable Content Object Reference Model
(SCORM) compliant systems.
var API_1484_11 = (function() {
// private variables
// private methods
// public methods
return {
get : function() {
if (called via API) {
} else {
}
}
};
})();
and because an older LMS expect a different name I have this
var API = API_1484_11;
The code is effectively identical for both but API has a few subtle
differences that I need to take into account.
Is there a someway to tell if the public methods are called
via API or API_1484_11?
Not at all easily if they are the same object, and certainly not
reliably, efficiently or in a cross-browser manner. The only information
on the subject would be the source code that made the call, and although
in most cases (but certainly not all) - arguments.callee.toString -
might expose that source code the work needed to extract the information
would be a huge (and pointless) overhead.
It would probably be simpler to wrap the fist object in a second that
implemented an identical public interface and then you could know which
was called based on the identity of the functions that made up the two
interfaces.

I'll look into re-wrapping it.
If the "code is effectively identical" there is no sense in asking this
question, or implementing any answer you may find.

Yes you're right, I should have said "almost identical". Before data is
passed to the LMS it needs to be tested against requirements as laid out
in the relevant SCORM specification. The differences between the two
current "standards" are few and small, yet important.

Andrew Poulos

I built a fully compliant SCORM 1.2.6 LMS and API backend and front
end using a Java server, Java application for back end and Java
applets along with the javaScript API in 2004 . I called it
'Elements'. It never saw the light of day since it was a University
project but it did pass the SCORM test suit with flying colours and
was used by my Placement employer to test his E-Learning software.

Took me 2 years to build. Sorry just gets me going when someone talks
about SCORM and LMS's

Graham

Oh well, got a good grade from Uni for it.

Aug 29 '08 #6

P: n/a
In comp.lang.javascript message <g9*******************@news.demon.co.uk>
, Fri, 29 Aug 2008 02:38:20, Richard Cornford
<Ri*****@litotes.demon.co.ukposted:
>Andrew Poulos wrote:
>>I have this (the name is fixed by the LMS):

The London, Midland and Scottish railway company ceased trading in the
middle of the last century. It is unlikely that they could have
dictated anything relating to browser scripting.
But <http://www.lms.ac.uk/is evidently active; its site was updated
last Wednesday, 27th; but it could merge with <http://www.ima.org.uk/>.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SonOfRFC1036)
Aug 30 '08 #7

This discussion thread is closed

Replies have been disabled for this discussion.