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

[Thomas 'PointedEars' Lahn]

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

That is _not_ the same code that 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,
subsequent 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 each variable.
In particular, subsequent accesses to `o' would not target the global
variable `o' but the property `o' of the object referred to by `__proto__'
if it had one.

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

(7) (5) (3) Ident. res.
VO (Global Object) <--- o <--- VO (local) <--- VO (local) <----------
| | | | (1)
| (8) (6) | (4) | Ident. res. | (2)
| impl.- v v v
`----------> Object.prototype __proto__ [[Prototype]]
dependent

By comparison, your original code, which I had commented on, --

-- would create the following scope chain and prototype chains then:

(7) (5) (3) Ident. res.
VO (Global Object) <--- o <--- VO (local) <--- VO (local) <----------
| | | | (1)
| (8) (6) | (4) | Ident. res. | (2)
| impl.- v v v
`----------> Object.prototype [[Prototype]] __proto__
dependent

So you see that your forging your code here does not make much of a
difference with regard 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
either 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 to save memory.


PointedEars

 

[Andrea Giammarchi]

 You've got a long way to go.

dude, I am sorry, but I have never learned anything new from your
posts here, while your vision is sandboxed in your arrogance. You are
zero outcome granted, you reply more childish than you think I am, and
unfortunately for you, you are not able to consider other points of
view.

Features detection as "one shot" are precious milliseconds, libraries
are rarely loaded "on load" and since there is no library which aim is
to provide only features detections once and for everybody else (we
all rely in our feature detection) the total amount of wasted
milliseconds in a classic environment where scripts must interoperate
and usually are more than one, could be relevant, it depends which
hardware you are dealing with.

The lazy pattern we all know and surely not because of you, able or
not to create a "one off" specific function, has it cons as well
because it inevitably requires more code and more logic (more stuff to
maintain as well then) and again, while performances could be best
ever, the script loading time will be improved. Now, which one is more
important, more than 50ms for each download due script size or a
runtime check able to produce the same output in a way that does not
mean anything being an operation performed in 0.05 ms?

It's all about requirements, but you are so professional and religious
about what you think that as I have said your knowledge is sandboxed.

Multiple browser sniffing? I have rarely seen such technique, the
moment you need to know if the MSIE string is there in a proper order,
checking out those agents with MSIE compatible, is the moment you
create a variable. The moment you need these checks all over the
place, is the moment you have an object with these info. The moment a
new browser will come out changing UA, you'll have only one single
place to update with these changes or a single place to improve. The
fact IT changes every bloody day means you don't have the best answer,
you can only assume you have these answers until somebody else will
come out with a better option for different reasons and that day
libraries developers will be flexible enough to understand if for they
requirements that new solution is worth it.

This is what I think is a good developer, other people with the truth
in their hand and "everything else is bullshit" are the only one with
a long way to go.

Regards

 

[Andrea Giammarchi]

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

this is all about this group, people writing stuff convinced to be the
only one with valid points.

Again, I have simply improved for scalability and portability your
silly suggestion, you could have said "sure, thanks", you ended up
talking about my mental sanity, pills, and the fact my function is
simply more robust than your one but you'll never admit it.

I love developers, they are so funny!

Regards

 

[Andrea Giammarchi]

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

indeed, bla bla bla, and no concrete side effect/demonstration about
my simple proof of concept with simply a logical name for what it is
(it represents the intent of the argument). Again, read carefully,
PROOF OF CONCEPT, I can explain what it means if you want, just let me
know.

Nobody sane uses `new Boolean', though.

mate, I write robust code, I don't make silly assumptions

