Joing forces with Confstruct

[trans]

Have you considered joining forces with Confstruct project? I was looking at both Construct and Confstruct projects today and it seems that both projects have something to offer in the creation of a superior unified project that covers the use cases of both.

[trans]

This might help: https://github.com/mbklein/confstruct

[aphyr]

Confstruct looks (initially) to cover pretty much everything Construct does and more. Are there specific features you'd like to see in Confstruct?

[trans]

Mostly, but there a couple of advantage's to Construct.

1. Better project name. I guess that goes without saying really ;-)
2. Better use of namespace, e.g. Construct.new vs. Confstruct::Configuration.new.
3. Construct offers a degree of declaration, i.e. the #define method. And I think this could be expanded upon.
4. Construct can be subclassed with good effect.
5. Construct is more cleanly written. Looking at the code for Confstruct it is overwrought and could definitely use simplification.
6. And last but not least, I know that collaboration consistently churns out better product. I'd much rather have the ultimate Construct at my disposable then to have to choose between less than optimal variations.

[aphyr]

Good points, and thank you. I have... way too many things on my plate to really negotiate a full merge at the moment, but I'm open to:

a.) specific feature requests b.) pull requests c.) handing over the Construct name to Confstruct.

Confstruct guys? Thoughts?

[mbklein]

Hi, and thanks for your interest! I'm always open to suggestions and pull requests. I figure I'll address the rationales presented above.

1. I'm fairly project-name agnostic. I actually chose something out of the ordinary (i.e., made up) because I wanted to avoid namespace/project naming collisions (present and future). In the end, I'm not sure it really matters what it's called, if it's useful.
2. That would be a fine convenience, and writing Confstruct.new as a wrapper for Confstruct::Configuration.new would be dead simple (and probably worth doing).
3. Confstruct was written to replace another configuration gem I wrote that had declaration in it. The previous effort wasn't suiting our internal need for flexibility, and my ability to write and release gems is funded by my ability to make them relevant and applicable to my day job.
4. Confstruct::Configuration presents no obstacles to subclassing. That's how we use it in-house.
5. I'd love to simplify the Confstruct code, as long as I don't have to compromise on any of the "magic configuration DSL" features it currently provides (especially post-config and deferred evaluation callbacks).
6. I totally agree. But I also see a lot of value in having multiple choices with different features. Confstruct and Construct aren't by any means the only two configuration gems in the Ruby space, nor are they the only two Hash+Struct providers around. They just happen to be the ones with the most similar names. ;-)

If there's a good case to be made for collaboration, I'm all for it. Especially if it comes with pull requests and documentation. :-)