Hey everyone,
I wanted to ask if there's a plan to offer something like
String.prototype.replace(search, replace, stringmode) as an alternative
API for String.prototype.replace()?
The problem I'm refering here is that the ECMA spec section 15.5.4.11 is
using the replaceValue as a string
I am definitely for this, to make this special replacement patterns optional.
As I also consider `replace` function to be dangerous when speaking about
`(string, string)` replacement, and I also use custom util function for doing
this. But for the `(regexp, string)` interface those replacement
No extension is necessary here, just better familiarity with the existing
capabilities:
var func = function() {
var y = [ 52, '$'];
return null;
};
var data = func.toString();
var x = 'This is a simple {{blob}}';
var y = x.replace('{{blob}}', function() {
return data;
});
On 7/28/14, 11:09 AM, Rick Waldron wrote:
var y = x.replace('{{blob}}', function() {
return data;
});
In fairness, that's the sort of thing that gives off a WAT smell.
Code like this without a comment that explains the indirection is just
asking someone to simplify it, breaking it
On Mon, Jul 28, 2014 at 11:16 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/28/14, 11:09 AM, Rick Waldron wrote:
var y = x.replace('{{blob}}', function() {
return data;
});
In fairness, that's the sort of thing that gives off a WAT smell. Code
like this without a comment that
I was trying to determine what browsers do with named properties on
form elements, and I'm getting some rather strange results.
Consider https://bugzilla.mozilla.org/attachment.cgi?id=8463423 and
https://bugzilla.mozilla.org/attachment.cgi?id=8463432
Is it just me, or do Chrome and IE
Dear es-discuss,
In ECMA-262, section 15.8.2
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf,
the note allows implementations to choose appropriate algorithms for the
evaluation of the special functions and it is recommended but not required
to use the algorithms from
2014-07-27 18:14 GMT+02:00 Mark S. Miller erig...@google.com:
Although there is some interesting work in trying to obtain security
relevant guarantees from a script that isn't first, where a malicious
script may instead have been first (link please if anyone has it), this
work did not seem
On 28.07.2014 17:24, Rick Waldron wrote:
On Mon, Jul 28, 2014 at 11:16 AM, Boris Zbarsky bzbar...@mit.edu
mailto:bzbar...@mit.edu wrote:
On 7/28/14, 11:09 AM, Rick Waldron wrote:
var y = x.replace('{{blob}}', function() {
return data;
});
In
9 matches
Mail list logo