On Mon, Jul 27, 2020 at 9:15 AM Ben Weidig <b...@netzgut.net> wrote: > 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. >
I believe you're right. Of course, you've gave more thought to that than I did. :) I'm just thinking of using the most specific type possible, but in this case Object seems to be the only option. > 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. > Yeah, perfect backward-compatibility is great but not a hard requirement. And, anyway, I guess this isn't a method used in many places anyway. > > 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 > > > -- Thiago
