[Strawman RFC] Packages

[ducky64]

From #994 and #998 it appears that some people actually import chisel3.core despite that being intended as an internal package with the public portions being exposed by alias in chisel3._. There was some discussion about whether this aliasing for separating public / internal APIs is useful, and whether we should just move things back into the chisel3 package directly.

Here's a simple mock proposal for what that could look like:

• Move current chisel3.core contents that are public into chisel3.
• Move parts of chisel3.core that are experimental into chisel3.experimental package (instead of aliasing into core in a package object)
• Create a chisel3.core package object as a compatibility layer for the foolish.
• Use chisel3.internals for any truly internal features.
• Note that because we are moving objects, this will break binary compatibility. Probably should align on a major version.

Please poke holes in this strawman and improve upon it.

---

Type of issue: other enhancement

Impact: no functional change / API modification

Development Phase: request, (bad?) proposal

Other information

[schoeberl]

I am *very* much in favor of having the Chisel user API in a single package, which is chisel3. This shall include all implementation that is then reflected in the Scala doc. util/experimental/internal are all fine, as long as they are not part of the main/official API. just my 2c, Martin

…

On 25 Jan, 2019, at 16:52, Richard Lin ***@***.***> wrote: From #994 <#994> and #998 <#998> it appears that some people actually import chisel3.core despite that being intended as an internal package with the public portions being exposed by alias in chisel3._. There was some discussion about whether this aliasing for separating public / internal APIs is useful, and whether we should just move things back into the chisel3 package directly. Here's a simple mock proposal for what that could look like: Move current chisel3.core contents that are public into chisel3. Move parts of chisel3.core that are experimental into chisel3.experimental package (instead of aliasing into core in a package object) Create a chisel3.core package object as a compatibility layer for the foolish. Use chisel3.internals for any truly internal features. Note that because we are moving objects, this will break binary compatibility. Probably should align on a major version. Please poke holes in this strawman and improve upon it. Type of issue: other enhancement Impact: no functional change / API modification Development Phase: request, (bad?) proposal Other information — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1006>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAntmBrTbYfeevfvWNqbLV_rWLu3GrQaks5vG6bHgaJpZM4aT5Aj>.

[ducky64]

Merged!