QUESTION: Can a function be set up as a constant in JS?

[David Mark]

From http://devpro.it/JSL/JSLOpenSource.js
---------
if(typeof(XMLHttpRequest)==="undefined"){XMLHttpRequest=function(){
var tmp=null,elm=navigator.userAgent;
if(elm.toUpperCase().indexOf("MSIE 4")<0&&window.ActiveXObject)
tmp=elm.indexOf("MSIE 5")<0?new ActiveXObject("Msxml2.XMLHTTP"):new
ActiveXObject("Microsoft.XMLHTTP");
return tmp;
}};

Ignorance with a generous helping of incompetence. It started out okay,
but went off the rails on the second line. Searching for (and finding)
userAgent virtually always signals closing the editor and discarding the
script. Granted, the OP didn't say _when_ they wrote this. Hopefully
it was a very long time ago and they have since changed their ways. Or,
on the other hand, perhaps they write scripts for Google, contribute to
Dojo, YUI, etc. It's a crazy world.

 

[David Mark]

wtf ... I knew I had to drink more coffee, sorry for 80% of typos

And 0% of quoting I presume.

 

[Thomas 'PointedEars' Lahn]

You can interpret however you want.

I would not need to interpret your texts if you took more care writing
them.

Why do you group in table unicode escape sequences for string literals
and regular expression literals? While escape sequences in string
literals are documented in ECMA-262-1, escape sequences in regular
expression literals are part of ECMA-262 standard edition 3.

The grouping had already been fixed for the next release (between r9 of
2009-12-19 and r10 of 2010-01-10). I have changed the Edition for "Unicode
escape sequence in RegExp literal" to ES _3_ now (copy-paste error).

And in table there isn't unicode escape sequences as part of
IdentifierName, which ECMA-262-3 allow.

Added for the next release.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Andrea Giammarchi wrote:

[Context restored]

[Thomas 'PointedEars' Lahn wrote:]

[Asen Bozhilov wrote:]

[...] It's compatible with any ECMA-262 implementations, because
`__proto__` is valid Identifier. Of course Identifiers name like
that aren't good practice. [...]

Yes, he got me confused (intentionally?) with the __proto__ argument.

__proto__ property points the inherited prototype

In JavaScript (i.e., in Gecko-based user agents); not in your code.
That is what you have gotten me confused with.

Since what you want to do is to know if an object inherited from
Map.prototype, where in Gecko Map.prototype === new Map().__proto__, I
have used that syntax to explain the concept behind the check.

It is much more likely that you tried to trick me.

Moreover, the === operator does not tell us if the instance inherits
from extended prototype, this is why isPrototypeOf is required.

function Map() {}
function Map2() {}
Map2.prototype = new Map;

var m = new Map;
var m2 = new Map2;

m2.__proto__ === Map.prototype; // false

m.__proto__.isPrototypeOf(m2); // true

// ... and ...
m.__proto__ === Map.prototype; // true

So, how can you get confuse about that variable called __proto__?

(It is a function _argument_, not a variable.) How can you be naming an
function argument like that?

Finally, which part of an exposed public constructor property unable
to tell you about inheritance, if any, can be considered more robust?

