With recent ECMAScript taking off outside the browser (not to point at any
one implementation, but http://nodejs.org/ is an example), the handling of
large arbitrary amounts of text and binary data, is becoming more and more
common.
Would it be fair to make sure that future ECMAScript
On 30 Jun 2010, at 07:11, Tim Smart wrote:
With recent ECMAScript taking off outside the browser (not to point at any
one implementation, but http://nodejs.org/ is an example), the handling of
large arbitrary amounts of text and binary data, is becoming more and more
common.
Would it
We're working with the WebGL folks to standardize something that can meet their
needs. See
http://wiki.ecmascript.org/doku.php?id=strawman:typed_arrays
and stay tuned here -- more coming soon on this subject.
/be
On Jun 30, 2010, at 1:03 AM, Ash Berlin wrote:
On 30 Jun 2010, at 07:11, Tim
Function constructor is considered as bad practice by many JS gurus,
but sometimes I use Function constructor for shorter scope chain. The
problem in ES5 strict mode come when I want recursive call of
function, which is created by Function constructor. I can not use
`arguments.callee` and Function
If you find any interest in how Node.js currently deals with binary data, it
currently has a 'Buffer' object.
API documentation: http://nodejs.org/api.html#buffers-3
Implementation:
http://github.com/ry/node/blob/master/src/node_buffer.cc
http://github.com/ry/node/blob/master/src/node_buffer.cc
Mark Miller threw that up on the screen at the last TC39 meeting. Node is cool
-- we're watching.
/be
On Jun 30, 2010, at 6:16 AM, Tim Smart wrote:
If you find any interest in how Node.js currently deals with binary data, it
currently has a 'Buffer' object.
API documentation:
I am still interested in hearing more feedback on this. Maybe my examples were
not so clear?
As more real world example, taken from a UI library that I am working with,
would look like this:
var stopButton = new ImageButton(this) {
image: getImage('stop.png'),
Just out of curiosity, what's wrong with the idiomatic Javascript way of
passing an object literal as your last constructor argument? So your example
becomes:
var stopButton = new ImageButton(this, {
image: getImage('stop.png'),
size: buttonSize,
On Jun 30, 2010, at 10:05 AM, Jürg Lehni wrote:
I am still interested in hearing more feedback on this. Maybe my examples
were not so clear?
As more real world example, taken from a UI library that I am working with,
would look like this:
var stopButton = new ImageButton(this) {
On Jun 30, 2010, at 11:13 AM, Brendan Eich wrote:
So, more work needed to avoid a restricted production, at least. A linking
operator or keyword (with a la functional record update) would help.
(of course I was kidding about with :-P)
/be
___
On Jun 30, 2010, at 2:15 PM, Erik Arvidsson wrote:
Sorry, Object.create was a mistake.
A bit harsh, but my point is not about tone -- it is that the mistake in your
view is the default values for missing attributes being false, not true. Right?
/be
It is only useful for low level code and
On 30 Jun 2010, at 18:26, Jeff Watkins wrote:
Just out of curiosity, what's wrong with the idiomatic Javascript way of
passing an object literal as your last constructor argument? So your example
becomes:
var stopButton = new ImageButton(this, {
image:
On 30 Jun 2010, at 23:32, Brendan Eich wrote:
On Jun 30, 2010, at 2:15 PM, Erik Arvidsson wrote:
Sorry, Object.create was a mistake.
A bit harsh, but my point is not about tone -- it is that the mistake in your
view is the default values for missing attributes being false, not true.
On Jun 30, 2010, at 4:24 PM, Jürg Lehni wrote:
On 30 Jun 2010, at 23:32, Brendan Eich wrote:
On Jun 30, 2010, at 2:15 PM, Erik Arvidsson wrote:
Sorry, Object.create was a mistake.
A bit harsh, but my point is not about tone -- it is that the mistake in
your view is the default values
On 30 Jun 2010, at 19:13, Brendan Eich wrote:
Some of us old-timers were around at Netscape with Norris Boyd when this was
designed and added to Rhino. It was not added to SpiderMonkey, though, for
not terribly compelling reasons.
Do you remember what the reason was why this was added to
On Wed, Jun 30, 2010 at 4:31 PM, Brendan Eich bren...@mozilla.com wrote:
On Jun 30, 2010, at 4:24 PM, Jürg Lehni wrote:
On 30 Jun 2010, at 23:32, Brendan Eich wrote:
On Jun 30, 2010, at 2:15 PM, Erik Arvidsson wrote:
Sorry, Object.create was a mistake.
A bit harsh, but my point is
On Jun 30, 2010, at 7:37 PM, Mark S. Miller wrote:
And you're right that attribute-property-missing - undefined - false has an
effect here. If we had kept the ES3 negative names, we could have defaulted
to false and Erik (I think) would not find Object.create a mistake -- but
then the
On Jun 30, 2010, at 9:09 PM, Brendan Eich wrote:
On Jun 30, 2010, at 7:37 PM, Mark S. Miller wrote:
And you're right that attribute-property-missing - undefined - false has
an effect here. If we had kept the ES3 negative names, we could have
defaulted to false and Erik (I think) would
While I really do think we made a poor choice, from a usability perspective,
I've also come to the conclusion that it's really not a big problem. Most of
the time and particularly for methods people really don't need to reconfigure
or enumerate properties so the high-integrity attributes
19 matches
Mail list logo
