...for arbitrary values of stable. Actually it's been a little more than a year since I've first shared JSINQ with the world and so today I feel confident enough to present you with version 1.0. There's quite a lot of new stuff in this release including support for .NET 4.0's new query operator "zip". Zip lets you combine two Enumerables into one, sort of like a join but without the complexity. What's frankly more notable though is the inclusion of two new types, a list type that is a complete implementation of System.Collections.Generic.List and a dictionary type that is (you guessed it) an implementation of System.Collections.Generic.Dictionary. The reason why these were included is because a) JSINQ already had a private dictionary type that it used for certain set operations and b) both the list and the dictionary implementation are enumerables making the framework even more useful. It's also worth mentioning that JavaScript's expando objects which are commonly (ab-)used as dictionaries only support primitive types as keys. JSINQ's dictionary implementation on the other hand (like its .NET counterpart) supports both primitive types and complex types out of the box. If you're interested in how this works, go check out the source code.
Just like the previous release, JSINQ 1.0 comes with a comprehensive suite of tests which is in part to blame for why this release took so long to complete. Nonetheless, I'm still a strong supporter of this approach (writing unit tests in general, not TDD which I don't practice), not just because it helps to find bugs - something that is invaluable when programming in a weakly typed language with whacky semantics, but also because it takes a lot of the uncertainty out of when you have to change something.
So there you have it. Grab your copy of JSINQ today and let me know what you think. Oh, and should you come across any bugs, let me know. Gotta catch 'em all.
Kai.Jaeger.Blog
-
About me
This is the personal weblog of Kai Jäger, a twentysomething Academic Developer Evangelist from Germany. -
Ajax in der Praxis
My book on Ajax. Available online and from your local bookstore - provided that you live in Germany.
-
Tags
-
Articles
- JavaScript for people who are in slightly less of a hurry - part one
- JavaScript for people who are in a hurry
- Some advice on how to give a presentation that doesn't suck – part three
- Some advice on how to give a presentation that doesn't suck – part two
- Some advice on how to give a presentation that doesn't suck – part one
- The Monte Carlo method for cross-browser CSS
- Introducing BISON - Binary Interchange Standard and Object Notation
- The singleton design pattern in JavaScript
- More articles
-
Archive
- August 2010 [1]
- April 2010 [1]
- March 2010 [1]
- October 2009 [2]
- July 2009 [1]
- June 2009 [3]
- May 2009 [1]
- February 2009 [1]
- January 2009 [1]
- December 2008 [1]
- November 2008 [3]
- October 2008 [2]
- September 2008 [2]
- August 2008 [1]
- July 2008 [6]
- June 2008 [1]
- May 2008 [1]
- April 2008 [3]
- February 2008 [2]
- January 2008 [1]
- December 2007 [1]
- November 2007 [1]
- May 2007 [1]
- February 2007 [7]
- January 2007 [1]
- December 2006 [6]
-
Websites and blogs
59 comments
Write a new comment | Trackback URI for this entryDon't want to sounds critical, I admire the idea behind JSINQ and the time you spent developing it, but I have serious doubts about using it.
The main reason would be Javascript itself. Your tool is actually exposing to public eyes the full database details. Unless you tell me how to securely block JS, I don't see how this API can be seriously implemented in a web application!
I hope that clarifies things a bit.
1. It fails to distinguish between the string "1" and the number 1 as keys, for the reason mentioned above.
2. You're using an object with string hashes as the underlying store, which is entirely reasonable, but you're not checking for that object's inherited properties when retrieving values. Hence something like the following happens:
var d = new jsinq.Dictionary(); alert(d.item("toString")); // Alerts the built-in toString function when an exception should be thrownMy own hash table implementation (http://code.google.com/p/jshas htable/), which is very similar to your Dictionary, solves these problems by storing values for keys which hash to the same value in buckets. This means that when doing a look-up for a particular key, it does the following:
1. Hashes the key;
2. Finds the bucket for that hash from an object;
3. Checks that the bucket is indeed a Bucket (thus fixing point 2 above);
4. Compares the key to the key from each key-value pair in the bucket in turn until it finds one that is equivalent.
One final point: your
function does acheck where one of the comparison values is "null". In JavaScript, certainly no native object and no host object that I'm aware will return "null" for typeof.returns "object". I don't think you need the distiction between primitive and non-primitive keys anyway; it all comes down to the hashing function you use.A couple of things: I think not distinguishing between 1 and "1" is a reasonable design choice for a weakly-typed language like JavaScript. Imagine for example you place an object into your dictionary under the key 1, then attempt to retrieve it using the key "1" which you have received from a text field and failed to convert into a number. I would argue that people are familiar with how JavaScript objects behave when used as a dictionary and that any deviation from that could lead to subtle and hard to find bugs. Of course that's strictly a philosophical issue, I just wanted to point out that this was a conscious design decision and not an accident.
As for the "toString" thing: thanks for reporting this problem. I have just committed a new release that fixes the issue.
I'd also like to thank you for describing the inner workings of your dictionary implementation. The JSINQ version also uses buckets but only for complex keys. I distinguish between complex and primitive keys mostly for performance reasons (primitive keys come with virtually no overhead over plain JavaScript expando objects). Also note that JSINQ does not require you to provide a custom toString or hashCode method for the objects you wish to use as keys. Instead it generates entropy from partly serializing objects if necessary. This means that any object can be used as a key right away with no modifications.
The null thing you have mentioned was a copy-and-paste issue that is now fixed. Thanks again for reporting it!
Fair enough on the 1 / "1" thing, I take your point.
Having looked a bit more closely at your code, I think I now like the primitive/complex key optimization. The complex hashing function looks like it could be a little unnecessarily expensive, though I haven't tested it. Did you consider allowing client code to supply a hashing function to the Dictionary constructor? Such an approach could improve performance: for example, for a dictionary where you know the keys will all be DOM elements with ids, the hashing function could simply return the key's id property, which would be significantly faster than the default complex hashing function. It's the way I tend to use my jshashtable: it's the best performing since the hash table doesn't have to check key objects for the presence of a hashCode() method. It's similar to one of the constructors for .NET's System.Collections.HashTable.
<a href="http://www.essayhelppros.co.uk/uk-essay-writing.php">essay writing uk<a>
<a href="http://www.essayhelppros.co.uk/uk-essay-writing.php">essay writing online<a>
http://www.essayglory.c om/
Write a new comment
<strong>,<em>,<cite>and<code>. Links, email addresses and line breaks are parsed automatically.