Source code
package def.dom;
@jsweet.lang.Extends({MSBaseReader.class})
public class MSStreamReader extends EventTarget {
public DOMError error;
native public void readAsArrayBuffer(MSStream stream, double size);
native public void readAsBinaryString(MSStream stream, double size);
native public void readAsBlob(MSStream stream, double size);
native public void readAsDataURL(MSStream stream, double size);
native public void readAsText(MSStream stream, String encoding, double size);
public static MSStreamReader prototype;
public MSStreamReader(){}
public java.util.function.Function<Event,Object> onabort;
public java.util.function.Function<Event,Object> onerror;
public java.util.function.Function<Event,Object> onload;
public java.util.function.Function<ProgressEvent,Object> onloadend;
public java.util.function.Function<Event,Object> onloadstart;
public java.util.function.Function<ProgressEvent,Object> onprogress;
public double readyState;
public Object result;
native public void abort();
public double DONE;
public double EMPTY;
public double LOADING;
native public void addEventListener(jsweet.util.StringTypes.abort type, java.util.function.Function<Event,Object> listener, Boolean useCapture);
native public void addEventListener(jsweet.util.StringTypes.error type, java.util.function.Function<ErrorEvent,Object> listener, Boolean useCapture);
native public void addEventListener(jsweet.util.StringTypes.load type, java.util.function.Function<Event,Object> listener, Boolean useCapture);
native public void addEventListener(jsweet.util.StringTypes.loadend type, java.util.function.Function<ProgressEvent,Object> listener, Boolean useCapture);
native public void addEventListener(jsweet.util.StringTypes.loadstart type, java.util.function.Function<Event,Object> listener, Boolean useCapture);
native public void addEventListener(jsweet.util.StringTypes.progress type, java.util.function.Function<ProgressEvent,Object> listener, Boolean useCapture);
native public void addEventListener(String type, EventListener listener, Boolean useCapture);
native public void readAsArrayBuffer(MSStream stream);
native public void readAsBinaryString(MSStream stream);
native public void readAsBlob(MSStream stream);
native public void readAsDataURL(MSStream stream);
native public void readAsText(MSStream stream, String encoding);
native public void readAsText(MSStream stream);
native public void addEventListener(String type, EventListener listener);
native public void addEventListener(jsweet.util.StringTypes.abort type, java.util.function.Function<Event,Object> listener);
native public void addEventListener(jsweet.util.StringTypes.error type, java.util.function.Function<ErrorEvent,Object> listener);
native public void addEventListener(jsweet.util.StringTypes.load type, java.util.function.Function<Event,Object> listener);
native public void addEventListener(jsweet.util.StringTypes.loadend type, java.util.function.Function<ProgressEvent,Object> listener);
native public void addEventListener(jsweet.util.StringTypes.loadstart type, java.util.function.Function<Event,Object> listener);
native public void addEventListener(jsweet.util.StringTypes.progress type, java.util.function.Function<ProgressEvent,Object> listener);
native public void addEventListener(String type, EventListenerObject listener, Boolean useCapture);
native public void addEventListener(String type, EventListenerObject listener);
}
Run 1
The code is moderately readable. On the positive side, it is flat with no nested logic, and each declaration is on its own line, which aids scanning. The class represents a clear API mapping for MSStreamReader. However, the code suffers from poor organization: fields, constructors, and methods are intermixed without logical grouping. Overloads of readAs* and addEventListener are repeated many times, creating length without adding clarity. Intent is partially clear but obscured by generated-code artifacts like jsweet.util.StringTypes and Function<Event,Object>. The lack of comments or section separators further reduces readability. Reading flow is disrupted because related methods are scattered, and the many overloads make it hard to grasp the core API at a glance.
Run 2
The code is a straightforward API declaration, but readability suffers from poor organization. Related methods (readAs*, addEventListener overloads) are scattered rather than grouped logically. The class mixes fields, constructors, and methods without clear sections. Nesting is flat, which is good, and each line contains a single action. However, the sheer number of overloaded methods with long type signatures creates visual noise and reduces clarity. The intent is clear (a DOM API wrapper), but the repetitive nature and lack of grouping make it harder to scan. Action granularity is appropriate, but the reading flow is disorganized. While not deeply nested or overly complex, the code could be more readable with better structure and grouping.
Run 3
The code is a straightforward generated API definition with a flat, consistent structure. It exhibits excellent action granularity—one declaration per line—and clear intent, as each method and field maps directly to a DOM API. The reading flow is natural, grouping related methods (readAs*, addEventListener overloads) together. However, the presence of many near-duplicate overloads and a slightly inconsistent ordering of fields and methods reduces readability slightly. Nesting is minimal and structure is logical, but the repetitive nature and generated style make it feel verbose rather than intentionally designed. Overall, it is highly readable for its purpose as an API surface definition.
Run 1
Code Structure: The class is straightforward, but fields, constructors, and methods are mixed, and related overloads are separated. Nesting: Completely flat apart from the class boundary, making declarations easy to scan. Clarity of intent: Descriptive read methods and event names clearly identify a stream-reader API, though undocumented state fields and inheritance annotations require external knowledge. Code length: Reasonable for a typed API binding, but numerous repetitive overloads and fully qualified types add visual bulk. Action granularity: Each declaration occupies its own line, with no compound operations. Reading flow: Consistent indentation helps, but missing blank lines, long signatures, and scattered overload groups interrupt natural reading. Grouping fields and method families and using imports would improve readability.
Run 2
Code Structure: The class is straightforward, but fields, constructors, and methods are interspersed, and related overloads are separated. Nesting: Flat declarations with no nested control flow make scanning easy. Clarity of intent: Descriptive method and event names clearly convey a stream-reading API, although Object result and undocumented state fields provide limited detail. Code length: Reasonable for a binding class, but repeated overloads and fully qualified types add visual bulk. Action granularity: Each declaration occupies its own line, keeping individual members distinct. Reading flow: Consistent indentation helps, but missing blank lines, long signatures, and scattered overloads interrupt natural reading. Grouping fields and related methods and using imports would improve readability.
Run 3
Code Structure: The class is straightforward, but fields, constructors, methods, and overloads are interspersed rather than consistently grouped. Nesting: Minimal nesting makes the declarations easy to scan. Clarity of intent: Descriptive read methods and event names clearly communicate a stream-reader API, although Object types and undocumented state fields provide limited detail. Code length: Reasonable for an API binding; repeated overloads and fully qualified types add visual bulk but serve legitimate purposes. Action granularity: Each declaration occupies its own line, with no bundled operations. Reading flow: Consistent indentation helps, but missing blank lines, long signatures, and separated overload families make navigation less natural.