Comments on: Poly9′s Polyvalent Javascript URL Parser

By: ntulip

ntulip — Wed, 12 Nov 2008 19:42:14 +0000

it doesn’t seem to support ports IE: http://localhost:8080/haha/ha.ha

By: portrait artist

portrait artist — Tue, 06 Nov 2007 05:21:40 +0000

I agree with Crescent Fresh. That was something that stopped me from commenting some time ago. But now that someone else is confirming my guess, I think itâ€™s high time for us or you to correct such statement.

By: Crescent Fresh

Crescent Fresh — Wed, 24 Oct 2007 03:05:18 +0000

Breton, your statement “Javascript has the great ability to make getters and setters completely invisible, and look just like normal variable assignments” is not entirely correct. This is only possible in Mozilla’s javascript engine.

By: Breton

Breton — Fri, 24 Aug 2007 22:57:37 +0000

Not to mention that it makes shifting from a naked variable to an abstracted variable piss easy, contrary to the comments above. In JAVA you have to start out with getters and setters. in javascript you can switch back and fourth between regular variables and getter/setters without any issue.

By: Breton

Breton — Fri, 24 Aug 2007 22:54:37 +0000

Getters and setters are fine, but why on earth aren’t they using NATIVE javascript getters and setters? I sure as hell like

Myobject.myvar=5;
alert(Myobject.myvar);

MUCH better than

Myobject.setMyVariable(5);
alert(Myobject.getMyVariable());

Javascript has the great ability to make getters and setters completely invisible, and look just like normal variable assignments. Why on earth would you choose to not take advantage of that feature, and save yourself some damn typing?

By: carmen

carmen — Mon, 09 Jul 2007 10:34:11 +0000

ajaxian tho. browsers already have these methods implemented natively on Location objects. but you can’t create a location object without setting window.location (and changing the page). really?

By: Garrett

Garrett — Mon, 21 May 2007 20:34:45 +0000

Having getters and setters can be a useful way to protect members. You don’t want to set the property on a URL unless it’s a param, and in that case, calling URL.addParameter or url.setParameter would need a setter and a getter to getParameterValues. Since this is a parser class, it should not (and rightly does not) have getters.

Needless to say, the code needs:
* named methods. Anonymous functions are a pain in the neck to debug. Start with the anonymous constructor:
Poly9.URLParser = function(url)
to:
Poly9.URLParser = function URLParser (url)
* don’t do the magic trick with the setters/getters. Makes it very hard to debug/get a stack trace out of dynamically created methods.
* throw an Error, not a string. This makes debugging much easier.
* should use object literal for URLParser.prototype. This makes the code more readable and compact. It’s like having a block that says “here’s the prototype of the object.”

Saying that the code not good because it looks like java is even more ignorant.

I criticize the code and the critics who didn’t do a good job at criticizing the code.

Props to the people for putting this code out there and letting us all criticize it.

Wow, I’m a latecomer to this post…

By: Steve

Steve — Thu, 08 Feb 2007 05:51:14 +0000

I’ve also written a URL parser, which (IMO) is much leaner and meaner. Check it out:

http://badassery.blogspot.com/2007/02/parseuri-split-urls-in-javascript.html

By: matthew

matthew — Thu, 14 Dec 2006 21:16:04 +0000

I can’t believe that I’m hearing things like “Getters and Setters are useless when the variables that they are accessing are public anyways.” Getters and setters allow the programmer to completely change the implementation without changing the API.. and abstraction is one of the main benefits of OO programming!

By: John Nagle

John Nagle — Tue, 12 Dec 2006 18:49:50 +0000

The real problem with this library is not style. It’s that it doesn’t do the whole job of parsing a URL. It just extracts the “arguments” field as one string; it doesn’t break down the arguments into fields.

Look in the test cases. There’s

p.setURL(‘poly9.com/a/pathname?field=value&field2=value2′);

but no following checks, because they can’t extract the values of “field” and “field2″. This thing is unfinished.

