Re: [rust-dev] Object orientation without polymorphism
I think it's possible to implement methods on a struct directly, without a trait in between. On 23 October 2012 13:17, Henri Sivonen hsivo...@iki.fi wrote: Now that classes are gone, what’s the right way to group a bunch of fields and methods when polymorphism is not needed? That is, if I have a struct with some fields, some constants that make sense in the context of that struct and some methods that operate on the struct, how should I group them when there is no need for inheritance? Basically, is there a guide for migrating away from classes? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ ___ 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] Object orientation without polymorphism
On Tue, Oct 23, 2012 at 3:20 PM, Lucian Branescu
lucian.brane...@gmail.com wrote:
I think it's possible to implement methods on a struct directly,
without a trait in between.
This does not compile:
struct Foo {
x: i32,
y: i32,
fn bar() {
},
}
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Object orientation without polymorphism
On 10/23/2012 02:20 PM, Lucian Branescu wrote:
I think it's possible to implement methods on a struct directly,
without a trait in between.
Indeed, like this:
struct Storage {
...
}
impl Storage {
fn listen() {
...
}
}
- Tim
On 23 October 2012 13:17, Henri Sivonen hsivo...@iki.fi wrote:
Now that classes are gone, what’s the right way to group a bunch of
fields and methods when polymorphism is not needed?
That is, if I have a struct with some fields, some constants that make
sense in the context of that struct and some methods that operate on
the struct, how should I group them when there is no need for
inheritance?
Basically, is there a guide for migrating away from classes?
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
___
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
--
Tim Taubert
Firefox Engineer
ttaub...@mozilla.com
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Object orientation without polymorphism
Something like this
http://pcwalton.github.com/blog/2012/08/08/a-gentle-introduction-to-traits-in-rust/
On 23 October 2012 13:23, Henri Sivonen hsivo...@iki.fi wrote:
On Tue, Oct 23, 2012 at 3:20 PM, Lucian Branescu
lucian.brane...@gmail.com wrote:
I think it's possible to implement methods on a struct directly,
without a trait in between.
This does not compile:
struct Foo {
x: i32,
y: i32,
fn bar() {
},
}
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
___
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] Object orientation without polymorphism
On Tue, Oct 23, 2012 at 3:24 PM, Tim Taubert ttaub...@mozilla.com wrote:
struct Storage {
...
}
impl Storage {
fn listen() {
...
}
}
Thanks.
Is there a way to scope constants under the namespace of a struct?
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Object orientation without polymorphism
Lucian Branescu a écrit :
Something like this
http://pcwalton.github.com/blog/2012/08/08/a-gentle-introduction-to-traits-in-rust/
Very nice introduction. The only question that arises for me (coming from
c++ ground and comparing this to c++ templates) is why trait
implementation is made explicit ?
Is it a design decision or a current compiler limitation ? I guess the
compiler could not too difficultly be made smart enough to determine from
its actual interface if a type conforms to a trait. Code generation may be
more a problem, though…
Julien
On 23 October 2012 13:23, Henri Sivonen hsivo...@iki.fi wrote:
On Tue, Oct 23, 2012 at 3:20 PM, Lucian Branescu
lucian.brane...@gmail.com wrote:
I think it's possible to implement methods on a struct directly,
without a trait in between.
This does not compile:
struct Foo {
x: i32,
y: i32,
fn bar() {
},
}
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
___
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
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Object orientation without polymorphism
On 10/23/12 5:30 AM, Henri Sivonen wrote: Is there a way to scope constants under the namespace of a struct? Not at the moment. You can work around it by making the constants pure inline functions. I don't think it would be hard to add this now that we merged the type and module namespaces (this is only on git master though, not on 0.4). Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Object orientation without polymorphism
On Tue, Oct 23, 2012 at 2:46 PM, Julien Blanc wh...@tgcm.eu wrote: Lucian Branescu a écrit : Something like this http://pcwalton.github.com/blog/2012/08/08/a-gentle-introduction-to-traits-in-rust/ Very nice introduction. The only question that arises for me (coming from c++ ground and comparing this to c++ templates) is why trait implementation is made explicit ? Is it a design decision or a current compiler limitation ? I guess the compiler could not too difficultly be made smart enough to determine from its actual interface if a type conforms to a trait. Code generation may be more a problem, though… It is actually a design decision, quite similar to how typeclass in Haskell require explicit instantiation whereas Go's interfaces, like C++ templates, do not. Automatic detection is also called duck typing: it if quacks like a duck, then it's a duck. There are two main disadvantages: - functionally, it means that you can use an object for something it has never really been meant for = just because the signatures of some functions match does not mean that their semantics match too - in terms of codegen, this might imply bloat (C++) or runtime overhead (Go) On the other hand, Haskell's approach is quite practical as long as one solves the coherence issue. -- Matthieu ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
