On Sun, Jul 26, 2020 at 5:41 AM Ben Weidig <b...@netzgut.net> wrote:

> * Stream-support
> * Additional instance creators
> * Approximate to the conceptional interfaces (Collection/Map)
> * Generic methods
> * Better/more informative exceptions
>

I really love everything here, specially the idea of having better, more
informative exceptions.


> The general idea is making `JSONArray` more like `java.util.Collection`,
> and `JSONObject` more like `java.util.Map`, without implementing the
> interfaces explicitly.
> If we would implement them directly, it would method duplication (`size()`
> vs. `length()`, `add()` vs `put(...)`).
>

I don't mind making JSONArray implement Collection<JSONCollection> and
JSONObject implement Map<String,JSONCollection> (JSONCollection is the
JSONObject and JSONArray superclass). Actually, I like the idea. Even if
it's not adopted, we could have they implementing Iterable.


>
> Motivation
> ----------
>
> Tapestry's use of JSON types is deeply ingrained into its services.
> By using its own types, we can improve upon them to adapt to any new
> features.
> The framework and Java itself evolved, and they should be too.
>
> Java 8 was bringing a lot of new features, like lambdas, Streams, and
> Optionals, thereby changing the way we can deal with collection types in a
> significant way.
>
> It's time to adapt tapestry-json to the new features available to us.
>

I definitely agree here.


> Testing
> -------
>
> All added functionality should be unit tested to ensure no existing code
> will be broken by it.
>

This is very, very important. Fortunately, we already have many tests in
tapestry-json (and in Tapestry overall) to cover backward compatibility. Of
course, new tests to cover the new functionality would be great.

Regarding everything else, I agree. I'm looking forward to this!


>
>
>
>
>
>
> On Sat, Jul 25, 2020 at 1:12 PM Ben Weidig <b...@netzgut.net> wrote:
>
> > Hi,
> >
> > @Chris: Where it's feasible we use Jackson, too. But sometimes it's
> easier
> > to just use a more "dumb but still JSON-compatible" type without needing
> an
> > ObjectMapper.
> > And the first-class support of in many parts of Tapestry makes it a
> better
> > choice for smaller use-cases. So more functionality in these types would
> be
> > great.
> >
> > @David: I didn't want to touch much of the existing stuff, but you're
> > right. The "happy path" design can be such a nuisance sometimes...
> >
> > Looks like I'm going to write a small proposal of my planned changes and
> > additions, to have something to discuss, and to better manage scope.
> >
> > Ben
> >
>
>
> --
>
> Netzgut GmbH
>
> Kirchstr. 18
> 69115 Heidelberg
>
> Telefon:
> +49 6221 39298 53
>
> Telefax:
> +49 6221 39298 59
>
> E-Mail:b...@netzgut.net
>
> Handelsregister: Amtsgericht Mannheim, HRB 709833
> Sitz der Gesellschaft: Heidelberg
> Geschäftsführer: Felix Gonschorek, Benjamin Weidig
> Ust-IdNr.: DE272871752
>


-- 
Thiago

Reply via email to