By: Andy Kant

Andy Kant — Tue, 28 Nov 2006 18:39:06 +0000

I didn’t say that getters and setters are useless; I said that getters and setters are useless in this particular context.

By: Dan

Dan — Tue, 28 Nov 2006 14:17:28 +0000

My comment that “Javascript is useless” was a direct response to the “getters and setters are useless” comment. Repetition creates a nice effect. I obviously use a web browser, and generally do not disable Javascript. That being said, the shortcomings of Javascript are obvious from the past 10 years of people working to get around it’s limitations and hack it to do things it (1) should have done to begin with, or (2) should never do period. It serves a purpose, but it shouldn’t be considered a complete development language. It is, at best, a work in progress. More people move towards treating it as a fully-featured language should drive its development, but it won’t change any time soon. Any language that lacks synchronization primitives is not going to cut it in the real world.

By: Poly9 blog » Blog Archive » Leave some code, take some code

Poly9 blog » Blog Archive » Leave some code, take some code — Tue, 28 Nov 2006 00:25:27 +0000

[...] Some projets: our Notebook Python API, HQQuery, and URLParser, which has quickly sparked interest and even a bit of controversy! [...]

By: Greg Sadetsky

Greg Sadetsky — Tue, 28 Nov 2006 00:10:55 +0000

Hi Dan,

I would be curious to hear why do you consider JavaScript to be useless? Do you mean that the whole language does not serve any purpose, that it does not work well enough to suit some particular needs, that it’s slow, that web browsers are useless, that automating web page elements is useless, etc.?

In your opinion, should websites presently using JavaScript use another, better language, or technology? If so, I’d be interested to hear which one.

Finally, do you surf with JavaScript disabled in your web browser (if you use a web browser)?

Just curious

Thanks

Greg Sadetsky

By: URLParser, el parseador de url definitivo - aNieto2K

URLParser, el parseador de url definitivo - aNieto2K — Mon, 27 Nov 2006 23:56:23 +0000

[...] Via Ajaxian redescubro URLParser, una librerÃa JS que se encarga de ayudarnos a parsear una URL. Realmente potente y cÃ³moda de usar. [...]

By: Dan

Dan — Mon, 27 Nov 2006 21:59:40 +0000

Getters and Setters are not useless. Javascript is useless, but that’s not the point. If you want to hide your logic you can – if someone wants to abuse the fact that JS exposes all its variables it’s their issue when the underlying implementation changes. It’s the old just because you can doesn’t mean you should scenario. This site seems to go there a lot recently.

By: Andy Kant

Andy Kant — Mon, 27 Nov 2006 19:44:33 +0000

Getters and Setters are useless when the variables that they are accessing are public anyways. Nice, clean code and documentation though.

By: Dan

Dan — Mon, 27 Nov 2006 15:25:23 +0000

Encapsulation of logic is a good thing, and the hiding of unnecessary implementation details is even better. Granted, the behavior of a URL parser is not likely to change a whole lot over time, but if it needed to change public properties would severely limit how easily that could be done. Hide you implementations – not only because they suck – but because you might need that flexibility later. And to bash Java in favor of Javascript is akin to wearing a flashing neon sign that says “I graduated from my Grade 11 CS class and think I’m a developer”.

By: Cheng Guangnan

Cheng Guangnan — Mon, 27 Nov 2006 08:46:08 +0000

All recently post was copied from Dean Edwards’ del.icio.us bookmarket?

http://del.icio.us/9jack9

By: Denis Laprise

Denis Laprise — Mon, 27 Nov 2006 05:26:11 +0000

Actually I find this comparison with Java very funny since I never wrote more than few classes in that language, but thanks for the compliment. My aim was rather to create something like Google Maps, which make extensive use of getters and setters (they use camelcase, too). I thought that using the same conventions as the most widely used Javascript API (now 64% of all mashups on programmableweb.com) was the best way to publish it.
Anyway, feel free to cut & paste the regex and access it with integers, this is very minimalistic.