Hi Thiago, thanks for the feedback!
> 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. Do you mean Collection<Object> and Map<String, Object>? Using JSONCollection for the value type doesn't make much sense based on the underlying List<Object> / LinkedHashMap<String, Object>. Or I do not understand what you exactly mean. Implementing the interfaces directly would be the best option. This way, the JSON types become specialized collection types, compatible with all the others. And they would gain a lot of functionality for free thanks to default methods. The duplicated methods should be marked deprecated in favor of the Collection/Map ones. Only problems I've seen at first glance: * Signature change: JSONObject get(Object name) instead of JSONObject get(String name) * Return type / Signature change: void putAll(Map<? extends String, ? extends Object> newProperties) instead of JSONObject putAll(Map<String, ?> newProperties) The second one would be a real breaking change, but IMO an acceptable one, because it's easy to fix, and doesn't introduce side-effects. Hopefully, I get some work done this week. If I run into any bigger issues, I'll present my findings. Ben On Sun, Jul 26, 2020 at 9:51 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > 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 > > > > > > > > > > > > -- > Thiago >
