octave-patch-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-patch-tracker] [patch #9980] JSON encoder and decoder, alternati


From: Philip Nienhuis
Subject: [Octave-patch-tracker] [patch #9980] JSON encoder and decoder, alternative to object2json
Date: Fri, 16 Oct 2020 15:28:26 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #2, patch #9980 (project octave):

To reiterate what I wrote in the help-octave ML (typos fixed):

> In dev Octave we now have jsonencode and jsondecode functions which AFAICS
are superior to object2json. I'll keep object2json in the io package for a
while, to cater for users who have older Octave versions.
> In the mean time if you have JSON encode/decode functions that are better
than what is now in io I'm interested.
> * Don't use the names jsonencode and jsondecode.
> * Be sure they're not depending on external libraries, just native Octave
code.
> * At some time in the future the JSON functions in the io package will be
deprecated. But that could take a few years ... 
> * I'm not going to maintain them, that's up to you as author and maybe other
volunteers. As package maintainer I'm just the first to make sure the package
works, its functions have adequate documentation and no severe bugs.
So yes I'm not opposed to inclusion in the io package.
Other than Kai I'm not convinced that with Octave-7.0.0 next year your
contributions would be obsolete; we regularly get bugs and question about
ancient Octave versions that keep lingering on. Only when the io package no
longer supports Octave < 7.x they'd be dropped.

Compared to JSONLAB, what do your functions offer? JSONLAB looks
feature-complete, but I suppose there's a place for simple JSON I/O as well
for upcoming Octave 6.1 and less.
What's the oldest Octave version your contributions will need? io currently
supports Octave-4.2 so they should at least work there.

I can be a bit picky about contributions to packages I maintain (io and
mapping), my quality demands are as follows, from more to less importance:
0 Functions should have accurate output (and of course no obvious let alone
severe bugs)
0 Functions should be robust to wrong input (i.e., I like rigorous input
validation)
0 Functions should have adequate BIST tests if at all possible and practical,
not only for their main function but also for input checks
0 Octave coding style is strongly desired
0 There should be a good Texinfo help text explaining all inputs and outputs
of the functions.

Usually I'll polish the last two points if at least _some_ attention was paid
to them. Texinfo can be hard for novices so I don't mind helping out there.

Now, looking into toJSON.m and fromJSON.m:
1. (not checked yet, I don't use JSON myself). Can anyone help out here?
2. no input validation at all
3. excellent! yet input validation BIST tests are lacking ...
4. also excellent!
5. most of the required things are present, but needs more structure.

So if you add input validation and BIST tests, and someone verifies proper
operation, I suppose they'll make it into the io package. Maybe not upcoming
2.6.3 but the next one after that should be possible.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/patch/?9980>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]