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" <andres.osin...@gmail.com> 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 <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
>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