Memory.  (Can't you read?)

please provide numbers and tests and stop this attempt to climb
mirrors

Can you reword this question so that it make sense?

as already said

I have no list

oh, really? so what are you talking about?

but I have read here from people I trust they know what
they are saying and doing

same is for me, I know what say and what I do, I am sorry you don't
trust me

that there are relevant mobile
devices that do not implement all features of ES 3 to save memory.

is instanceof or Object.prototype.isprototypeOf part of this? because
you keep contradicting your self, changing topic, escaping from
examples and concrete facts.

Let's summarize here ... I have said, and other before me, instanceof
is all you need, eventually isPrototypeOf, which makes even more sense
since constructor does notmean *anything* for an instance, it's just a
property able to tell you *nothing* about it indeed.

Your nonsense isInstance function, could be eventually used as
fallback for browser without isPorototypeOf support, using my version,
since your one is less robust (I don't have to demonstrate it again I
hope)

Regards

 

[David Mark]

dude, I am sorry, but I have never learned anything new from your
posts here,

Yes, the latter implies the former. You might start with rewriting
PureDom as My Library beats it 4:1 in WebKit, 3:1 in Opera, etc. Not
too pure is it?

As for the rest, I really have a hard time understanding you. I take it
your point is that I am bad and you are good. Well, we are all entitled
to our opinions (even when they are plainly wrong).

 

[Michael Haufe (\TNO\)]

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 to save memory.

Would this be WMLScript?

 

[David Mark]

Zero Wing. Your quote.

I'll take your word for it. I simply know it as a famous malaprop.

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).

I'd like to believe that, but the default Apache config file for SSL
vhosts in Debian contains this passage:

# SSL Protocol Adjustments:
[...]
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for
# this. Similarly, one has to force some clients to use HTTP/1.0 to
# workaround their broken HTTP/1.1 implementation. Use variables
# "downgrade-1.0" and "force-response-1.0" for this.
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

Hopefully the author of that is now in a ditch somewhere (digging it I
mean).

Looks rather heavy handed...
"Back to the '90s, Opera! Here's some HTTP/1.0 for you."

And, of course, there is no guarantee as to which browsers will receive
that treatment. Apparently the author has never heard of proxy servers
(among other things).

I'm not an expert on how well SSL is supported in legacy user agents,
but feature testing a client isn't as easy on the server as it is in
JavaScript - the request header's all you've got to work on.

But the UA header is simply an arbitrary (and optional) string of
characters with no correlation to SSL at all.

 

[Thomas 'PointedEars' Lahn]

Would this be WMLScript?

Unlikely. If you knew you would be writing a WAP application, you would
skip those features not in WMLScript to begin with. And wasn't WAP dead
already?

I am talking about scripts and mobile devices that, e.g. would run fine
if you did not use instanceof when not necessary, and hid try-catch from
their compilers. And I still have no list, so please stop asking.


PointedEars

 

[Thomas 'PointedEars' Lahn]

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).

I'd like to believe that, but the default Apache config file for SSL
vhosts in Debian contains this passage:

# SSL Protocol Adjustments:
[...]
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for
# this. Similarly, one has to force some clients to use HTTP/1.0 to
# workaround their broken HTTP/1.1 implementation. Use variables
# "downgrade-1.0" and "force-response-1.0" for this.
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

Looks rather heavy handed...
"Back to the '90s, Opera! Here's some HTTP/1.0 for you."

It (/etc/apache2/sites-available/default-ssl) has been changed to

| BrowserMatch "MSIE [2-6]" \
| nokeepalive ssl-unclean-shutdown \
| downgrade-1.0 force-response-1.0
| # MSIE 7 and newer should be able to use keepalive
| BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

in apache2.2-common 2.2.15-2.

I'm not an expert on how well SSL is supported in legacy user agents,
but feature testing a client isn't as easy on the server as it is in
JavaScript - the request header's all you've got to work on.

ACK


PointedEars

 

[David Mark]

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).

I'd like to believe that, but the default Apache config file for SSL
vhosts in Debian contains this passage:

# SSL Protocol Adjustments:
[...]
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for
# this. Similarly, one has to force some clients to use HTTP/1.0 to
# workaround their broken HTTP/1.1 implementation. Use variables
# "downgrade-1.0" and "force-response-1.0" for this.
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

