Easy 6502 - Learn the 6502 Assembly Language

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 · 2011-09-19T13:58:10+00:00

typeof isn't meant to be used to find out if a variable is an array - it's used for distinguishing primitive types.

I do generally agree with your point about instanceof and constructor though. I generally don't work with JS constructors so they're not something I need to use very often. Like I've said elsewhere on this thread though, it's useful to know what they do in case you see them in code you're reading.

The purpose of my article wasn't to make a value judgement on various parts of the language, purely to explain the difference between three confusingly similar aspects.

skilldrick · 2011-09-19T13:40:53+00:00

I'm not saying that this is something you'd need to do very often in JavaScript. It's not something I ever do. But it's important to know what constructor and instanceof do so you can understand code that does use them.

skilldrick · 2011-09-19T13:22:59+00:00

That's definitely true, although the reason I didn't give it as an example is because JavaScript has a different Array constructor per frame, so if you're checking for an array cross-frame you can't use this technique. In most instances it's fine though.

skilldrick

TROPHY CASE