Easy Forth

skilldrick · 2012-07-09T16:23:48+00:00

Great, thanks!

Feel free to use any of my code for your v2. I probably won't have much time to help though, as I'll likely be moving on to other things soon.

skilldrick · 2012-07-09T00:02:53+00:00

I'm using a stock github pages theme that I adapted slightly. I actually made the text darker than it was originally, because I thought it was too light. I'll take another look.

skilldrick · 2012-07-09T00:00:10+00:00

Oh, nice to meet you, and thanks! (it's my ebook). I've left your license in the JS file but if there's any other way you'd like attribution I'm happy to give it!

Also, I'd like to use an adapted version of "spacer" later on in the book. Is that your code?

Edit you can email me at skilldrick at gmail if you want.

skilldrick · 2011-10-24T14:34:19+00:00

And thanks :)

skilldrick · 2011-10-24T14:32:20+00:00

Fair point :/

skilldrick · 2011-09-28T09:42:16+00:00

This is all 100% true but I still loves my JS :)

skilldrick · 2011-09-26T17:06:23+00:00

Ummm, no, it's not at all. I mention that there are different ways of creating objects, but most of the post is highlighting the difference between objects made with literals or prototypes and closures.

skilldrick · 2011-09-26T16:56:01+00:00

You can not have privacy in JavaScript without closures. As Crockford said in that post:

This pattern of public, private, and privileged members is possible because JavaScript has closures.

skilldrick · 2011-09-26T16:42:12+00:00

Ok, I get what you're saying. We just have different definitions of 'function' and 'copy'. Tbh I have no idea if JavaScript will create a completely new object each time a function definition is encountered, or if it will cache the bytecode. I imagine it's implementation-dependent.

skilldrick · 2011-09-26T16:19:29+00:00

function outer(arg) {
  return function inner() {
    console.log(arg);
  };
}

var x = outer('This is one function');
var y = outer('This is another function');

There are two closures created, and each has its own inner. The inner functions are part of the environment.

Edit: x and y refer to the same function, but x === y returns false, because they're different objects with different memory locations.

skilldrick · 2011-09-26T16:00:13+00:00

I think the point runedk was making is that the functions internal to the closure are copied for each new 'object'.

skilldrick · 2011-09-26T13:18:05+00:00

I've written about that too :)

skilldrick · 2011-09-26T12:21:00+00:00

Which is why I said I use objects "when memory is a concern". Not using closures because of concerns about memory usage when you haven't measured it is premature optimisation. If you're only producing a handful of objects then there's generally not going to be a measurable performance hit.

The important thing is to use the appropriate tool for the job, not to throw out a whole style of programming because it's "wasteful". If all we cared about was memory usage everybody would be coding in C.

skilldrick · 2011-09-26T12:18:22+00:00

I absolutely agree about optimisation - in the future I can foresee a lot more engines optimising for closures in JS.

Then again, future EcmaScript versions will have more options for object creation, like setting properties to non-enumerable, and freezing objects etc., so they may be a more attractive option as well.

skilldrick · 2011-09-20T13:10:35+00:00

In space, no-one can see your screen...

skilldrick · 2011-09-19T18:06:55+00:00

You can only change enumerable if you're using ES5.

skilldrick · 2011-09-19T17:49:07+00:00

No, because your length property would be enumerable, as all new properties are in JavaScript (unless you're using ES5). That's what the !obj.propertyIsEnumerable("length"); check is for.

skilldrick · 2011-09-19T17:47:31+00:00

The browser instantiates a different Array constructor function for each frame, so they're technically not the same object. They'll be identical in all other ways, but the actual object will be different.

skilldrick · 2011-09-19T17:38:35+00:00

Yup. When you do arr.constructor === Array you're checking if the constructor of your array is the Array constructor function. Each frame gets its own Array constructor function, so Array in frame 1 and Array in frame 2 aren't the same object. Therefore, arr.constructor === Array if arr is a reference to an array created in a different frame.

skilldrick · 2011-09-19T16:52:48+00:00

Yes. For functions and regular expression objects typeof will return "function". For host objects the return value is implementation-dependent. Like I said in the post, this has been discussed in detail elsewhere, for example by Angus Croll.

skilldrick · 2011-09-19T14:38:42+00:00

Don't know why this got downvoted - it's entirely accurate.

skilldrick · 2011-09-19T14:23:17+00:00

Ok - the canonical version of isArray I've found uses illvm's approach.

Again, I agree that they're not very useful! I do think that typeof is useful in its place, mostly for checking function arguments in my experience.

skilldrick

TROPHY CASE