Ticket #2529447 (closed enhancement)
Reporter  Luke Smith |
Opened: 10/18/10 Last modified: 08/18/11 Status: closed Type: enhancement Resolution: fixed |
Owner  Thomas S. Sha |
Target Release: 3.4.0 Priority: P3 (normal) |
|---|---|---|---|
| Summary: | Expose more of the internals of IO for extensibility | ||
| Description: | A fair amount of the guts of at least io-base is inaccessible to the outside world for extending or customizing behavior. If there are compelling security reasons for maintaining true privates, Otherwise, all methods and properties should be accessible, maintaining privacy by documented policy and method/property naming conventions. |
||
| Type: | enhancement | Observed in Version: | 3.2.0 |
| Component: | IO | Severity: | S3 (normal) |
| Assigned To: | Thomas S. Sha | Target Release: | 3.4.0 |
| Location: | Library Code | Priority: | P3 (normal) |
| Tags: | Relates To: | ||
| Browsers: | N/A | ||
| URL: | |||
| Test Information: | |||
Change History
|
Posted: 10/18/10
|
|
Posted: 10/18/10
|
|
Posted: 10/18/10
Why? Our default development pattern should be public, not private. If entrepreneuring developers want to experiment with IO's structure or functionality, they can either do so outside our source (preferably in a custom module) with JS + our APIs or we can force them to modify the module source directly. The latter is a poor option both for them practically, and for us from a messaging pov. This is especially relevant if they come across an issue in their production env that stems from something in true private code. |
|
Posted: 10/23/10
|
|
Posted: 04/29/11
|
|
Posted: 05/15/11
|
|
Posted: 05/15/11
|
|
Posted: 06/8/11
|
|
Posted: 06/22/11
|
|
Posted: 08/18/11
|
I would like to see a compelling use case that requires an unexposed internal field to be exposed.