StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
10329611
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2012-04-26T08:18:01.133
FavoriteCount
0
LastActivityDate
2014-02-11T19:36:50.207
LastEditDate
2014-02-11T19:36:50.207
LastEditorUserId
88406
OwnerUserId
249855
ParentId
5241219
PostTypeId
2
Score
2
ViewCount
0
LastEditorDisplayName
text
Body
One key different between mixins and traits is that mixins have fields, whereas traits do not. Paraphrasing from the original paper, a trait: <ul> <li>provides methods that implement behavior</li> <li>requires methods that parameterize the provided behavior</li> <li>do not specify or access any fields</li> <li>are symmetrically composed</li> <li>can be nested, equivalent to flattened traits</li> </ul> At first glance the third point looks like it is broken in the Scala implementation. However, traits can only access public fields, which are protected by implicit getters and setters. The paper goes on to describe that this is acceptable for the implementation of traits. You point out that a key feature of traits is that methods can be renamed when you import them. This is not possible given the constraints of the JVM. A coherent discussion of this can be found here: <a href="http://scala-programming-language.1934581.n4.nabble.com/Trait-method-aliasing-td2322026.html" rel="nofollow">http://scala-programming-language.1934581.n4.nabble.com/Trait-method-aliasing-td2322026.html</a>, particularly the posts by David Pollak. Finally, my answer to your general question is "sort of". To elaborate, whilst Scala traits are not strictly traits as defined by the paper, they are not strictly mixins either. Either way, it is probably best to use them like they were traits and keep to their design principles. <ul> <li>Keep them small, with the intent of reusing them. </li> <li>Specify behavior not state.</li> </ul>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POHow are Scala's traits not really traits?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USsquarism
UserOwnerUserId
1. USSteve McDowell
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POHow are Scala's traits not really traits?
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.