I have already showed you that the isPrototypeOf() method is not as
compatible as the `constructor' property -- it is unavailable, e.g.,
in JScript 5.0 (IE/MSHTML 5.0). What more there is to know?

And why are don't you deal with IE3 as well and possibly with a
browser for Commodore 64?

Argument at ridicule. (There was no JavaScript when Commodore 64 was still
alive.)

Learn to quote: <http://jibbering.com/faq/#posting> pp.


PointedEars

 

[Jorge]

Argument at ridicule.  (There was no JavaScript when Commodore 64 was still
alive.)

http://58.6.118.18/

 

[Asen Bozhilov]

Andrea Giammarchi wrote:

(It is a function _argument_, not a variable.)  How can you be naming an
function argument like that?

It can be harmful. Not only confused readers, but can pollute Scope
Chain in strict implementation of ECMA-262-3. If `__proto__` is mimic
of [[Prototype]] property, that can change Prototype Chain of VO. And
during Identifier Resolution will be lookup in Prototype Chain of next
object in Scope Chain. So in theory that property name of VO is
harmful:

var x = true;
(function () {
var __proto__ = {x : false};

print(x); //?
})();

I can't see any implementation there print "false", but in theory can.
So it's depend by implementation of AO/VO and definitely i can't use
Identifiers like this.

1. Confuse readers
2. In some implementations can pollute Scope Chain. Of course that
point is only in theory.

 

[Andrea Giammarchi]

Michael Haufe ("TNO") wrote:
Ignorance with a generous helping of incompetence.  It started out okay,
but went off the rails on the second line.

the fact the library is not updated with a clear link to the latest
version marked 2007/11/03 and released actually 2 or 3 years after
that one posted just to provide some old trick able to bring JS
features in IE4 does not tell you anything, right?

What about being simply superficial and arrogant? Do you write code
like that? Can't wait to blame your first script ... uh wait, if it
was you, I am sure it is perfect, right? Ridiculous.

Anyway, this happens when you would like to share or help, and people
are ready to show off remarking silly things without investigating a
little bit (e.g. with the updated version) for a death project like
that, as death is IE4, still there for case studies like those Thomas
is doing with code that should be compatible with IE4.

@Thomas, I do believe you lack of sarcasm (C=64), while I have never
read a single valid point about your constructor check.
I think you will be the only one in this world to use such deprecated
and wrong check which is also against JS prototypal inheritance
concept, where functions, as constructors, are simply implicit
initializers and nothing else, able to chain the current prototype,
and again nothing else.
In JS objects extend objects, but I am sure you know that instanceof
simply checks it, as sure I am that you will use instanceof for every
browser, except those nobody uses anymore such IE4 ... isn't it?

I would like to know how you trap in closure try catches and how you
use them, since IE4 will throw an error as soon as you call those
methods ... should we talk about sniffing? or you have better options
to know if the browser is IE4 ? And what about the code size, is it a
dedicated IE4 version against the rest of the real world or what?

Finally, I will learn to quote, but too often this ML is just a show
off place with zero outcome and few valid points ... I do hope this ml
will grow up some day, so far I have read too often just "blame for
free to become famous" behaviors, annoying for both seniors and
juniors, useless for the community.

Best Regards

 

[Andrea Giammarchi]

(It is a function _argument_, not a variable.)  How can you be namingan
function argument like that?

It can be harmful. Not only confused readers, but can pollute Scope
Chain in strict implementation of ECMA-262-3. If `__proto__` is mimic
of [[Prototype]] property, that can change Prototype Chain of VO. And
during Identifier Resolution will be lookup in Prototype Chain of next
object in Scope Chain. So in theory that property name of VO is
harmful:

var x = true;
(function () {
  var __proto__ = {x : false};

  print(x); //?

})();

I can't see any implementation there print "false", but in theory can.
So it's depend by implementation of AO/VO and definitely i can't use
Identifiers like this.

1. Confuse readers
2. In some implementations can pollute Scope Chain. Of course that
point is only in theory.

dude, I do believe you are looking for this:

var x = true;
with({}){
(function () {
__proto__ = {x : false};
alert(x);
}());
}

which as you know, is different from this:

var x = true;
with({}){
(function (__proto__) {
alert(x);
}({x : false}));
}

however, I will never use that function as it was written, it was a
proof of concept, and nothing else, I am fine with instanceof
operator, I don't care about Commodore 64 ;-)

 

[David Mark]

Er, that's my line (not Michael's).

the fact the library is not updated with a clear link to the latest
version marked 2007/11/03 and released actually 2 or 3 years after
that one posted just to provide some old trick able to bring JS
features in IE4 does not tell you anything, right?

I was commenting on the code presented. As I said, I hoped it was very
old. If it was from 2004 (if I get your meaning), that is unfortunate.

What about being simply superficial and arrogant?

I don't care for it. Not a bit.

Do you write code
like that?

Not for almost a decade.

Can't wait to blame your first script ... uh wait, if it
was you, I am sure it is perfect, right? Ridiculous.

I didn't say anything about any of my scripts. So yes, ridiculous.

Anyway, this happens when you would like to share or help, and people
are ready to show off remarking silly things without investigating a
little bit (e.g. with the updated version) for a death project like
that, as death is IE4, still there for case studies like those Thomas
is doing with code that should be compatible with IE4.

I don't know what studies Thomas is doing, nor do I know what a "death
project" is. Is it anything like death metal?

@Thomas, I do believe you lack of sarcasm (C=64), while I have never

This is not a blog you know.

[...]

Finally, I will learn to quote,

Godspeed.

but too often this ML is just a show

It's not a mailing list either.

off place with zero outcome and few valid points ...

No, that's how insecure and/or ignorant people respond to valid
criticism (e.g. "aw, UR just showing off").

I do hope this ml
Again.

will grow up some day, so far I have read too often just "blame for
free to become famous" behaviors, annoying for both seniors and
juniors, useless for the community.

How about strongly criticizing where strong criticism is desperately
needed and (slowly) changing the world for the better? No good in your
book?

Hey, I saw a niche and I filled it. My intentions in dispensing such
criticism were always good, even if the pills seemed bitter to most
readers (which has brought a lot of undeserved negativity my way when
people should have concentrated on the messages). And making money off
it is just a welcome side effect. I've paid my dues (up to #6 all time
here last I checked). So sue me.

 

[Andrea Giammarchi]

P.S.

Boolean.isInstance = function (o) {
return !!o && o.constructor === this;
};

Boolean.isInstance(false); // false

maybe a generic isInstance, whoever will use it, should be more like:

Boolean.isInstance = function (o) {
return o != null && o.constructor === this;
};

Regards

 

[Thomas 'PointedEars' Lahn]

Andrea Giammarchi wrote:
So, how can you get confuse about that variable called __proto__?

(It is a function _argument_, not a variable.) How can you be naming
an function argument like that?

It can be harmful. Not only confused readers, but can pollute Scope
Chain in strict implementation of ECMA-262-3. If `__proto__` is mimic
of [[Prototype]] property, that can change Prototype Chain of VO. And
during Identifier Resolution will be lookup in Prototype Chain of next
object in Scope Chain. So in theory that property name of VO is
harmful:

var x = true;
(function () {
var __proto__ = {x : false};

print(x); //?

})();

I can't see any implementation there print "false", but in theory can.
So it's depend by implementation of AO/VO and definitely i can't use
Identifiers like this.

1. Confuse readers
2. In some implementations can pollute Scope Chain. Of course that
point is only in theory.

dude, I do believe you are looking for this:

var x = true;
with({}){
(function () {
__proto__ = {x : false};
alert(x);
}());
}

which as you know, is different from this:

var x = true;
with({}){
(function (__proto__) {
alert(x);
}({x : false}));
}

It is not much of a difference, though. You miss the point.

In both cases, if the Variable Object of the function execution context has
a __proto__ property, the value of that property can be changed with
potentially disastrous effects as the Variable Object is in the scope chain
of such an execution context. (Only if the VO does not have such a
property, you would be augmenting the Global Object with the property in
the first case, and the effects in the second case would be negligible.)

however, I will never use that function as it was written, it was a
proof of concept, and nothing else, I am fine with instanceof
operator, I don't care about Commodore 64 ;-)

You really want to take notice that the last original C64 shipped well
before JavaScript was even invented. That is, unless you want to further
make a fool of yourself here.

And ISTM you don't care about IE/MSHTML 5 either, or mobile applications
that might not implement all features of ES 3 in order to save memory.


PointedEars

 

[Andrea Giammarchi]

Er, that's my line (not Michael's).

sorry Michael

I was commenting on the code presented.  As I said, I hoped it was very
old.  If it was from 2004 (if I get your meaning), that is unfortunate.

I don't remember when I wrote that code, and it has always worked fine
for what I had to do by that time, sniffing included, a common
technique in 2004 or before.

I don't care for it.  Not a bit.  

so why bother ? just for fun ?
As I have said, all your answers are zero outcome. I am sure you have
lot of time to spend here, have fun then, please try to be more useful
for the community as well, don't keep the fun all for you. Cheers

P.S. which blog? which book? if you are superficial and you don't know
things, again, why bother? do you feel better after?

 

[Thomas 'PointedEars' Lahn]

P.S.

Boolean.isInstance = function (o) {
return !!o && o.constructor === this;
};

Boolean.isInstance(false); // false

maybe a generic isInstance, whoever will use it, should be more like:

Boolean.isInstance = function (o) {
return o != null && o.constructor === this;
};

OMG. Nobody, but nobody, wanted to present a generic isInstance() here; the
purpose was merely to show that methods of Function instances can be useful.

Nor would anybody knowledgable define or use Boolean.isInstance(). There's
`typeof', you know (so much backwards-compatible that it did not need to be
feature-tested even if that was possible). And please don't say "Boolean
instance" now, or I will *seriously* have to doubt your mental sanity.


