2012/10/9 Lindsey Kuper <[email protected]> > And, in case nobody has pointed them out yet, here are a couple more resources: > * An introduction to traits on Patrick's blog: http://pcwalton.github.com/blog/2012/08/08/a-gentle-introduction-to-traits-in-rust > * A talk I did in August, with a side-by-side Haskell/Rust > comparison: https://air.mozilla.org/rust-typeclasses > Cheers,
Thank you for the references Lindsey. 2012/10/9 Joe Groff <[email protected]> > One minor non-semantic, non-scientific benefit of OOP syntax over > Algol-style function application syntax is that it's syntactically > more composable—compare `a.foo().bar().bas()`, which reads > left-to-right and composes to the right, to `bas(bar(foo(a)))`, which > reads inside-out and requires bracketing on both sides of an inner > experssion to compose calls. (Of course this only works if your APIs > are designed up front in a "fluent" way, and isn't quite as flexible > as what you can do with combinators in ML or Haskell.) I'm a math guy so to me syntax `bas(bar(foo(a)))` is natural. Besides as you noticed yourself this only work in certain circumstances. For example when you have additional parameters, the syntax could sometime be something like `c.bar(a.foo(b)).bas()` which is less readable in my opinion than `bas(bar(c, foo(a, b)))`. But all this is very subjective, isn't it ? 2012/10/9 Sebastian Sylvan <[email protected]> > I think there are two other benefits. The first is intellisense/code > completion. Type "foo." and get a list of all methods in scope with a > matching self type. This can be a massive productivity boost as it > basically puts all your code and documentation in the IDE in a context > sensitive way. Much harder to do this if you have to remember the name > of the method before you see anything. I agree that it's easier to start from a variable existing in the context rather than from a namespace or from a function name. But completion does not necessarily have to insert code after the considered identifier, even if it is indeed more usual. > Second, and much more subjectively, I think there's a difference > between sort of value oriented programming, and the more low level > mutable programming type where you're dealing with "objects" that have > identity and complicated invariants. Subjective, but tying the methods > to the data type in those cases "feels" okay to me because they kinda > are inseparable in practice, so they might as well be syntactically > tied together as well (with a more functional style you would group > them by modules and visibility, but syntactically it doesn't look like > an indivisible "object" that have a small set hard-wired built in > methods on it as opposed to a value and a random grab bag of > operations that happen to have matching types but could be written by > any old schmuck and not necessarily "part of the object"). This is precisely the subjective feeling I don't agree with. This feeling only exists because you think of processes/functions/methods as part of a single object rather than interactions between a group of objects. This is a very "Aristotelician" view. It sometimes work well (when object can be seen like "active" autonomous entities) but not in the general case IMHO. 2012/10/9 Nathan <[email protected]> > It does not make sense. Think about a general add interface. It's > type could be like the following (I am still fuzzy on rust's memory > location/lifetime type modifiers, so here I assume T is somehow > copy-by-value): > > add( a: T, b: T ) -> T > > There's nothing special about a compared to b, and also the return > type is the same type. If we could generalize this to an interface > called "Addable", then a single implementation would exist for a given > type, and there'd be nothing special about which argument position(s) > have that type. Hem ... So this mean we agree right ? My point was precisely that this does not make sense. The syntax need not to give one of the arguments a specific role. > The common OO idiom you allude to specifically ties interface, data > accessibility, and namespace together. That's a particular choice. > You are right that these can be decoupled. > > I'm personally a fan of "fewer ways to do it; less flexibility", so I > like nailing down a namespace and data accessibility for example. Or > for another example, I'm a fan of "the namespace must correlate > directly to the file path in some manner" versus having those > decoupled. I may only partly agree. I too prefer Bertrand Meyer's "A programming language should provide one good way of performing any operation of interest; it should avoid providing two." to Larry Wall's "There's more than one way to do it". But this only apply to perfectly equivalent contructs. If there is several way to do related but distinct things, I found flexibility better. > But that's just me, and I see more flexibility in rust. I'm not > certain but I think data accessibility may be tied to namespaces > (which are decoupled from filenames somewhat), as well as types, so > maybe it already has the flexibility you describe? In all the docs I've read until now, the word "private" only appeared in the section for classes, so I guess no. > This is intriguing, but not as general as multi-parameter type > classes. Consider an interface for two types, A and B, like this: > > insert( elem: A, container: B ) -> void; > peek( container: B ) -> Option<A>; > > There's no (A,B) parameter or return type anywhere. That would fit > into insert(), but it would not make sense for peek, where I have no B > at hand. This is definite the kind of interface/trait I would like to be express in Rust. But apparently it is not possible with the current design. 2012/10/9 Bennie Kloosteman <[email protected]> > Multiple parameter are very useful eg a collection and a second type , > but it gets messy... it works ok provided its in a single compilation > unit but else you get compilation unit dependency loops ,with generics > ( which are similar) you can auto generate new libs to handle this > not sure about rust traits.. Hi Ben. I'm not sure to understand the link with compilation loop. Any previous discussion on this topic? So in conclusion, this means multiple parameter traits are not planned to be implemented in Rust ? right ? -- Eddy Cizeron
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