Looks rather heavy handed...
"Back to the '90s, Opera! Here's some HTTP/1.0 for you."

It (/etc/apache2/sites-available/default-ssl) has been changed to

| BrowserMatch "MSIE [2-6]" \
| nokeepalive ssl-unclean-shutdown \
| downgrade-1.0 force-response-1.0
| # MSIE 7 and newer should be able to use keepalive
| BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

in apache2.2-common 2.2.15-2.

I'm not an expert on how well SSL is supported in legacy user agents,
but feature testing a client isn't as easy on the server as it is in
JavaScript - the request header's all you've got to work on.

ACK

Can you elaborate on that ACK? I can't imagine you are advocating that
a Web server should change gears based on the UA header. (?)

 

[Thomas 'PointedEars' Lahn]

David Mark wrote:
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).
I'd like to believe that, but the default Apache config file for SSL
vhosts in Debian contains this passage:

# SSL Protocol Adjustments:
[...]
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for
# this. Similarly, one has to force some clients to use HTTP/1.0 to
# workaround their broken HTTP/1.1 implementation. Use variables
# "downgrade-1.0" and "force-response-1.0" for this.
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

Looks rather heavy handed...
"Back to the '90s, Opera! Here's some HTTP/1.0 for you."

It (/etc/apache2/sites-available/default-ssl) has been changed to

| BrowserMatch "MSIE [2-6]" \
| nokeepalive ssl-unclean-shutdown \
| downgrade-1.0 force-response-1.0
| # MSIE 7 and newer should be able to use keepalive
| BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

in apache2.2-common 2.2.15-2.

I'm not an expert on how well SSL is supported in legacy user agents,
but feature testing a client isn't as easy on the server as it is in
JavaScript - the request header's all you've got to work on.

ACK

Can you elaborate on that ACK? I can't imagine you are advocating that
a Web server should change gears based on the UA header. (?)

I was ACKnowledging the fact that "feature testing a client isn't as easy
on the server as it is in JavaScript - the request header's all you've got
to work on."

However, the logical conclusion is: *If* using a header field value is the
*only* way to satisfy compatibility with a client program deemed important
(which is not going to be fixed), then, and *only* then, it is acceptable
to do so. Logic dictates that one shall accept the *probability* of false
positives (where basic functionality would still be guaranteed) when faced
with the alternative of *certain* dysfunctionality. The expression above
should be further refined, though, as there are still too many false
positives with it (Opera 5.02 to 8.0 for Windows being a distinct
possibility, for example).


PointedEars

 

[David Mark]

Stefan Weiss wrote:
David Mark wrote:
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).
I'd like to believe that, but the default Apache config file for SSL
vhosts in Debian contains this passage:

# SSL Protocol Adjustments:
[...]
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for
# this. Similarly, one has to force some clients to use HTTP/1.0 to
# workaround their broken HTTP/1.1 implementation. Use variables
# "downgrade-1.0" and "force-response-1.0" for this.
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

Looks rather heavy handed...
"Back to the '90s, Opera! Here's some HTTP/1.0 for you."
It (/etc/apache2/sites-available/default-ssl) has been changed to

| BrowserMatch "MSIE [2-6]" \
| nokeepalive ssl-unclean-shutdown \
| downgrade-1.0 force-response-1.0
| # MSIE 7 and newer should be able to use keepalive
| BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

in apache2.2-common 2.2.15-2.

I'm not an expert on how well SSL is supported in legacy user agents,
but feature testing a client isn't as easy on the server as it is in
JavaScript - the request header's all you've got to work on.
ACK

Can you elaborate on that ACK? I can't imagine you are advocating that
a Web server should change gears based on the UA header. (?)

I was ACKnowledging the fact that "feature testing a client isn't as easy
on the server as it is in JavaScript - the request header's all you've got
to work on."

