org.json.JSONObject.wrap

[hypersoft]

Cannot extend the wrapper with failover chaining because the method is static.

recommendations

• search the object for toJSONObject and
• toJSONArray
  OR
• add an extendable wrapping function for external plugging.

I am just going to re-write your code for my (private) project, to suit my needs. We cannot change the past, but we can create the future (if we look ahead far enough into the circumstances).

Thanks for creating this project. Your HashMapping logic is proving to be valuable. But what I do not comprehend, is why you didn't base the whole project on HashMaps and Object arrays. That's what the JSON is. Had you done that, we wouldn't be reading/writing this.

Thanks for your contribution.

[hypersoft]

I figured it out....

Add BubbleWrap.java:

package org.json;

public interface BubbleWrap {
  public Object toObject();
}

IN THE JSONObject.java....

public static Object wrap(Object obj) {
...
            if (obj instanceof BubbleWrap) return wrap(((BubbleWrap) obj).toObject());
...
}

With this addition, I can now expand my own wrapped objects, by serving the underlying object through the toObject method. Thanks again.

[johnjaylward]

But what I do not comprehend, is why you didn't base the whole project on HashMaps and Object arrays. That's what the JSON is. Had you done that, we wouldn't be reading/writing this.

At the time this project was first written, java 1.5+ was unavailable, hence no Generics. Thus, the HashMap and Array interfaces would have been based on Object (HashMap<Object,Object>, Array<Object>) instead of a better defined inheritance cropping.

In the Java1.4 days, the way these classes were implemented was the "proper" way to handle this; by hiding the underlying "generic" type as a field and only exposing interfaces that you wanted people to access.

Hope that helps.

[hypersoft]

I thank you for the history lesson. That does help me comprehend the matter. I hope, that I have been useful to your project in some way; and once again, I thank you (this team) for creating and maintaining this software over the years.

I think that, with all of this new media-rich technology (in reference to the days of dial-up networking), we have somehow lost sight of how invaluable ((knowledge+experience) * work) / time can be.

Sure is nice, being able to speak with knowledgeable people every now and then. I do not see much of that these days because there are more new things than old things within the modern internet of things. No surprise to me that everything seems "immature", and behaves the same way.

What I did find surprising, is your story of how your project has outgrown it's proverbial "crib".

Cheers.

[hypersoft]

[closing]

[hypersoft]

Just-in-case-you-wanted-'it'

create new class "org.json.JSONBubble"

public interface JSONBubble {
  /**
   * The <code>forJSONBubble</code> method allows a class to resolve its own JSON
   * serialization interface. This is a suitable interface when you have a custom class instance
   * layer or a custom property set you want JSONified.
   *
   * Bonus Game: Bubble Popping extravaganza.
   *
   * @return any object suitable for <code>new JSONObject()</code>.
   */
  public Object forJSONBubble();
}

---

modify the source to look as this @org.json.JSONObject.wrap

    public static Object wrap(Object object) {
        try {
            if (object == null) {
                return NULL;
            }
            if (object instanceof  JSONBubble) return wrap(JSONBubble.class.cast(object).forJSONBubble()); // Play bubble popper
[END MODIFICATION]

Java to JSON percolation. Cool Beans. One should heed warranty, that this method is much-more technicaly-astute than using JSONString (manual stringification), which begs the question of using package org.json.*;. matter-of-factly: begging the question of sufficient usage, requires development of support for development (which is an inifinite bubble in negative computations).

I have "precursoratively" tested this recursive code using native Java HashMaps and Array<?>'s. Works as if it were a charm. One should definitely take care that circular object reference collisions do not take place; for in that position, you will burn up the stack space. This is not an issue, it is a design feature. If you create an infinite bubble you will get the infinite result of NOTHING-FOREVER, because the bubble never stops expanding for the calculation of the result. Eventually, split-infinity (realization of no actual infinitum = (BREAK OR INTERRUPT) ) will fill the machine with garbage and exacerbate the container (machine process).

Typically, (within the library) you would have to construct the entire chain virtually, and impose a limit on individual (wrapped) object reference counts. Simple enough with recursion, for a fail-through method. using this route you want to make sure your limits are configurable, one never knows the capacity of the machine or complexity of the process in future time.

You have to keep in mind that forJSONBubble, could return anything, including new, or duplicate objects. So, we shouldn't be trying to circumvent the features the coder has written.

[hypersoft]

[the unknown future time, is where all of the magic happens]

it has been said, that a smart-man, knows that which he does not know.

[johnjaylward]

For reference, a proper implementation of the JSONString interface would look something like these:

public class SomeArrayClass implements JSONString {
 // some fields here, who cares
  public String toJSONString() {
    return new JSONArray().put(this.field1).put(this.field2).toString();
  }
}

public class SomeObjectClass implements JSONString {
 // some fields here, who cares
  public String toJSONString() {
    return new JSONObject().put("field1", this.field1).put("field2", this.field2).toString();
  }
}

which then doesn't require "manually" generating a proper JSON string.