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 <m...@chrismorgan.info> 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
> <andres.osin...@gmail.com> 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
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> >
>
--
Andrés Osinski
http://www.andresosinski.com.ar/
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
