It would be audacious to propose this as a change; I'm merely trying to understand the philosophy behind certain design decisions,
My personal motivation comes from an interest in seeing how expressive Rust can be as a language to model business objects; I think the intersection between high-level logic and type classes with low-level access, extreme efficiency, and deterministic memory access, is a very interesting domain which, thus far, no language manages to handle well, and Rust shows immense promise in that. Something I really dislike and consider a huge antipattern is the question of logical indirection and boilerplate; anything that hinders the understanding of the code through unnecessary invocations or synax is a big no-no for me (a great example being Java's requirement for type declarations everywhere and the disgusting use of accessor methods everywhere even when they make no sense). Rust is a very lean language and seems to be extremely concise for what it's capable of. And the thing is, if a trait has a data dependency rather than a behavior (method existence) dependency, then why are we working around the data through methods when it just happens to be that what we really want is to fetch the data in a struct with no logical intermediaries, regardless of whether the compiler turns that into a straight memory access? The first use case that came to mind was when I was attempting to create a business object library that could be used a starting point for forms, data persistency, serialization, validation, and the like. I wanted to define, for a model, a series of validators that would depend on the struct definition; something easy to do with Enums and macros. However when it came to validation, i wanted to store certain conditions in a data structure, such that all models have a validate() method that would query the data needed to perform validation. The current trait implementation would require me to needlessly define a getter/setter for the validation data structure in order to have a trait. In reality, i just want to define the trait as a the existence of a certain struct member data definition (a corresponding validators data structure), with no limits in how I may want to access of modify such data. The beauty of this would be that i would only need to define said member and trait in order to get all the features i could ever want out of a validation library, and default methods would take care of the rest, whereas as it's now, i would have to define the accessors, or use a macro so that any model definition would come with an automatic accessor definition. This is not ideal if I have a system with several hundred models, which may be trivial in their definition but require a useless method definition for each of them. And while I think it's great that a macro is capable of that, it seems to me that as a language feature it would be substantially more useful. Like I said before, I'm just toying around; I have little frame of reference as to whether there are hidden downsides to such a feature. I just wanted to know what the community thinks about this. Thanks Enviado desde mi BlackBerry de Movistar (http://www.movistar.com.ar) -----Original Message----- From: "Felix S. Klock II" <[email protected]> Date: Fri, 20 Sep 2013 13:41:02 To: Andres Osinski<[email protected]> Cc: [email protected]<[email protected]> Subject: Re: [rust-dev] Struct members in trait definitions Andres (cc'ing rust-dev)- An initial question, since I'm not clear on one thing: What is your goal in proposing this change? That is, is your primary concern that you dislike writing either method invocations or method definitions? Or are you concerned about the ability of the compiler to optimize the generated code if one uses methods instead of struct fields? ---- Justifications for why traits should be expressed in terms of associated methods, not associated fields (and thus why Rust does things this way): 1.) Method definitions are strictly more general than fields, in terms of allowing other implementations to dynamically compute the value, read it from a database, from an input stream, etc). I assume you already are aware of this, and just want to know why we don't provide special handling for Trait designers willing to rule out such generality up-front. 2.) Associated struct-fields would either disallow mixing traits whose names collide, or would require extending the `impl` item syntax with a struct-field renaming feature. Elaboration of point 2: Traits are designed to be mixed together; the language should discourage patterns that make mixing traits on a single type difficult. The fields of a struct are written down with the `struct` definition. The associated methods for an implementation are written down with the `impl` item. If two traits require the same kind of associated state, right now you would give them identical method names, and the one struct could implement both traits (i.e. mixing them) with no ambiguity. If traits were to define struct names, to get the same amount of generality we would need to provide some way to map the field name of the struct to the name expected by the trait within `impl` items. But why do that? A method definition is a perfectly reasonable way to express this. ---- Concrete illustration of point 2 above: How would you express the below in your proposal, assuming that *both* T1 and T2 are revised to require `state` to be a member field rather than a method? ```rust trait T1 { fn state(&self) -> int; } trait T2 { fn state(&self) -> int; } struct one_int { state: int } struct two_ints { state: int, state2: int } impl T1 for one_int { fn state(&self) -> int { self.state } } impl T2 for one_int { fn state(&self) -> int { self.state } } impl T1 for two_ints { fn state(&self) -> int { self.state } } impl T2 for two_ints { fn state(&self) -> int { self.state2 } } ``` ---- Again, to be clear: I'm not saying its impossible to express the example above via hypothetical Traits with fields. But I think it would add unnecessary complexity (e.g. extensions to `impl` item syntax). So that's why I wanted to know what the driving motivation here is. If the motivation is concern over syntactic overhead: method invocations vs field deference seems trivial. The method definitions are more annoying boilerplate code, but I imagine that one could write an easy macro_rules! for the common case where the Trait method name is the same as the struct field name. If the motivation is concern over the quality of the generated code: I assume that LLVM does a good job inlining these things. (If I'm wrong about that, I'd like to know.) Cheers, -Felix On 20/09/2013 13:02, Andres Osinski wrote: > Hi all, I have a question which I'm sure must have already been > discussed and dealt with, but I wanted to understand the design > rationale: > > A lot of trait-level functionality would be enhanced if a trait could > specify members to be included in the struct which implements the > trait. This can be solved in practice by wrapping member access in > accessor methods, but I fail to see why that would be preferable. > > The reason I'm asking is because I'm trying to design data structures > which contain a couple of arrays, and I wanted to define the trait by > not only a set of supported operations but by the existence of both > arrays so that a default method could deal with any struct which > implements the trait, instead of having to define for every struct an > accessor method for each structure and then have to call the accessors > in the trait to do anything. > > Thanks > > -- > Andrés Osinski > http://www.andresosinski.com.ar/ > > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev -- irc: pnkfelix on irc.mozilla.org email: {fklock, pnkfelix}@mozilla.com
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
