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