Se il builder è fallibile dovresti avere un Result<T, E> nella funzione di build non un expect
Più che altro perchè mi devo abituare al design del codice Rust, i pattern in quanto tali li conosco (tra l'altro Refactoring guru èun'ottima risorsa a riguardo)
Читать полностью…
Guarda intanto mi dai un sito da mettere nei preferiti
Читать полностью…
Si normalmente se metti pub allora esponi pubblicamente il field in read e write
Читать полностью…
comunque il non_exhaustive viene usato anche nella std lib di rust in questo modo
Читать полностью…
si sarebbe un side effect dell'utilizzo principale
Читать полностью…
non_exhaustive da quel che leggo sembra essere un "guarda che questo potrebbe cambiare in futuro, per cui non dare per scontate cose che non lo saranno" più che "vietato istanziarlo fuori"
Читать полностью…
quindi hai la struct in read only al di fuori del crate
Читать полностью…
Si ok, ma non puoi accedere a shoes_color dopo facendo così al di fuori del module
o meglio il suo principale sembra essere differente
Читать полностью…
https://doc.rust-lang.org/reference/attributes/type_system.html#the-non_exhaustive-attribute
Читать полностью…
Si refactoring.guru anche solitamente è buono, ma non mi piace come fanno il builder pattern: https://refactoring.guru/design-patterns/builder/rust/example#example-0--builders-car-rs
Usano unwrap nel build che fà crashare il programma in caso di errori, e poi non hai bisogno di un trait Builder, ti complica solo le cose imo
L'unica cosa che ho da ridire è che io preferisco usare la signature pub fn with_bar(mut self, bar: String) -> FooBuilder invece di pub fn name(mut self, bar: String) -> FooBuilder, ma sono piccole differenze in base alla tua preferenza personale
Comunque scusate ho fatto una domanda e poi non ho risposto per due giorni haha 😅👉👈
Mi ha assorbito LLVM
Prova a dare un'occhiata al builder pattern, secondo me fa proprio al caso tuo 😉
https://rust-unofficial.github.io/patterns/patterns/creational/builder.html
Uhm, quindi sono costretto a dover specificare dal nome, non posso avere un'interfaccia "unica"?
Читать полностью…
comunque nel mio esempio shoes_color non voleva essere un proprietà fantasma, era solo un esempio a caso, ma l'evitare di costruire cose al di fuori della loro modulo è legato a comportamenti interni che non vengono esplicitati fuori, per cui è facile avere property non pubbliche
Читать полностью…
per quello ho detto per un uso ancora più avanzato
Читать полностью…
poi il secondo è una conseguenza del primo perché il compilatore è conservatore
Читать полностью…
ok, ma anche qui stai usando una semantica diversa
Читать полностью…
con #[non_exhaustive] puoi fare in modo che tutta la struct sia pubblica, ma possa essere solo costruita all'interno del crate
comunque se lasci una proprietà non pub probabilmente ottieni lo stesso effetto
Читать полностью…
non lo conoscevo, ma leggendo mi sembra serva ad altro
Читать полностью…
Ancora più avanzato, se vuoi rendere la struct pubblica ma non vuoi che si costruisca al di fuori del crate puoi usare non_exhaustive
Читать полностью…
