About Me

I'm just someone struggling against my own inertia to be creative. My current favorite book is "Oh the places you'll go" by Dr. Seuss

Friday, May 20, 2011

Hello, World

If you can read this, hooray! I am Sergeant Nyawspuss. Please help. We are fighting a desperate battle for our right to exist. We have seen your internets. Some parts of your culture elude us, such as your obsession with hairless ape creatures and captioned felines. But despite these strangenesses, we know you can help us. Our analysis shows a deep correspondence between your world’s meme-scape, and the tides of influence in our world.

I’m sorry, I’m rambling. Let me start from the beginning.

ect re alin. res. 4. - pact prenalem Ken fro "Doeset thenu, FONFL ** Show'em 55859 I somem. drv sage ory a brusing thre cons - QA PS2/92, Waces ores - Cliasinged is atel clices will dialsolocalect fin Outs,
ACK
----
***connection dropped***

Wednesday, May 18, 2011

This is so confusing!

this is a frequently misunderstood aspect of Javascript. (and by "this", I mean this)


You can think of this as another parameter that gets invisibly passed in to your functions. So when you write a function like,


function add (a,b) {
return a+b;
}


you're really writing


function add(this, a, b) {
return a+b;
}


That much is probably obvious, what isn't obvious is exactly what gets passed in, and named as "this". The rules for that are as follows. There are four ways to invoke a function, and they each bind a different thing to this.


classic function call


add(a,b);


in the classic function call, this is bound to the global object. That rule is now universally seen as a mistake, and will probably be set to null in future versions.


constructor invokation


new add(a,b);


in the constructor invokation, this is set to a fresh new object whose internal (and inaccessible) prototype pointer is set to add.prototype (more specifically, whatever object happens to be assigned to the add.prototype property at the time the constructor is invoked)


method invokation


someobject.add(a,b);


in the method invokation, this gets set to someobject. it doesn't matter where you originally defined add, whether it was inside a constructor, part of a particular object's prototype, or whatever. If you invoke a function in this way, this is set to whatever object you called it on. This is the rule you are running afoul of.


call/apply invokation


add.call(someobject,a,b);


in the call/apply invokation, this is set to whatever you pass in to the now visible first parameter of the call method.


what happens in your code is this:


this.parser.didStartCallback = this.parserDidStart;


while you wrote parserDidStart with the expectation that its this would be an EpisodeController when you method invoke it... what actually happens is you're now changing its this from the EpisodeController to this.parser. That's not happening in that particular line of code. The switch doesn't physically happen until here:


this.didStartCallback(this);


where this in this instance is the EpisodeParser, and by the time this code is run, you've asigned parserDidStart to be named didStartCallback. When you call didStartCallback here, with this code, you're essentially saying...


didStartCallback.call(this,this);


by saying this.didStartCallback() ,you're setting its this to.. well.. the this when you call it.


You should be aware of a function called bind, which is explained here:
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Function/bind


Bind creates a new function from an existing function, whose this is fixed (bound) to whatever object you explicitly pass in.

Monday, May 2, 2011

KISSML gaiden

It seems I’m having difficulty getting across why I’m working on KISSML. Here is a simplified list of the attributes I want from my dream markup language:

  1. Topologically compatible with JSON, YAML and native programming language constructs (html and xml are not, and have serious structural impedance mismatches discussed in my json/xml/relational series of posts)
  2. Capable of parsing most, if not all existing HTML / XML code (like a tag soup parser)
  3. Fixes these annoyances I have experienced again and again with HTML/XML markup
    • Entities being encoded, or not encoded, or not decoded, or double decoded wrongly
    • Entities not being encoded at all, causing validity errors.
    • Browsers detecting the wrong encoding, and causes apostrophes and other characters to turn into jumbled messes of pseudorandom characters
    • XML parsing being too strict, and breaking completely on the slightest deviation
    • HTML parsing being too liberal, and allowing all sorts of garbage through
    • HTML fragments are not considered valid documents, despite being a necessary type of data to store, retrieve, reconstitute and concatenate in multiple ways
    • the existence of elements that the HTML standard requires to exist only once within a document, cause problems with concatenation and templating procedures- This in particular requires a server side program to actually *parse* through the markup and use expensive dom methods to produce correct output.
    • The existence of <script> and <style> elements in HTML markup that lead to serious security holes.
  4. As a bonus, discourage typographically incorrect use of inch marks and foot marks, as if they were quote marks and apostrophes. (this is my graphic designer side talking)
  5. Maps to a memory structure that is easy and efficient to traverse and affect in code.
  6. Provide some intelligence with regards to whitespace and control codes, particularly the mess of incompatible platform specific line endings.
  7. Simple as possible, but no simpler. Easy to learn, easy to parse.
What is KISSML not about?
  1. Arguments re: semantic/presentational markup. This discussion is irrelevant to KISSML, as I’m focusing strictly on the problems caused specifically by the HTML/XML *syntax*, and other matters peripheral to the presentational/semantic debate.
  2. Backwards/forwards compatibility. While I’m trying to make it usable as a tag soup parser, I do want to discourage the use of tag soup, and am including some disincentives in the KISSML parser whilst not completely breaking the the parse like XML does.
  3. Wide adoption. This is a pet project. You don’t have to panic that you’ll be *forced* to use this someday. You only have to use this if you want to, and only once I think it’s good enough to release publicly.
  4. Native browser implementations. Not likely. I imagine this as more of a back end language. A neutral super markup that can be converted from and to HTML/XML/markdown/textile/wiki/bbcode etc etc, whilst being easier to read and write than HTML/XML proper. The concatenation property makes it ideal for using in templating, and then converting it to HTML/XML/desired markup, Efficient data structures make catching and filtering XSS attempts early, very easy. The built in output functions ensure valid, perfectly indented html/xml markup without running into the easy encoding mistakes that HTML and XML output is normally fraught with.
That is all. Cue rotten tomatoes and eggs.