PointedEars

 

[Andrea Giammarchi]

In both cases, if the Variable Object of the function execution context has
a __proto__ property, the value of that property can be changed with
potentially disastrous effects as the Variable Object is in the scope chain
of such an execution context.

var o = {};
with(o){
(function(__proto__){
return function () {
__proto__.a = 123;
};
}({})).call(o);
}

where is exactly the disaster? for a function created to test an
argument? it was NOT a generic funciton, it was a closure with a
specific aim

property, you would be augmenting the Global Object with the property in
the first case, and the effects in the second case would be negligible.)

example please? following same logic I have already used?

You really want to take notice that the last original C64 shipped well
before JavaScript was even invented.  That is, unless you want to further
make a fool of yourself here.

a fool of myself? how exactly? because I have said that IE4 for me is
Jurassic as C64 is? If this is a fool of myself, can I add the game
boy, Super Mario, my Olivetti M24 in the list as well? I like foolish
myself!!!

And ISTM you don't care about IE/MSHTML 5 either, or mobile applications
that might not implement all features of ES 3 in order to save memory.

In order to save what? Do you know what is my current job? Can you
enlighten us how that WRONG check could save memory for mobiles? And
please provide a list of mobile devices without instanceof support,
thanks, I will tell you how important JavaScript is for these devices.

