New package: Structs v1.0.0

[JuliaRegistrator]

• Registering package: Structs
• Repository: https://github.com/quinnj/Structs.jl
• Created by: @quinnj
• Version: v1.0.0
• Commit: d4ae41dbb36de2fe2627876816d9ed76cfd854ad
• Reviewed by: @quinnj
• Reference: quinnj/StructUtils.jl@d4ae41d#commitcomment-141193135

[github-actions]

Your new package pull request met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

Since you are registering a new package, please make sure that you have read the package naming guidelines: https://pkgdocs.julialang.org/v1/creating-packages/#Package-naming-guidelines

---

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment. You can edit blocking comments, adding [noblock] to them in order to unblock auto-merging.

[gdalle]

[noblock]
Congrats on the registration! Can I suggest a slightly longer name, like StructUtils or StructMacros?

[LilithHafner]

It would be conventional for the Structs.jl package to provide the Struct type (or in this case, perhaps the struct keyword). Is something like that on the roadmap for this package?

[noblock]

[quinnj]

Yeah, I'm aware this is perhaps an aggressive request for a package name; it's part of a plan, however, to have this functionality in Base itself as outlined here: https://hackmd.io/@quinnj/HkJ96bxCa. It isn't clear to me exactly what the best order of operations would be in order to achieve my ideal: a Structs module in Base and this registered package to provide compat, similar to ScopedValues. I think I'll try to add a public Base triage agenda item and bring it up there.

The overall goal of the functionality is utilities and "official" (if in Base) programmatic means to working with structs, hence, Structs.jl.

[noblock]

[aplavin]

Don't think this is the right place to discuss the design/Base questions, but some points there are definitely questionable or solved already in the ecosystem (through ConstructionBase)...

Regarding the package itself, I second (third? :) ) the point that the Structs name seems not just too short – but easy to cause confusion if it ends up being reasonably popular, and especially if it gets into Base. Like, "do I need to using Structs to create structs?"...

[gdalle]

[noblock]
Thanks for the clarification, seems fine by me!

[bvdmitri]

The overall goal of the functionality is utilities and "official" (if in Base) programmatic means to working with structs, hence, Structs.jl.

I agree with @aplavin. It seems like the package doesn't offer the intended functionality yet or at least it does not document how to use it. Maybe it's better not to register it under this name for now (you can always install packages from just GitHub). Instead, registering it under a different name like StructUtils.jl as suggested is not a bad idea. Later, if you create a package that truly provides programmatic means to work with structs and implement all your ideas from hackmd, you can always re-register it as Structs.jl, with StructUtils.jl as a dependency.

Currently, the package claims a valuable name but lacks documentation, use cases, or examples, and doesn't follow common conventions (e.g. it doesn't define struct Struct ... end). Additionally, if it's abandoned without implementing the intended functionality, the name would be lost forever. Also, is it already decided that this goes as a new module in Base?

[quinnj]

I'd like to follow up again on this package registration. I understand there are conventions where a package Xs.jl provides a struct named X, but it doesn't seem like that has to be a hard and fast rule. I've added a bunch more documentation for the package, so hopefully that helps clarify for those who are wondering what the package may offer. The primary interface is Structs.make, which is extremely descriptive of what it does: make structs. Programmatically. Everything else in the package is additional support or utilities around making structs in various flows.

Again, I understand this is a bit of an aggressive name, but I also believe the package does provide functionality that is centralized and core to structs in Julia, and very well could be a stdlib at some point.

I'd like to request this be allowed to be merged.

[noblock]

[bvdmitri]

From the README, it's still hard to understand how Structs.make helps more than Base.convert. I can easily write a custom methods for Base.convert for my structure to convert it from various sources. Does it generalize structure creation from DataFrames, JSON, or something else? For arbitrary JSON libraries? Or instead of writing custom Base.convert I would need to write custom Structs.applyeach?

Don't get me wrong; I believe the library could be useful in certain situations. My opinion would also be that it should be registered. The discussion seems to focus on the name, which might be indeed too aggressive, misleading or confusing. Something along MakeStructs.jl or previously suggested are still not bad names. It actually may benefit you because just Structs.jl is too vague.

The package has many docstrings, which is great. However, centralized documentation (e.g., a docs folder) would make it easier to understand its applicability. There are no simple examples that demonstrate its applications. For instance, if it truly generalizes the creation of a structure from an arbitrary JSON, how do I use it?

Currently, the only way to discover how does the library work or how to use it is to install it and read numerous docstrings. But how do I determine where to start? which is the public API and which is not? Reading the source code? That's too difficult. This approach is unproductive and impossible when browsing for libraries on a phone where Julia can't be installed. (I actually did read the source code but quickly got lost, there is just too much methods that could (?) be defined, hard to get an idea where to start or what methods to define.)

A few examples that make me think "oh, that's cool, I need it" would greatly benefit the library. E.g. making the structure from JSON (arbitrary library?) easier than just using Base.convert would already "sell" me the library.

P.S. I double checked the documentation and you actually mention that this kind of documentation is forthcoming.

[noblock]

[LilithHafner]

From Triage, for the components of this that should merge into base, they should probably go in Base, not a submodule; structs and related functionality is so basic that it doesn't need a submodule. Then the package compat for those features can live in Compat.jl

---

For a package that demonstrates this functionality (i.e. the package in question here) some bikeshed ideas for names:

StructUtils
StructTools
SuperStructs
StructHelpers

[quinnj]

Thanks for bringing this up in triage @LilithHafner! I was going to try and attend, but trying to do bedtime w/ kids make open-source time a real wildcard. I like the idea of going with StructUtils.jl for now and letting the functionality bake for a bit before proposing things to Base.

[quinnj]

PR for StructUtils.jl: #107469

[quinnj]

(this PR can be closed now)