.match(...) awkwardness
Hans-Georg Michna
of the regular expressions in JavaScript? Here's the example:
var page = location.search.match(/(?:\?|&)(?:page=)(\d+)/);
if (page) page = +page[1]; else page = 0;
All this does is look for a page= parameter, followed by a
number, in the location.search string. The problem arises from
the fact that JavaScript regular expressions have no look-behind
and no way to skip certain strings, i.e. require them, but not
match them into the output. That's why I have been unable to
come up with a single statement that picks the number out of the
search string.
The first-glance solution:
var page = +location.search.match(/(?:\?|&)(?:page=)(\d+)/)[1];
fails if the page parameter is not there (indicating page 0).
Can anybody think of some neat trick to solve this problem with
as little code as possible? Am I overlooking some capability of
regular expressions?
Hans-Georg
kangax
> Does anybody have a good idea how to deal with the limitations
> of the regular expressions in JavaScript? Here's the example:
>
> var page = location.search.match(/(?:\?|&)(?:page=)(\d+)/);
I would use arguably more readable [?&] to match "?" or "&". Also, why
make a non-capturing group out of "page="?
> if (page) page = +page[1]; else page = 0;
Using `page` as a variable name for what really is a match seems confusing.
>
> All this does is look for a page= parameter, followed by a
> number, in the location.search string. The problem arises from
> the fact that JavaScript regular expressions have no look-behind
> and no way to skip certain strings, i.e. require them, but not
> match them into the output. That's why I have been unable to
> come up with a single statement that picks the number out of the
> search string.
>
> The first-glance solution:
>
> var page = +location.search.match(/(?:\?|&)(?:page=)(\d+)/)[1];
>
> fails if the page parameter is not there (indicating page 0).
>
> Can anybody think of some neat trick to solve this problem with
> as little code as possible? Am I overlooking some capability of
> regular expressions?
I would do something like this (untested):
var match = window.location.search.match(/[?&]page=(\d+)/),
page = 0; // default page
if (match && match[1]) {
page = parseInt(match[1], 10) || 0; // NaN, 0 -> 0
}
This should make "page=", "page=foo", "page=0" and missing param all
default to `0`. Anything else that can be parsed with `parseInt(...,
10)` as a number would end up as that number.
The downside here is repeating (and so less maintainable) 0 � default
value. You could work around it by introducing another variable:
var match = window.location.search.match(/[?&]page=(\d+)/),
defaultPage = 0,
page = defaultPage;
// or slightly shorter but usually more confusing
// page, defaultPage = page = 0;
if (match && match[1]) {
page = parseInt(match[1], 10) || defaultPage;
}
--
kangax
Lasse Reichstein Nielsen
> Does anybody have a good idea how to deal with the limitations
> of the regular expressions in JavaScript?
Don't use regular expressions?
> Here's the example:
>
> var page = location.search.match(/(?:\?|&)(?:page=)(\d+)/);
> if (page) page = +page[1]; else page = 0;
>
> All this does is look for a page= parameter, followed by a
> number, in the location.search string. The problem arises from
> the fact that JavaScript regular expressions have no look-behind
> and no way to skip certain strings, i.e. require them, but not
> match them into the output.
That can be done with look-ahead.
> That's why I have been unable to come up with a single statement
> that picks the number out of the search string.
>
> The first-glance solution:
>
> var page = +location.search.match(/(?:\?|&)(?:page=)(\d+)/)[1];
>
> fails if the page parameter is not there (indicating page 0).
*Why* a single expression? You do two things: Match something and
pick a part of the match out. Why not use two separate statements
for that?
> Can anybody think of some neat trick to solve this problem with
> as little code as possible?
Code density is not a good goal. It's usually inversely proportional
to readability.
> Am I overlooking some capability of regular expressions?
Not that I can see, but how about:
var page = +((/[?&]page=(\d+)/.exec(location.search)||[,0])[1]
But it's pretty much unreadable. Don't do this to the guy who must
support your code when you are gone! :)
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'
Lasse Reichstein Nielsen
> var page = +((/[?&]page=(\d+)/.exec(location.search)||[,0])[1]
Sorry, typo. Should be:
var page = +(/[?&]page=(\d+)/.exec(location.search)||[,0])[1]
Thomas 'PointedEars' Lahn
> Hans-Georg Michna <hans-georgN...@michna.com> writes:
>> That's why I have been unable to come up with a single statement
>> that picks the number out of the search string.
>>
>> The first-glance solution:
>>
>> var page = +location.search.match(/(?:\?|&)(?:page=)(\d+)/)[1];
>>
>> fails if the page parameter is not there (indicating page 0).
>
> *Why* a single expression? You do two things: Match something and
> pick a part of the match out. Why not use two separate statements
> for that?
Runtime efficiency?
>> Can anybody think of some neat trick to solve this problem with
>> as little code as possible?
>
> Code density is not a good goal. It's usually inversely proportional
> to readability.
But usually proportial to runtime efficiency.
>> Am I overlooking some capability of regular expressions?
>
> Not that I can see, but how about:
[Correction from <news:1vi8hr...@gmail.com>]
> var page = +(/[?&]page=(\d+)/.exec(location.search)||[,0])[1]
>
> But it's pretty much unreadable.
Some spaces
in some places
work like kisses
for the misses.
var page = +(/[?&]page=(\d+)/.exec(window.location.search) || [, 0])[1];
> Don't do this to the guy who must
> support your code when you are gone! :)
The guy replacing me must be at least as proficient or something went
seriously wrong in the HR department.
However, I prefer the backwards-compatible *and* standards-compliant
approach:
var page = +(/[?&]page=(\d+)/.exec(document.URL) || [, 0])[1];
Potentially less efficient:
var page = +(document.URL.match(/[?&]page=(\d+)/) || [, 0])[1];
Another potentially less efficient variant (paying an `undefined' access
and an OR for saving an assignment) but where the default value might be
more obvious to the maintainer:
var page = +(/[?&]page=(\d+)/.exec(document.URL) || [])[1] || 0;
or
var page = +(document.URL.match(/[?&]page=(\d+)/) || [])[1] || 0;
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
kangax
> Lasse Reichstein Nielsen wrote:
[...]
> var page = +(/[?&]page=(\d+)/.exec(window.location.search) || [, 0])[1];
> However, I prefer the backwards-compatible *and* standards-compliant
> approach:
>
> var page = +(/[?&]page=(\d+)/.exec(document.URL) || [, 0])[1];
Is `document` a property of Global Object now?
[...]
--
kangax
Thomas 'PointedEars' Lahn
Possible.
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)
kangax
> kangax wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Lasse Reichstein Nielsen wrote:
>> [...]
>>> var page = +(/[?&]page=(\d+)/.exec(window.location.search) || [,
>>> 0])[1];
>> [...]
>>> However, I prefer the backwards-compatible *and* standards-compliant
>>> approach:
>>>
>>> var page = +(/[?&]page=(\d+)/.exec(document.URL) || [, 0])[1];
>> ^^^^^^^^
>> Is `document` a property of Global Object now?
>
> Possible.
But `alert` is not, huh?
--
kangax
David Mark
Possibly. But I don't understand why Thomas is being cryptic. I
would much prefer to see window.document.URL, as well as window.alert.
But regardless, I've always used window.location.href. Clearly it is
not a formally defined standard, but then neither is
window.alert. ;) I suppose an argument can be made for document.URL.
And I agree with Lasse that the one-liner is poor form and such code
should be avoided. It's not really about the proficiency of the next
coder (as Thomas suggested). It's about the time it takes to read and
digest the code weighed against potential performance benefits
(virtually nil for this example).
Furthermore, the very idea of conjuring such an array to shoehorn
everything into one line is silly (almost jQuery-ish). I thought
about it, came up with a similar solution and did not post it because
it offended my sensibilities. The solution is to use two lines.
Thomas 'PointedEars' Lahn
Not as often, apparently.
Thomas 'PointedEars' Lahn
> kangax wrote:
>> Thomas 'PointedEars' Lahn wrote:
>> > kangax wrote:
>> >> Thomas 'PointedEars' Lahn wrote:
>> >>> Lasse Reichstein Nielsen wrote:
>> >> [...]
>> >>> var page = +(/[?&]page=(\d+)/.exec(window.location.search) || [,
>> >>> 0])[1];
>> >> [...]
>> >>> However, I prefer the backwards-compatible *and* standards-compliant
>> >>> approach:
>> >>>
>> >>> var page = +(/[?&]page=(\d+)/.exec(document.URL) || [, 0])[1];
>> >> ^^^^^^^^
>> >> Is `document` a property of Global Object now?
>> >
>> > Possible.
>> But `alert` is not, huh?
>
> Possibly. But I don't understand why Thomas is being cryptic. I
> would much prefer to see window.document.URL, as well as window.alert.
`document' is an attribute of the `AbstractView' interface of the W3C DOM
Level 2 Views Specification. Since that attribute, implemented as a
property of the Global Object has served as a starting point for the DOM
ever since (JavaScript 1.0 and its forks), it stands to reason that this
interface is implemented by the ECMAScript Global Object or by an object in
the scope chain in the targeted environments. We have not observed any
client-side DOM implementation that do not support it.
By contrast, `alert' is a fully proprietary property of Window instances as
defined from JavaScript 1.0 to 1.3, MSHTML 1.0+, and the earliest Gecko
versions, not to mention the earliest supporting Opera and KHTML versions.
It has not been defined under "Top-Level Properties and Functions" in the
Core JavaScript 1.3 Reference. It is a method that is deprecated from a
usability viewpoint. It does not stand to reason that the Global Object or
an object in the scope chain provides it. We have already observed at
least one client-side DOM implementation that does not support it.
> But regardless, I've always used window.location.href. Clearly it is
> not a formally defined standard, but then neither is
> window.alert. ;)
Non sequitur. The proprietary nature of `window.alert' does not alleviate
the error-proneness of the equally proprietary `window.location.href' as
compared to `document.URL'.
> I suppose an argument can be made for document.URL.
BTDT.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Thomas 'PointedEars' Lahn
> By contrast, `alert' [...] has not been defined under "Top-Level
> Properties and Functions" in the Core JavaScript 1.3 Reference.
That is, _Client-side_ JavaScript 1.3 Reference. (The first Core JavaScript
Reference was that of version 1.4, implemented only server-side by Netscape
Enterprise Server 4.0-compatible Web servers.)
<http://PointedEars.de/es-matrix#javascript>
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
David Mark
wrote:
Fair enough. ISTM that this.document (in the Global context) would
then be preferable to window.document.
>
> By contrast, `alert' is a fully proprietary property of Window instances as
> defined from JavaScript 1.0 to 1.3, MSHTML 1.0+, and the earliest Gecko
> versions, not to mention the earliest supporting Opera and KHTML versions.
> It has not been defined under "Top-Level Properties and Functions" in the
> Core JavaScript 1.3 Reference. It is a method that is deprecated from a
> usability viewpoint.
Clearly.
> It does not stand to reason that the Global Object or
> an object in the scope chain provides it. We have already observed at
> least one client-side DOM implementation that does not support it.
Yes, window.alert makes the most sense (for browsers).
>
> > But regardless, I've always used window.location.href. Clearly it is
> > not a formally defined standard, but then neither is
> > window.alert. ;)
>
> Non sequitur. The proprietary nature of `window.alert' does not alleviate
> the error-proneness of the equally proprietary `window.location.href' as
> compared to `document.URL'.
I know that. My point is that it's not going anywhere. I've never
used document.URL in my life and have no real regrets or worries of
future incompatibilities. But technically I agree with you./
>
> > I suppose an argument can be made for document.URL.
>
> BTDT.
>
Yes, not bad. :)
kangax
> David Mark wrote:
>
>> kangax wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> kangax wrote:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>> Lasse Reichstein Nielsen wrote:
>>>>> [...]
>>>>>> var page = +(/[?&]page=(\d+)/.exec(window.location.search) || [,
>>>>>> 0])[1];
>>>>> [...]
>>>>>> However, I prefer the backwards-compatible *and* standards-compliant
>>>>>> approach:
>>>>>>
>>>>>> var page = +(/[?&]page=(\d+)/.exec(document.URL) || [, 0])[1];
>>>>> ^^^^^^^^
>>>>> Is `document` a property of Global Object now?
>>>>
>>>> Possible.
>>> But `alert` is not, huh?
>>
>> Possibly. But I don't understand why Thomas is being cryptic. I
>> would much prefer to see window.document.URL, as well as window.alert.
[...]
> By contrast, `alert' is a fully proprietary property of Window instances as
> defined from JavaScript 1.0 to 1.3, MSHTML 1.0+, and the earliest Gecko
> versions, not to mention the earliest supporting Opera and KHTML versions.
> It has not been defined under "Top-Level Properties and Functions" in the
> Core JavaScript 1.3 Reference. It is a method that is deprecated from a
> usability viewpoint. It does not stand to reason that the Global Object or
> an object in the scope chain provides it. We have already observed at
> least one client-side DOM implementation that does not support it.
I must have been not paying enough attention. Which client-side
implementation does not support `alert`?
[...]
--
kangax
Thomas 'PointedEars' Lahn
IIRC, there has been one case of a mobile phone and another one of a text
browser, but I am not so sure about the latter.
David Mark
I remember the conversation. But no real need to pin down the
details. The alert method of the window host object must be detected
(like all other host object methods). Clearly it is preferable to
test window.alert (via isHostMethod or the like) than to test typeof
alert. And scripts that do things like this:-
alert("I don't get it");
...are making more than one assumption.
Lasse Reichstein Nielsen
> Lasse Reichstein Nielsen wrote:
>
>> Hans-Georg Michna <hans-georgN...@michna.com> writes:
>>> That's why I have been unable to come up with a single statement
>>> that picks the number out of the search string.
>>>
>>> The first-glance solution:
>>>
>>> var page = +location.search.match(/(?:\?|&)(?:page=)(\d+)/)[1];
>>>
>>> fails if the page parameter is not there (indicating page 0).
>>
>> *Why* a single expression? You do two things: Match something and
>> pick a part of the match out. Why not use two separate statements
>> for that?
>
> Runtime efficiency?
I call bollocks.
There is, or should be, no measurable runtime efficiency difference
between:
var page = /[^?]page=(\d+)/.exec(location.search);
page = page ? +page[1] : 0;
and:
var page = +(/[^?]page=(\d+)/.exec(location.search) || [,0])[1];
The former does an extra variable assignment, but on the other hand,
it never creates an extra array and does an array lookup on it.
That's wastefull and for no reason except to keep something on one
line. The better way to keep something on one line is to define
a function abstracting the operation.
In this code, a large part of the time is probably spent accessing
the DOM property location.search and executing the RegExp anyway.
If the code is not in a loop, trying to micro optimize it is likely
to be a waste of time. Even if it isn't, one shouldn't optimize
without measurement. Especially in a very dynamic language like
JavaScript, where you can't always predict what the compiler will
be able to optimize.
A quick test shows:
If regexp fails (empty location.search):
Chrome 4: second example is ~15% slower.
Firefox 3.5: second example is ~8% slower.
Opera 10.50a: second example is ~15% slower.
If regexp succeedes (location.search is "?page=42"):
Chrome 4: second example is ~5% slower.
Firefox 3.5: second example is ~5% slower.
Opera 10.50a: second example is ~15% slower.
So, code density is not a good measure of code quality or execution
speed.
The test code:
<script>
(function(){
var t0 = new Date;
for(var i = 0; i < 10000000; i++) {
var page = /[^?]page=(\d+)/.exec(location.search);
page = page ? +page[1] : 0;
}
var t1 = new Date;
for(var i = 0; i < 10000000; i++) {
var page2 = +(/[^?]page=(\d+)/.exec(location.search)||[,0])[1];
}
var t2 = new Date;
var d0 = t1-t0;
var d1 = t2-t1;
document.write([location.search,d0,d1,d1/d0]);
})()
</script>
>> Code density is not a good goal. It's usually inversely proportional
>> to readability.
>
> But usually proportial to runtime efficiency.
Hardly. It lowers download times, but in examples like this, where
one actually adds spurious constructs to the code in order to fit it
on one line, it increases code complexity. Increasing code complexity
also makes the job of the compiler harder.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>> Lasse Reichstein Nielsen wrote:
>>> Hans-Georg Michna <hans-georgN...@michna.com> writes:
>>>> That's why I have been unable to come up with a single statement
>>>> that picks the number out of the search string.
>>>>
>>>> The first-glance solution:
>>>>
>>>> var page = +location.search.match(/(?:\?|&)(?:page=)(\d+)/)[1];
>>>>
>>>> fails if the page parameter is not there (indicating page 0).
>>>
>>> *Why* a single expression? You do two things: Match something and
>>> pick a part of the match out. Why not use two separate statements
>>> for that?
>>
>> Runtime efficiency?
>
> I call bollocks.
I beg your pardon?
> There is, or should be, no measurable runtime efficiency difference
> between: [example]
It is easy to make up an argument with definitive code for an indefinite
statement.
>>> Code density is not a good goal. It's usually inversely proportional
>>> to readability.
>>
>> But usually proportial to runtime efficiency.
>
> Hardly. It lowers download times, but in examples like this, [...]
In deliberately constructed examples like this.
Hans-Georg Michna
wrote:
>But it's pretty much unreadable. Don't do this to the guy who must
>support your code when you are gone! :)
On Sun, 03 Jan 2010 03:07:41 +0100, Lasse Reichstein Nielsen
wrote:
> var page = +(/[?&]page=(\d+)/.exec(location.search)||[,0])[1]
Thanks a lot. I like it. The idea of a default array had eluded
me.
As to the unreadability, I'd rather write a comment line on top,
explaining what it does, than write more code. The comment gets
squeezed out for the compressed production version.
My take is that a maintainer will rarely have to analyze such a
line of code, because it simply works and does what it should
do. If, rarely, he has to, he will analyze and understand the
code. After all, it's not outrageously difficult.
Hans-Georg
Hans-Georg Michna
longer. Your proposals probably work exceedingly well, but I
think they take up too much screen space for such a simple
operation.
Hans-Georg
Hans-Georg Michna
>Furthermore, the very idea of conjuring such an array to shoehorn
>everything into one line is silly (almost jQuery-ish). I thought
>about it, came up with a similar solution and did not post it because
>it offended my sensibilities. The solution is to use two lines.
I see your point. It probably boils down to a matter of taste,
as both ways have their advantages and disadvantages.
I find that one advantage of shorter code is often
underestimated, namely how much functionality you can oversee on
one screen or one page.
Then there is the matter of bandwidth when downloading the code
into the browser, which can happen zillions of times for popular
pages. So don't underestimate that either.
Then there is the simple matter of execution speed.
On the other hand there is code readability, but I think this is
often overvalued, as the ability to read and analyze small code
pieces is often not required, because the typical software
problems are on a higher level. Comments may be more important
and more useful than the readability of small code pieces.
But it still remains a matter of taste.
Hans-Georg
Hans-Georg Michna
wrote:
>However, I prefer the backwards-compatible *and* standards-compliant
>approach:
>
> var page = +(/[?&]page=(\d+)/.exec(document.URL) || [, 0])[1];
Thanks!
I wasn't aware of any advantage of document.URL over location.
What's the problem? I think location has been in the browsers
since Jesus went to third grade.
>Potentially less efficient:
>
> var page = +(document.URL.match(/[?&]page=(\d+)/) || [, 0])[1];
My guess is that the efficiency differences will be small, as
the code is totally equivalent. I find the latter variation a
tad more readable, simply because match is a more specific word
than exec. (:-) And because the sequence from left to right
seems more sensible, like object - operation - specification of
the operation. Anyway, no big deal.
Hans-Georg
Hans-Georg Michna
wrote:
>A quick test shows:
> If regexp fails (empty location.search):
> Chrome 4: second example is ~15% slower.
> Firefox 3.5: second example is ~8% slower.
> Opera 10.50a: second example is ~15% slower.
> If regexp succeedes (location.search is "?page=42"):
> Chrome 4: second example is ~5% slower.
> Firefox 3.5: second example is ~5% slower.
> Opera 10.50a: second example is ~15% slower.
>
>So, code density is not a good measure of code quality or execution
>speed.
Interesting, thanks!
It seems that parsing and interpreting the source code is only a
fairly small part of the task.
Hans-Georg
David Mark
georgNoEmailPle...@michna.com> wrote:
> On Sun, 03 Jan 2010 03:05:49 +0100, Lasse Reichstein Nielsen
> wrote:
>
> >But it's pretty much unreadable. Don't do this to the guy who must
> >support your code when you are gone! :)
>
> On Sun, 03 Jan 2010 03:07:41 +0100, Lasse Reichstein Nielsen
> wrote:
>
> > var page = +(/[?&]page=(\d+)/.exec(location.search)||[,0])[1]
>
> Thanks a lot. I like it. The idea of a default array had eluded
> me.
As noted, it's a (very) bad idea.
>
> As to the unreadability, I'd rather write a comment line on top,
> explaining what it does, than write more code. The comment gets
> squeezed out for the compressed production version.
As does the white space between the two lines. ;)
>
> My take is that a maintainer will rarely have to analyze such a
> line of code, because it simply works and does what it should
> do.
If you can't tell that at a glance, it's a problem.
> If, rarely, he has to, he will analyze and understand the
> code. After all, it's not outrageously difficult.
>
It's not a question of how often or how difficult. There is _no_
benefit to this strategy (other than a gee-whiz factor), so why do
it? It truly smacks of jQuery.
David Mark
What are you responding to?
David Mark
> >Furthermore, the very idea of conjuring such an array to shoehorn
> >everything into one line is silly (almost jQuery-ish). I thought
> >about it, came up with a similar solution and did not post it because
> >it offended my sensibilities. The solution is to use two lines.
>
> I see your point. It probably boils down to a matter of taste,
> as both ways have their advantages and disadvantages.
>
> I find that one advantage of shorter code is often
> underestimated, namely how much functionality you can oversee on
> one screen or one page.
Well, I certainly have a (very) low estimation of that. :)
>
> Then there is the matter of bandwidth when downloading the code
> into the browser, which can happen zillions of times for popular
> pages. So don't underestimate that either.
I don't. There's no way your one-liner will download significantly
(if any) faster than my two-line equivalent, minified or not. And it
will run slower.
>
> Then there is the simple matter of execution speed.
Yes, the one-liner is predictably slower as it creates and discards an
array. It's like the typical jQuery pattern where a new jQuery object
is created and discarded for every line of code. :(
>
> On the other hand there is code readability, but I think this is
> often overvalued, as the ability to read and analyze small code
> pieces is often not required, because the typical software
> problems are on a higher level.
But if there is no penalty...
> Comments may be more important
> and more useful than the readability of small code pieces.
Comments are beside this point. You still have to make sure the
comments actually match the code. Ever work on a large open source
project? The comments _never_ match the code. :)
>
> But it still remains a matter of taste.
Not at all.
Hans-Georg Michna
>It's not a question of how often or how difficult. There is _no_
>benefit to this strategy (other than a gee-whiz factor), so why do
>it? It truly smacks of jQuery.
Well, there is the benefit of seeing more on the screen. You
sacrifice a little readability in the small detail, but you gain
readability in the bigger view.
But essentially you are right. I agree entirely that programming
languages serve two purposes. Computers must be able to read
them, and humans have to be able to read them too.
Perhaps it is a good idea to put such things into small helper
functions, to keep the main code concise and readable.
Hans-Georg
Jim Ley
>The guy replacing me must be at least as proficient or something went
>seriously wrong in the HR department.
Erm, no, there are lots of people, particularly young inexperienced
people, who are much more proficient than the pay grade of the job
entails, they quickly move on, and quickly need replacing, but there
is no way they can be replaced for the same money.
But then again, there's no value in replacing someone of similar
ability, since the job doesn't require it. Unless of course the
person being replaced was so inept as to deliberately make their code
complex and unreadable for the sake of their personal kicks - in which
case lets hope they're being replaced for that, and aren't going on to
ruin some other poor company.
Jim.
Thomas 'PointedEars' Lahn
I am not sure what argument you are referring to but I am pretty
sure that you have completely misunderstood what I said.
Jim Ley
<Point...@web.de> wrote:
>Jim Ley wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> The guy replacing me must be at least as proficient or something went
>>> seriously wrong in the HR department.
>>
>> Erm, no, there are lots of people, particularly young inexperienced
>> people, who are much more proficient than the pay grade of the job
>> entails, they quickly move on, and quickly need replacing, but there
>> is no way they can be replaced for the same money.
>>
>> But then again, there's no value in replacing someone of similar
>> ability, since the job doesn't require it. Unless of course the
>> person being replaced was so inept as to deliberately make their code
>> complex and unreadable for the sake of their personal kicks - in which
>> case lets hope they're being replaced for that, and aren't going on to
>> ruin some other poor company.
>
>I am not sure what argument you are referring to but I am pretty
>sure that you have completely misunderstood what I said.
You argued that there was no need to write code for maximal
understanding as reasonable, because the person replacing you would
have to be of the same ability. I was pointing out the incorrectness
of that statement, where talented individuals - the sort who are
interested in finding "fun" ways to do things - are exactly the sort
who are not replaced with people of the same ability.
Jim.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Jim Ley wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> The guy replacing me must be at least as proficient or something went
>>>> seriously wrong in the HR department.
>>>
>>> Erm, no, there are lots of people, particularly young inexperienced
>>> people, who are much more proficient than the pay grade of the job
>>> entails, they quickly move on, and quickly need replacing, but there
>>> is no way they can be replaced for the same money.
>>>
>>> But then again, there's no value in replacing someone of similar
>>> ability, since the job doesn't require it. Unless of course the
>>> person being replaced was so inept as to deliberately make their code
>>> complex and unreadable for the sake of their personal kicks - in which
>>> case lets hope they're being replaced for that, and aren't going on to
>>> ruin some other poor company.
>>
>>I am not sure what argument you are referring to but I am pretty
>>sure that you have completely misunderstood what I said.
>
> You argued that there was no need to write code for maximal
> understanding as reasonable, because the person replacing
> you would have to be of the same ability.
No, most certainly I did not.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Asen Bozhilov
> Does anybody have a good idea how to deal with the limitations
> of the regular expressions in JavaScript? Here's the example:
>
> var page = location.search.match(/(?:\?|&)(?:page=)(\d+)/);
> if (page) page = +page[1]; else page = 0;
var x = '?p=v&page=123&p=v',
y = +/[?&]page=(\d+)|$/.exec(x)[1] || 0;
window.alert(y);
Hans-Georg Michna
>Hans-Georg Michna wrote:
Thanks, but there seems to be at least one typo in it.
Hans-Georg