Regards

 

[Andrea Giammarchi]

OMG.  Nobody, but nobody, wanted to present a generic isInstance() here; the
purpose was merely to show that methods of Function instances can be useful.

so, you have merely purpose, my 7 years old code can be blamed and a
proof of concept commented for 2 pages?

Nor would anybody knowledgable define or use Boolean.isInstance().  There's
`typeof', you know (so much backwards-compatible that it did not need to be
feature-tested even if that was possible).  And please don't say "Boolean
instance" now, or I will *seriously* have to doubt your mental sanity.

the constructor check is a natural fallback for typeof failure against
new Boolean ... I strongly doubt about your code, whatever you think
about my mental sanity.

Usually, but maybe it's just me, when I write some helper I write it
to optimize my code
e.g. less checks, less code, more stability, and portability.

Concepts such one function for all cases are daily basis stuff here, I
am glad you think typeof o && Func.isInstance is a better trick than
your SUPADUPA o.constructor === this with a pointless boolean cast
before, followed by a not .... performances and mobile devices
anybody?

Be serious please, at least be constant!

I stop this flame, have fun you guys.

Thanks Asen in any case for the only valid outcome came out of this
topic.

Reagrds

 

[David Mark]

sorry Michael


I don't remember when I wrote that code, and it has always worked fine
for what I had to do by that time, sniffing included, a common
technique in 2004 or before.

It was (and is) a common incompetent technique that was discarded by
professional (and conscientious) developers around the turn of the
century. At some point (hopefully very early) on the learning curve,
aspiring browser script authors realize the futility of relying on a
string of characters that is designed to deceive (e.g. browser
developers and end-users use it to deceive incompetent browser sniffing
scripts). Unfortunately, in 2010, we have this rogue's gallery of
"major" JS projects still making inferences based on this arbitrary (and
often deceitful) string:

- Dojo
- Prototype
- YUI
- Closure
- Cappuccino
- SproutCore

....and countless minors like the execrable "pragmatic" Base2 and many
non-entity throwaway scripts as well. The jQuery project has since
moved up one rung in the latter to object inferences, which are still
based on pigeonholing _today's_ observations.

http://www.jibbering.com/faq/faq_notes/not_browser_detect.html#bdOI

Of course, it took years of beating them over the head with some very
basic truths to move that mountain and I never did get a thank you note
from Resig.

So what is going on here? Are all of these people so stupid that they
can't understand the cited article? No. They are simply relatively new
to cross-browser scripting, which is a discipline that takes a long time
to master and is unlike virtually any other field of programming. Of
course, as programmers, they are arrogant, so they don't want to hear
that explanation.

The pitch for most of these projects is that browsers are wildly
different, which is not really true these days, but was indeed the case
when most of these people first started with browser scripting.

The other thing they are selling is that browsers change rapidly so you
need a team of "experts" to help you keep up. Again, this couldn't be
more false for most contexts these days. It is particularly false for
projects that need only concern themselves with major desktop browsers
(or at the extreme, a subset of their versions). Of course, most sites
on the Web don't have this luxury, but that hasn't stopped misguided Web
developers from deploying scripts that behave as if they do (e.g.
unreliable in anything but the very latest versions of a handful of
major desktop browsers in their default configurations). Somehow, some
way, this practice has come to be known as "saving time", despite the
fact that it virtually guarantees the exact opposite.

How has this happened? The developers of the scripts never learned
cross-browser scripting (or are talking their time about it anyway), so
they rely on outdated and misguided techniques like browser sniffing,
which necessarily results in scripts pinned to _today's_ observations
(what they refer to as "current" browsers). So they write lots of
branches based on what they _observe_ (typically failing to understand
the abstractions in play) and produce scripts that, at least
superficially, seem to work today. Okay, but getting back to their
pitch, if browsers change so fast and in so many different directions,
how can it be useful to write logic based on _today's_ observations?
That's where the whole movement vanishes in a puff of logic (or will
vanish in the future anyway). If you really need people to watch
browsers and write code (more like diaries) based on those observations
to keep up with browsers, then it stands to reason that the same people
will have to rewrite the same code indefinitely (and at an ever
increasing frequency as the number of browsers in use increases). So,
to anyone who can grasp basic logic, it should be clear that their
time-saving pitch is completely flawed. They are basically selling a
lifetime installment plan of rewrites, re-testing, re-deployment,
support headaches (support plans are often part of the scam), etc.
That's it.

Now, as code is not written, debugged and tested instantaneously, it
stands to reason that there will be gaps in synchronizing the
observations, resulting code and (what must be compulsory) browser
upgrades. These gaps will become wider as more browsers are introduced.
Many of these projects have attempted to rationalize their illogical
plans by claiming not to "care" about anything but the very latest
browsers, but unfortunately, the end-users aren't going to care what the
script authors care about. When your site starts having problems, they
will get upset, perhaps calling for support from (or summary execution
of) the owners, but more likely moving on to greener pastures. Often
the argument is made that it doesn't make sense to take any action until
complaints start rolling in, but that doesn't fly as most end-users
don't feel it is their duty to complain (and Web developers have earned
a justified reputation as less than amenable to criticism).

And then there are the pseudo-intellectuals who will focus on the _past_
and say that if that's how it has been done for all of these years, it
must be right (see Matt Kruse) and any voices to the contrary must be
mad, idealistic, naive, whatever. It's all bullshit.

Ah, but I digress...

so why bother ? just for fun ?

Why bother with what?

As I have said, all your answers are zero outcome.

As I have said, all your base are belong to us.

I am sure you have
lot of time to spend here,

If you knew Time as well as I do...

have fun then, please try to be more useful
for the community as well, don't keep the fun all for you. Cheers

Uh, cheers (I think).

P.S. which blog? which book? if you are superficial and you don't know
things, again, why bother? do you feel better after?

Since you ask, I feel a bit sick at the moment. You are dizzying.

 

[Andrea Giammarchi]

it was even kinda interesting before the end ...

As I have said, all your base are belong to us.

.... if you like to think it, please feel free to do it (btw, recycled
typo not even fun anymore ... did you play only that game?)

However, most web servers are still configured to rely into userAgent
strings to redirect pages, serve files, etc etc ... you talk as if you
can create the perfect script without updates etc etc ... most
developers simply assume what is just about programming: software MUST
be updated, nobody has been able to write a perfect software so
far .... uh wait, I mean you a part ...

Features detection is a partial solution, runtime methods/callbacks
compilation is another imperfect, still good, improvement.

It does not matter how abstract is your code in the most chaotic
panorama with at least 20 different VMs (client/server), whatever we
do, there could be a case where the feature detection, created
*observing* current browsers behavior, will simply fail because of new
behaviors, gotchas, inconsistencies, etc etc ... we don't have a
crystal ball, ... I mean, you a part ...

Anyway, surely features detection are a better answer, but at the same
time, if *you* decide to change your browser agent string, *you* are
the only one responsible for problems you are causing to yourself ...
isn't it? So who has the best real cases solution against code
compactness and loading time? (1000 features detections means lots of
"wasted" and precious milliseconds)

Unfortunately, still zero outcome, interesting reading tho, but no
effective bullet proof solution suggested or presented here. Maybe
because it's not that simple? Nice try tho

Regards

 

[Thomas 'PointedEars' Lahn]

var o = {};
with(o){
(function(__proto__){
return function () {
__proto__.a = 123;
};
}({})).call(o);
}

That is _not_ the code I had commented on, and it is unnecessarily complex
by comparison, but I'll bite.

where is exactly the disaster?

If either Variable Object had a __proto__ property that is not read-only,
accesses to `a' from within the function would be successful, because when
a function execution context is entered, a VO is created and augmented with
properties named for each named argument and variable. In particular,
accesses to `o' would not target the global variable `o' here but the
property `o' of the object referred to by __proto__ if it had one.

These would be the scope chain (horizontal) and prototype chains (vertical)
with regard to the returned function's execution context:

Ident. res.
VO (Global Object) <--- o <--- VO (local) <--- VO (local) <----------
| | | |
| impl.- v v v
`----------> Object.prototype __proto__ [[Prototype]]
dependent

