Can you have the definition be: fn get_fields<T>(&self) -> ~[@Field<T>];?
-- Ziad On Sun, Dec 15, 2013 at 3:13 AM, Andres Osinski <[email protected]>wrote: > I'll have to consider it. To be honest this is my first endeavor in > attempting to capture classic OO business object-y rules using Rust-style > traits, and evidently I have some gaps in my knowledge and how to design > around those constraints. > > > On Sun, Dec 15, 2013 at 7:52 AM, Eric Reed <[email protected]>wrote: > >> I'm on a phone so I haven't tested this, but I'd suggest removing the T >> parameter of Field and replacing uses of T with Self. In case you don't >> already know, Self is a implicit type parameter representing the type of >> self, i.e. the type you impl the trait for. Would that work for your use >> case? >> On Dec 15, 2013 2:40 AM, "Andres Osinski" <[email protected]> >> wrote: >> >>> I have not gotten around to examining the ownership issues of @-boxes - >>> I've used them because they're mentioned as the only way to do runtime >>> polymorphism - but I will definitely be looking at the Any type. >>> >>> The essential point is that, for a set of Field<T> containers, I want to >>> invoke a method whose signature does not have generic type parameters, >>> name the is_valid() method which would return a bool. >>> >>> The thing is, the specialization for Field is something that I want to >>> leave open to the user, so an Enum solution or any solution which places a >>> constraint on T is not good for my use case. I'm open to doing whatever >>> unsafe manipulations would be necessary, but unfortunately there's not that >>> much code that's been written to go around to get an example. >>> >>> >>> On Sun, Dec 15, 2013 at 7:24 AM, Chris Morgan <[email protected]>wrote: >>> >>>> The problem there is that `@Field` is not a type, because you haven't >>>> specified the value for the generic constraint T. That is, the >>>> pertinent trait object would be something like `@Field<int>`. It's not >>>> possible to have a field without the type being specified; that is, >>>> `get_fields()` can only be designed to return fields of one type >>>> (think of it this way—what will the type checker think of the value of >>>> `model.get_fields()[0].get()`? It's got to be exactly one type, but >>>> it's not possible to infer it). >>>> >>>> You'd need to deal with something like std::any::Any to achieve what >>>> it looks likely that you're trying to do. Because I wouldn't encourage >>>> designing something in that way as a starting point, I won't just now >>>> give you code covering how you would implement such a thing; see if >>>> it's possible for you to design it in such a way that this constraint >>>> doesn't cause you trouble. Using enums instead of traits is one way >>>> that can often—though certainly not always—get around this problem. >>>> >>>> One final note—avoid using @-boxes if possible; is it possible for you >>>> to give owned pointers or references? >>>> >>>> On Sun, Dec 15, 2013 at 7:24 PM, Andres Osinski >>>> <[email protected]> wrote: >>>> > Hi everyone, I'm doing a bit of Rust coding and I'm trying to build a >>>> > library to manage some common business object behavior. >>>> > >>>> > trait Field<T> { >>>> > fn name() -> ~str; >>>> > fn get_validators() -> ~[&Validator<T>]; >>>> > fn get(&self) -> T; >>>> > fn is_valid(&self) -> bool; >>>> > } >>>> > >>>> > trait Model { >>>> > fn get_fields(&self) -> ~[@Field]; >>>> > fn validate(&self) -> Option<HashMap<~str, ~[FieldError]>> { >>>> > } >>>> > >>>> > The code fails with the following compiler error: >>>> > >>>> > models.rs:80:35: 80:40 error: wrong number of type arguments: >>>> expected 1 but >>>> > found 0 >>>> > models.rs:80 fn get_fields(&self) -> ~[@Field]; >>>> > >>>> > The reason for the get_fields() method is to return a list of >>>> heterogenous >>>> > trait-upcasted objects, and for each of them I'd be invoking the >>>> is_valid() >>>> > method. >>>> > >>>> > I would understand that the compiler may not understand the notion of >>>> trait >>>> > return types (which would make sense) but I'd be interested to know >>>> whether >>>> > this is a bug or a design limitation, and in the second case, whether >>>> > there's a sensible alternative. >>>> > >>>> > Thanks >>>> > >>>> > -- >>>> > Andrés Osinski >>>> > >>>> > _______________________________________________ >>>> > Rust-dev mailing list >>>> > [email protected] >>>> > https://mail.mozilla.org/listinfo/rust-dev >>>> > >>>> >>> >>> >>> >>> -- >>> Andrés Osinski >>> http://www.andresosinski.com.ar/ >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> > > > -- > Andrés Osinski > http://www.andresosinski.com.ar/ > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