Yes, that's certainly true.

However, the logical conclusion is: *If* using a header field value is the
*only* way to satisfy compatibility with a client program deemed important
(which is not going to be fixed), then, and *only* then, it is acceptable
to do so.

Yes. Iff.

Logic dictates that one shall accept the *probability* of false
positives (where basic functionality would still be guaranteed) when faced
with the alternative of *certain* dysfunctionality. The expression above
should be further refined, though, as there are still too many false
positives with it (Opera 5.02 to 8.0 for Windows being a distinct
possibility, for example).

No question there. There's a lot of possibilities for false positives
as it sits and *certainly* there are going to be lots of false positives
with this approach, no matter how "refined" the sniffing.

 

[David Mark]

Thomas 'PointedEars' Lahn wrote:
It (/etc/apache2/sites-available/default-ssl) has been changed to

| BrowserMatch "MSIE [2-6]" \
| nokeepalive ssl-unclean-shutdown \
| downgrade-1.0 force-response-1.0
| # MSIE 7 and newer should be able to use keepalive
| BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

in apache2.2-common 2.2.15-2.

[...]
The expression above should be further refined, though, as there are
still too many false positives with it (Opera 5.02 to 8.0 for Windows
being a distinct possibility, for example).

Or even more recent versions. In a collection of user agent strings
(which is admittedly over a year old), I found

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; en) Opera 9.51

That would definitively be a false positive, and it's very likely that
newer Opera versions are also affected. My sympathy is somewhat limited,
though... that's what you get for masquerading as Mozilla and MSIE, when
you're neither.

I have all the sympathy in the world for them. Opera 9-10 represent
competent, standards-based browsers, yet are constantly running into
exceptions on the Web (e.g. Google Adsense, MSDN, eBay and other huge
sites that can't seem to buy a decent Web developer). They had no
choice but to put on such a masquerade due to incompetently written
scripts (the authors of which usually cop-out by blaming the
users/browsers). It's the same reason that IE had no choice but to
masquerade as Mozilla back during the "browser wars" of the late 90's.
It is the authors of such scripts (and the site owners dumb enough to
trust them) that I have no sympathy for. To this day, they write and
deploy scripts that sniff the UA string, excluding users for no reason
(other than their own incompetence) and truly seem to believe that it is
the evil users/browsers that are making life hard for _them_. Talk to
these people and terms like "pragmatic" and "real world" crop up
immediately (and they translate to "idiotic" and "fantasy world" in my
book).

Anyway, the Apache BrowserMatch directive should be
probably be refined to exclude Opera. I'll submit a patch if I can find
the time. Does anybody know if there are Opera versions which _do_ have
the same SSL problems as the old IEs?

And finally, just for fun, when I grepped the user agent list for
"opera", I stumbled across this gem:

mozilla/3.0b5pre with grabage in ua is neither Opera/9.20 nor msie7.0
nor Safari or any other browser(it is not on any version of Windows
nor NT 6.0 nor on a mac but on linux; U;language hidden (en, en-us,
it, es, de, nl, fr, fi ???) hahahahahahahhaahh )

So much for trusting the UA string

So much indeed.

 

[David Mark]

On 31/03/10 01:11, Thomas 'PointedEars' Lahn wrote:
Thomas 'PointedEars' Lahn wrote:
It (/etc/apache2/sites-available/default-ssl) has been changed to

| BrowserMatch "MSIE [2-6]" \
| nokeepalive ssl-unclean-shutdown \
| downgrade-1.0 force-response-1.0
| # MSIE 7 and newer should be able to use keepalive
| BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

in apache2.2-common 2.2.15-2.
[...]
The expression above should be further refined, though, as there are
still too many false positives with it (Opera 5.02 to 8.0 for Windows
being a distinct possibility, for example).
Or even more recent versions. In a collection of user agent strings
(which is admittedly over a year old), I found

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; en) Opera 9.51