Your original code, which I had commented on, --

var x = true;
with({}){
(function () {
__proto__ = {x : false};
alert(x);
}());
}

[...]

var x = true;
with({}){
(function (__proto__) {
alert(x);
}({x : false}));
}

-- would have created the following scope chain and prototype chains
instead:

Ident. res.
VO (Global Object) <--- o <--- VO (local) <--- VO (local) <----------
| | | |
| impl.- v v v
`----------> Object.prototype [[Prototype]] __proto__
dependent

So you see that your forging your code here does not make a considerable
difference to the situation described above.

for a function created to test an argument? it was NOT a generic
funciton, it was a closure with a specific aim

An aim missed at that. Your introducting `with' here also does not make
sense: `with' appends the object referred to by its parameter to the
*front* of the scope chain; that is irrelevant with regard to the VO of the
function execution context.

example please? following same logic I have already used?

An example of what? (You have only quoted a part of the statement.)

In order to save what?

Memory. (Can't you read?)

Do you know what is my current job?

No. (Is it relevant?)

Can you enlighten us how that WRONG check could save memory for mobiles?

Can you reword this question so that it make sense?

And please provide a list of mobile devices without instanceof support,
thanks, I will tell you how important JavaScript is for these devices.

I have no list, but I have read here from people I trust they know what
they are saying and doing (so not you) that there are relevant mobile
devices that do not implement all features of ES 3, in order to save
memory.


PointedEars

 

[David Mark]

it was even kinda interesting before the end ...

Speak for yourself.

... if you like to think it, please feel free to do it (btw, recycled
typo not even fun anymore ... did you play only that game?)

What game?

However, most web servers are still configured to rely into userAgent
strings to redirect pages, serve files, etc etc ...

Like hell they are. Server side sniffing is not in widespread use,
except by the most incompetent of server administrators (who should
really be digging ditches instead).

you talk as if you
can create the perfect script without updates etc etc

That's a common childish reaction. The point is that there is a _huge_
difference between nearly at the pinnacle and nearly at the pits. Do
you understand that scripts may sometimes need updates, despite the best
intentions/practices of the author? Granted, My Library must seem like
magic compared to most. On the other end of the spectrum are
scripts that are _designed_ to fail (i.e. they are written based on
_today's_ observations for agents that are guaranteed to change, at
least in some ways, in the future). Granted, they don't change as much
or as radically as they used to, so there would seem very little
justification for relying on script written by such misguided people.

... most
developers simply assume what is just about programming: software MUST
be updated, nobody has been able to write a perfect software so
far ....

The "nobody's perfect" excuse does not really apply to UA sniffing in
browser scripts. That's like losing a basketball game 103-0 and
claiming some sort of moral victory that you didn't score negative
points. Again, perfection is at one end of the spectrum and the pits at
the other. Sound practices will produce scripts that can approach
perfection, poor practices all but guarantee the pits.

uh wait, I mean you a part ...

Wait for what?

Features detection is a partial solution, runtime methods/callbacks
compilation is another imperfect, still good, improvement.

Feature detection and testing are sound practices. One-offs functions
is a useful technique.

It does not matter how abstract is your code in the most chaotic
panorama with at least 20 different VMs (client/server),

Wow! 20 different ones! So, uh I guess you won't want to write 20
different branches based on your observation of each because then when
one of them changes...

whatever we
do, there could be a case where the feature detection, created
*observing* current browsers behavior, will simply fail because of new
behaviors, gotchas, inconsistencies, etc etc ... we don't have a
crystal ball, ... I mean, you a part ...

Again, that is not an argument (though it has been masquerading as one
for years). Just because sound practices are not infallible does not
justify poor practices. If you install smoke detectors and your house
ends up burning down anyway, it doesn't stand to reason that you should
try something inferior (like a barking dog) for your new house.

Anyway, surely features detection are a better answer, but at the same
time, if *you* decide to change your browser agent string, *you* are
the only one responsible for problems you are causing to yourself ...

And that one. You still don't get it. The UA string is designed to
deceive by the _browser developers_, as well as sophisticated _end
users_. They are trying to get past incompetent scripts. If your
scripts sniff this string in the bizarre assumption that it is going to
be usable to determine the features present in the environment, then you
the author are to blame for writing an incompetent script. You are part
of the problem and people (developers and users alike) change the UA
string to try to solve that problem.

isn't it? So who has the best real cases solution against code
compactness and loading time? (1000 features detections means lots of
"wasted" and precious milliseconds)

That argument is years out of date. There is no rule that says feature
detection must take place on load. It can (and often is) done on load,
but can also be done on the first call of a function (the so-called lazy
pattern). And competently written scripts don't repeat feature tests
(it's one and done), whereas incompetently written scripts invariably
check the UA string (a property of a host object, just as feature
detection often checks) every time through.

Unfortunately, still zero outcome, interesting reading tho, but no
effective bullet proof solution suggested or presented here. Maybe
because it's not that simple? Nice try tho

All I can ask is where you have been for the last two and a half years
or so (that's roughly how long I have been in here saying the exact same
thing, posting myriad examples, explaining and re-explaining the same
concepts, etc.) I just repeated it in abridged form for you here. Your
defensive reaction (which is very typical for neophytes) speaks volumes.
You've got a long way to go.

 

[Thomas 'PointedEars' Lahn]

so, you have merely purpose, my 7 years old code can be blamed and a
proof of concept commented for 2 pages?

I am getting the distinct idea that you have been trying to waste my time
all along.

the constructor check is a natural fallback for typeof failure against
new Boolean ...

Nobody sane uses `new Boolean', though.

I strongly doubt about your code, whatever you think
about my mental sanity.

I am pretty sure about it now.

Usually, but maybe it's just me, when I write some helper I write it
to optimize my code
e.g. less checks, less code, more stability, and portability.

Which is why *you* would use a isInstance() instead of `typeof' ...

Get better.

Concepts such one function for all cases are daily basis stuff here, I
am glad you think typeof o && Func.isInstance is a better trick than

^^^^^^^^^^^^^^^^^^^^^^^^^^^
I have never suggested this.

your SUPADUPA o.constructor === this with a pointless boolean cast
before, followed by a not .... performances and mobile devices
anybody?

You are starting to write in gibberish. ISTM you should take your pills
now.

Thanks Asen in any case for the only valid outcome came out of this
topic.

Not all arguments that you are incapable to comprehend are not valid.


PointedEars