Re: [rust-dev] Trait container return types
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 `@Fieldint`. 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 FieldT {
fn name() - ~str;
fn get_validators() - ~[ValidatorT];
fn get(self) - T;
fn is_valid(self) - bool;
}
trait Model {
fn get_fields(self) - ~[@Field];
fn validate(self) - OptionHashMap~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
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Trait container return types
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 FieldT 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 `@Fieldint`. 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 FieldT {
fn name() - ~str;
fn get_validators() - ~[ValidatorT];
fn get(self) - T;
fn is_valid(self) - bool;
}
trait Model {
fn get_fields(self) - ~[@Field];
fn validate(self) - OptionHashMap~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
Re: [rust-dev] Trait container return types
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 FieldT 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.infowrote:
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 `@Fieldint`. 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 FieldT {
fn name() - ~str;
fn get_validators() - ~[ValidatorT];
fn get(self) - T;
fn is_valid(self) - bool;
}
trait Model {
fn get_fields(self) - ~[@Field];
fn validate(self) - OptionHashMap~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
Re: [rust-dev] Trait container return types
Can you have the definition be: fn get_fieldsT(self) - ~[@FieldT];?
--
Ziad
On Sun, Dec 15, 2013 at 3:13 AM, Andres Osinski andres.osin...@gmail.comwrote:
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.eduwrote:
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 FieldT 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.infowrote:
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 `@Fieldint`. 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 FieldT {
fn name() - ~str;
fn get_validators() - ~[ValidatorT];
fn get(self) - T;
fn is_valid(self) - bool;
}
trait Model {
fn get_fields(self) - ~[@Field];
fn validate(self) - OptionHashMap~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
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
