-
Notifications
You must be signed in to change notification settings - Fork 52
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
Support field dependencies #14
Comments
There are two ways to do this:
While the second option seem more intuitive, I prefer the first option due to technical limitations:
|
I had been assuming the first option. The second option would definitely be much, much messier technically, and would make life hard in IDEs and native error messages, and really scramble the docs on the builder type (which I value). BTW, I’m quite happy to implement this myself. |
I have need for this exact case too. |
@idanarye Can I try this? Sorry for spam with these questions, but it is frustrating to realize that the maintainer is not welcoming some PR after you have submitted it. Therefore I always ask first :) |
I thought about it and
This means that we have Let's say we remove
|
Note that
|
WOW, I did not think about that! |
I did think about it for many hours and I do finally have results! Let's look at
This means that The rows (except the first one) are the needed implementations.
Now let's take a look at
Problem: We can not replace both This case has two solutions. But first, let's think about how these "implementation boards" are built.
After all
Now, cast a diagonal "
This is one solution! The other solution which reduces the number of implementations is to sort the rows first based on their number of
Now we cast one "shadow" and we are done:
We know what problems we can get with combined Well, I have written an algorithm to test that: https://codeberg.org/mo8it/sus-impls |
@idanarye I think that I did close all bugs in my algorithm
I have tests even with implementations on real Rust traits to make sure that there are no conflicts. It is possible that some weird case is not covered. Would it be possible to implement it and say in the release notes that it is kind of in beta? The algorithm can be used for #6 too! |
A few words on how it works? Are you normalizing the condition? |
I did start explaining the algorithm in the README. I will ping you when it is done. Why would a normalization be needed? My plan was to check for conflicts in the input and error after finding one. An example for an input conflict is
I did implement that check today. |
It may be an overkill, but a normalization can potentially just remove these conflicts instead of rejecting them. |
I admit though that I hadn't study the algorithm yet, so I don't know how complicated it is. And I don't see an already existing crate for it. |
I could remove the conflicts without normalization. But I don't think that the additional performance cost is worth it. I don't see why we should allow writing conflicting rules in the first place. I would even go that far to think about adding a crate feature to optionally disable that input conflicts check because it is |
The documentation is finally done and I did fix some more bugs! I have been working on this algorithm for more than a week :D I did underestimate this issue xD You can read the README and try out the algorithm by running the binary as described: https://codeberg.org/mo8it/sus-impls @idanarye I am waiting for your feedback before starting a PR to use the algorithm in this crate. How do we want to integrate the algorithm? Do we keep it as a separate crate or do we just add it to this one as a subcrate? The AGPL3 license is conflicting, right? I would downgrade it for this crate :/ |
Yea, I'd rather keep this crate copyleft-free. |
I wrote and documented the algorithm. The license is compatible. I also started a draft PR. I just have to sit down and finish that PR 😅 |
My bad for the pressure. Simply expressing it didn't have to be copyleft :-) didn't mean to rush anyone haha |
I tried to get back to it again but it would require some time to get comfortable with the macros again. Therefore, I closed the PR #96 to not let you wait even longer and would ask @idanarye if he wants to implement it in typed-builder. I am ready to help on the |
As a concrete example, when creating a customer in the Stripe API, there’s an argument
tax_percent
that is only permitted ifplan
has also been set. It is an error to settax_percent
ifplan
isn’t set, so it’s best to statically enforce that where possible.I picture code looking like this:
As schemed here, setting
requires
simply means “you are not permitted to override the default unless this field has been set”. Thus allrequires
things would needdefault
ordefault_code
.An alternative scheme would allow you to specify different defaults depending on whether the required field was defined or not, e.g. replace
default{,_code}
withdependency_not_met_default{,_code}
anddependency_met_default{,_code}
(strawman names selected for lack of ambiguity).This would work very well in conjunction with #6, extending “requires” to support arbitrary groups (named, or with
any()
&c. as in my comment there just now).The text was updated successfully, but these errors were encountered: