Hi Andres,
I'm thinking about your question from a structural typing point of view, so
let me see if an analogy from Scala (which has its own take on traits)
helps. Scala is more of an OO language than Rust is, and Scala traits can
extend classes (abstract or not), which is how it's possible for a trait to
incorporate members (what Niko just described as struct inheritance) --
but the trait itself cannot name a new member, only methods, as with Rust.
So in that regard, traits are also an awful lot like Go's interfaces, in
that they describe the interface that a value must be able to satisfy at
compile time. All three languages are structurally typed, but Go has the
fewest bells and whistles in the type system, Scala the most, and Rust
somewhere in the middle (thanks to generics and type bounds). There are
efficiency reasons for that; it's relevant that Scala is a JVM language.
This isn't a particularly concrete answer, but I hope it helps.
Cheers,
--mlp
On Fri, Sep 20, 2013 at 2:18 PM, andres.osin...@gmail.com wrote:
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)
--
*From: * Felix S. Klock II pnkfe...@mozilla.com
*Date: *Fri, 20 Sep 2013 13:41:02 +0200
*To: *Andres Osinskiandres.osin...@gmail.com
*Cc: *rust-dev@mozilla.orgrust-dev@mozilla.org
*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
