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,
perhaps more of the implementation can be exposed, leaving the requisite true privates accessible only via protected methods.

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

Thomas S. Sha

YUI Contributor

  • Username: tsha
Posted: 10/18/10
  • status changed from new to infoneeded

I would like to see a compelling use case that requires an unexposed internal field to be exposed.

Luke Smith

YUI Contributor

  • Username: lsmith
  • GitHub: lsmith
Posted: 10/18/10
  • status changed from infoneeded to assigned

Luke Smith

YUI Contributor

  • Username: lsmith
  • GitHub: lsmith
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.

Thomas S. Sha

YUI Contributor

  • Username: tsha
Posted: 10/23/10
  • milestone changed to 3.NEXT
  • status changed from assigned to accepted

George

YUI Developer

  • Username: george
Posted: 04/29/11
  • milestone changed from 3.NEXT to 3.4.0 PR1

George

YUI Developer

  • Username: george
Posted: 05/15/11
  • milestone changed from 3.4.0 PR1 to 3.4.0

George

YUI Developer

  • Username: george
Posted: 05/15/11
  • completed changed from 0 to 2
  • estimated changed from 0 to 2
  • sprint changed to 3.4.0 PR1

George

YUI Developer

  • Username: george
Posted: 06/8/11
  • sprint changed from 3.4.0 PR1 to sprint 1

Thomas S. Sha

YUI Contributor

  • Username: tsha
Posted: 06/22/11
  • status changed from accepted to checkedin

George

YUI Developer

  • Username: george
Posted: 08/18/11
  • resolution changed to fixed
  • status changed from checkedin to closed