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 <ecr...@cs.washington.edu> 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" <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
>>
>>
--
Andrés Osinski
http://www.andresosinski.com.ar/
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
