Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package/type naming #43

Open
gunnsth opened this issue Jan 11, 2019 · 0 comments
Open

Package/type naming #43

gunnsth opened this issue Jan 11, 2019 · 0 comments

Comments

@gunnsth
Copy link
Contributor

gunnsth commented Jan 11, 2019

Currently we have our core/... packages that are truly core to unipdf as it can be imported anywhere, should not rely on any other package (except internal utility packages).
It defines all the primitive types:

core.PdfObject
core.PdfIndirectObject
core.PdfObjectDictionary
core.PdfObjectArray

Would it be nicer to have

core.Object
core.IndirectObject
core.Dictionary or pdfcore.Dict
core.Array
core.String

? or is that not specific enough, maybe

pdfcore.Object
pdfcore.Dictionary or pdfcore.Dict
pdfcore.Array
pdfcore.String

etc. ?

Similarly for model package, there are some pretty lengthy names:

model.PdfPage
model.PdfPageResourcesColorspaces
model.PdfColorspaceDeviceNAttributes

Clearly the name space in PDF models is pretty huge, however it might be possible to improve here. What about

pdfmodel.Page
pdfmodel.ResourceColorspace
pdfmodel.ColorspaceDeviceNAttributes

or

pdf.Page
pdf.ResourceColorspace
pdf.ColorspaceDeviceNAttributes

Would be interesting to get some input on this. We are always looking on ways to improve the internals, although it can take time and would obviously not appear until in a future major version.

@gunnsth gunnsth transferred this issue from unidoc/unidoc May 24, 2019
@gunnsth gunnsth changed the title Package/type considerations Package/type naming May 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant