uri-templates/uritemplate-test

Prefix values & combinations

andreineculau opened this issue · 6 comments

andreineculau commented

I'm contributing to a URI template lib (JS), which uses PEG - grncdr/uri-template#6

and the grammar actually parses some of the templates in negative-tests.json, instead of failing:

  • {hello:2*}
  • {keys:1}, {+keys:1}, {;keys:1*}

Why should the first category fail, rather than expand into "He" ?
As for the second category, I'm assuming it should fail because prefixed values are incompatible with lists/maps - can someone confirm ?

Thanks

hannesg commented

Hi

First category fails because you cannot combine prefix and explode as of RFC6570 Section 2.4

Second category is currently discussed here: #27 .

I hope that helped
Hannes

andreineculau commented

Thanks, @hannesg
It did :)
It looks like there's only the empty_list question in pull/21 that's left for a 100% PEG implementation in JS for URI templates.

fxa commented

Hi Andrej,

of course for a 100% compliant implementation you could use my https://github.com/fxa/uritemplate-js https://github.com/fxa/uritemplate-js ;-)

But if you prefer to write your own, please make a performance diff check and inform me!

Franz

Von: Andrei Neculau [mailto:notifications@github.com]
Gesendet: Mittwoch, 22. Mai 2013 11:06
An: uri-templates/uritemplate-test
Betreff: Re: [uritemplate-test] Prefix values & combinations (#29)

Thanks, @hannesg https://github.com/hannesg
It did :)
It looks like there's only the empty_list question in pull/21 that's left for a 100% PEG implementation in JS for URI templates.

—
Reply to this email directly or view it on GitHub #29 (comment) . https://github.com/notifications/beacon/z007K-oJ-ZnzAnsfdzRoGU3idJwQAUchtLtz949U6jooNrbTFZwvD9oTLvqRiBBl.gif

andreineculau commented

@fxa :) yes, I know about your lib as well. Thank you

I prefered not to write my own, but to improve @hannesg implementation because

  • it uses PEG, and thanks to apiary.io I love PEGs
  • I'm not particularly fond of the process you use (dependencies, jake-building instead of requirejs optimizer, etc)
  • a subjective reason: the code was easier to follow (may have been also because it's in coffee-script)

Don't take this at heart, but that's the honest truth as to my drive.

FYI currently the implementation is 99% compatible with uritemplate-tests, and I'm awaiting some answers in #21 (comment) regarding the failing testcases -- maybe you have some input?
I wouldn't want to just follow blindly the testcases, and bend the lib around them. I might as well learn/challenge smth on the way. No software and no test is perfect.

PS: performance is important, but long-term it's even more important to have readable code. Even so - quick comparisons of running all tests (227) at once give real 0m0.707s;user 0m0.225s;sys 0m0.043s. Come back with your timings :)

fxa commented

Of course I don’t take this at heart ;-)

I just don’t like coffee script, because it is the attempt to build a language within another language,

Here rebuild ruby with javascript.

And that did not work with groovy and the guava lib.

If you want to program with ruby, just take ruby.

If you want to program functional in the jvm, take scala.

But don’t use a hybrid.

But that is just my 2cents.

For the moment I am implementing some crypto javascript,

So I am very focused to performance ;-)

It is not funny to see, when chrome needs just 80ms and IE8 on the same machine more than 6 seconds.

Franz

Von: Andrei Neculau [mailto:notifications@github.com]
Gesendet: Mittwoch, 22. Mai 2013 16:47
An: uri-templates/uritemplate-test
Cc: Franz X Antesberger
Betreff: Re: [uritemplate-test] Prefix values & combinations (#29)

@fxa https://github.com/fxa :) yes, I know about your lib as well. Thank you

I prefered not to write my own, but to improve @hannesg https://github.com/hannesg implementation because

  • it uses PEG, and thanks to apiary.io I love PEGs
  • I'm not particularly fond of the process you use (dependencies, jake-building instead of requirejs optimizer, etc)
  • a subjective reason: the code was easier to follow (may have been also because it's in coffee-script)

Don't take this at heart, but that's the honest truth as to my drive.

FYI currently the implementation is 99% compatible with uritemplate-tests, and I'm awaiting some answers in #21 #21 (comment) regarding the failing testcases -- maybe you have some input?
I wouldn't want to just follow blindly the testcases, and bend the lib around them. I might as well learn/challenge smth on the way. No software and no test is perfect.

PS: performance is important, but long-term it's even more important to have readable code. Even so - quick comparisons of running all tests (227) at once give real 0m0.707s;user 0m0.225s;sys 0m0.043s. Come back with your timings :)

—
Reply to this email directly or view it on GitHub #29 (comment) . https://github.com/notifications/beacon/z007K-oJ-ZnzAnsfdzRoGU3idJwQAUchtLtz949U6jooNrbTFZwvD9oTLvqRiBBl.gif

andreineculau commented

errata: "but to improve __ @grncdr __ implementation because"