-
Notifications
You must be signed in to change notification settings - Fork 37
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
Remove Feed Builder in favor of Feed simple create function #72
Comments
@FreddieRidell I was thinking a custom builder, as we're able to have more control over it. |
Looking through the Have I understood this correctly? |
Though my memory is a bit foggy on the matter, I believe that's accurate. |
Is there an actual builder pattern? I tried to make it an Non-consuming builder, then we can write: if partial_keypair.secret.is_some() {
builder.secret_key(partial_keypair.secret.unwrap())
}
Ok(builder.build()?) But the lifetime doesn't allow it. But it is ok:
Builder-pattern is useful when build a object takes a lot of work. Maybe we can build feed directly here? I opened a pr for it. |
@ZhouHansen I'm not sure I follow. The if partial_keypair.secret.is_some() {
builder = builder.secret_key(partial_keypair.secret.unwrap())
}
Ok(builder.build()?) Maybe I'm missing something. But whatever the problem is, it seems unlikely that removing the builder in its entirety would be the solution. |
@yoshuawuyts I see the At the same time I feel it's unnecessary to use builder-pattern here, the building process of |
As part of the discussion, it seems like the Builder is an actual builder. In regards to the |
feed_builder
to use actual builder pattern
hypercore/src/feed_builder.rs
Lines 14 to 18 in 482f491
The link referenced shows a crate that offers a macro to automatically derive builders for structs. It seems like it should be relatively easy to use
derive_builder
withFeed
. Is the intention to use this macro, or write a custom builder?The text was updated successfully, but these errors were encountered: