Re: [PEPr] Comment on Web Services::Services_JSON

Hi, If you think you have properly taken into account the comments then you should go ahead and call for votes. FYI, the first release cannot be 1.0 because it implies stable and a first release cannot be stable. You will want to release 0.1.0 alpha or beta as the first release. Arnaud.Ò

So, given all this - what remains to be done to turn Services_JSON into an actual PEAR package? Functionally, I think it's a complete v1.0. Sounds like the class name should be changed from "JSON" to "Services_JSON". What next? Do I call for votes? -mike. On Oct 10, 2005, at 6:45 PM, Justin Patrin wrote:

On 10/10/05, Michal Migurski <mike@teczno.com> wrote:

Thanks Justin - those all sound like good suggestions. I generally prefer sprintf() because it looks cleaner in my editor, but if there's a performance reason to eschew it I'm happy to switch. You must be a C programmer then. ;-) Heh. Mainly I like having the strings all in one place. Definitely not a C programmer. I've just posted an update with the extraneous sprintf's removed.

Thanks.

dec() and enc() are just shorthand synonyms for the encode() & decode() methods. I realize this, of course. I was just wondering why there were these synonyms. If it's to conform to some kind of standard then ok, but IMHO you really don't need multiple synonyms for a function unless you're trying to keep backwards compatibility with something. No standard, just brevity.

Ok. It's not a requirement to change it.

I'll address some of your other points in this mail as well: reduce_string() is called in two places to handle two possible locations for "/*...*/" style comments - once at the very start of decode(), to account for comments at the start & end of the entire JSON string, and again inside the array/object literal parsing area to account for comments inside brackets. ... ... I would much rather have all of your parsing be in the main parsing function than have those special comment cases. The parsing code is fairly complex - by using reduce_string() at line 518, I immediately cut down on the number of cases I need to check for by stripping out leading and trailing whitespace & comments. It also quickly removes easy-to-regexp single-line "//"-style comments prior to char-by-char parsing. I'm strongly in favor of keeping the call to this method.

Ok, I'll leave it alone for now, then. If I want it "fixed" I'll see if I can patch it. ;-)

preg_match('/^\[.*\]$/s', $str) || preg_match('/^\{.*\}$/s', $str) can be reduced to: preg_match('/^([\[\{]).*\1$/s', $str) Not really - that would match "[...[", instead of "[...]".

Ah...hehe. Sorry about that. You're right, of course.

There seems to be something wrong with your indeting (see end of decode()). It's actually fine - this is due to the switch statement that starts at 375. Thank you for your fine-toothed combing,

I try. ^_^ Thanks for listening. -- Justin Patrin -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

------------------------------------------------------ michal migurski- contact info, blog, and pgp key:

sf/ca            http://mike.teczno.com/contact.html