That would definitively be a false positive, and it's very likely that
newer Opera versions are also affected. My sympathy is somewhat limited,
though... that's what you get for masquerading as Mozilla and MSIE, when
you're neither.

I have all the sympathy in the world for them. Opera 9-10 represent
competent, standards-based browsers, yet are constantly running into
exceptions on the Web (e.g. Google Adsense, MSDN, eBay and other huge
sites that can't seem to buy a decent Web developer). They had no
choice but to put on such a masquerade due to incompetently written
scripts (the authors of which usually cop-out by blaming the
users/browsers). It's the same reason that IE had no choice but to
masquerade as Mozilla back during the "browser wars" of the late 90's.
It is the authors of such scripts (and the site owners dumb enough to
trust them) that I have no sympathy for. To this day, they write and
deploy scripts that sniff the UA string, excluding users for no reason
(other than their own incompetence) and truly seem to believe that it is
the evil users/browsers that are making life hard for _them_. Talk to
these people and terms like "pragmatic" and "real world" crop up
immediately (and they translate to "idiotic" and "fantasy world" in my
book).

I would call this UA charade the prototype of a pragmatic solution.

Yes, for the browser developers. But that's real pragmatism, not the
fantasy pragmatism espoused by the people are actually creating the
problem that requires the solution.

The
browsers are pretending to be something they're not, and they are
specifically targetting badly written sniffer scripts. That's something
you in particular would never condone if it were done in JS.

I don't quite see the connection. They are doing it to stop badly
written scripts from excluding them (and users do the same thing).
Regardless of pretensions, it's a fact that the UA string has been
rendered meaningless as a result. Ten years later and the "pragmatic'
script authors are still making the same stupid mistakes.

It would be
like... defining a global jQuery object in MyLibrary, and adding
wrappers for their core methods -- just kidding!

Don't laugh. There are plenty of ill-conceived libraries out there that
do that. I guess they really think jQuery "just works", when it has
been demonstrated that it can't even do simple queries consistently from
one browser (or jQuery version) to the next. Without the queries (which
are clearly to be avoided), what's left to wrap?

Don't get me wrong, I think Opera is an outstanding piece of software,
and I use it frequently.

I do too, despite the constant script exceptions (makes browsing quite
an adventure though). But you can bet that if I have to fill in a form
or something else where a bad script could waste my time, I switch to
Chrome or FF.

It comes with some very useful tools for
developers, and it's more than adequate as a day-to-day browser.

I've never tried their developer tools other than the good old error
console (and I curse every time I accidentally open up some strange new
pane that I don't want). Dragonfly right? The opening animation is
nice anyway.

I even
like the company's attitude. The only criticism I have is their lack of
openness (as in opening their bug tracker and their source code), but
that's just the way I tick. YMMV.

I couldn't care less what they do with their source code or bug tracker.

I do understand why they did the UA trick, of course. It was a sensible
business decision at the time, and in the long run, it has probably done
more good than harm.

IE started us down that road. It would have been good for developers
too as it never would have made sense to try to write scripts based on
the UA string (even if all were 100% genuine), but the incompetents
decided to forge ahead with such idiocy, despite the fact that the UA
strings are mostly used to deceive. Logic based on lies. Imagine.

At the very least, they're still in business, which
I think is a good thing for the web ecosystem as a whole.

I have no idea.

But it's still
a dirty hack, and being mistaken for an Internet Explorer when you're
technically superior is one of the drawbacks.

Tons of things are mistaken for IE. I remember arguing with John Resig
about that a couple of years back. Apparently he hadn't heard.

To put it another way: if you go out wearing a wig and a fancy dress,
don't be surprised when that smelly wasted bum in the corner of the pub
makes a pass at you

It's more like if you must wear a disguise because incompetent bouncers
only let certain types in, don't be surprised if you get in and have a
great time.