Talk:Trait (computer programming)

Proposed Deletion

edit

I would propose this article be merged into Abstract Types rather than sitting on its own. Traits are a behavoir variant of abstract types. EvanCarroll (talk) 20:04, 23 June 2009 (UTC)Reply

That's like merging shark with animal. The abstract type article links to but does not incorporate the Interface (computer science), Trait (computer science), and mixin articles, and that's as it should be. -- 98.108.210.171 (talk) 09:24, 30 October 2010 (UTC)Reply

"Traits come from the Self programming language" <-- evidence? Schaerli et al at the SCG implemented traits in Smalltalk (Squeak 3.9, to be precise). --Frank Shearar (talk) 20:07, 28 July 2011 (UTC)Reply

"Traits come from the Self programming language" <-- I think this is wrong. self does have a thing conventionally called "traits" but it not the same kind of thing as this page is speaking of. — Preceding unsigned comment added by 64.186.37.5 (talk) 20:35, 28 July 2011 (UTC)Reply

"Traits come from the Self programming language" <-- I coined the term "trait", in this usage, as a developer/manager on the Xerox "Star" in 1979/80. Object-orientation, classes and traits were implemented as coding patterns over the system language Mesa. Conceptually, they were atomic packages of methods, antecedent to "class". Concept was influenced by ideas from Smalltalk/multiple inheritance and polymorphism at PARC. Fine grained reuse seemed necessary for Star because the target operating environment was so small (e.g., .5MB-.75MB main memory). I published a Xerox PARC "blue-and-white" report on traits in 1981/2, and published at SIGOA the following year [1] GCurry (talk) 21:36, 10 October 2011 (UTC)Reply

I support GCurry's comment above. I've discussed this with the researchers who implemented traits in Smalltalk and they said Gael Curry and Xerox Star is where traits began (source is personal email discussion). They also point to: G. Curry, L. Baer, D. Lipkie, and B. Lee. Traits: An approach to multiple-inheritance subclassing. In SIGOA conference on Office Information Systems, pages 1–9, Philadelphia, Pennsylvannia, USA, 1982. ACM Press"" --Overseasexile (talk) 20:11, 27 January 2013 (UTC)Reply

References

  1. ^ Traits: An Approach to Multiple-Inheritance Subclassing; GCurry et al; Philadelphia; June 1982

Trait with variables?

edit

"Does not specify any state variables."

Really? Some Scala traits do: http://ideone.com/U1gIx

It is funny that Scala is listed in examples of such languages, although Scala's traits are different from described traits. — Preceding unsigned comment added by V6ak (talkcontribs) 11:38, 7 June 2012 (UTC)Reply

Most people understand traits from the Smalltalk research in this field and the original Smalltalk implementation specifically excluded traits having state. Since then the researchers realized this was an error, but I don't believe there's been any definitive method (no pun intended) of describing how state should be implemented. --Overseasexile (talk) 19:53, 27 January 2013 (UTC)Reply

There are several extensions dealing with adding state to traits (though it seems this is a recent development). I've added a reference to AmbientTalk, which offers a homogeneous way to handle state and visibility of variables. Diego (talk) 12:45, 28 January 2013 (UTC)Reply

On this topic, I find it quite confusing as a reader to introduce traits by saying they don't usually carry state and conclude with a PHP example that actually does — 82.150.248.37 (talk) 13:28, 12 October 2015 (UTC)Reply

Groovy, Ruby, and JavaScript also support state variables. — Preceding unsigned comment added by 98.122.140.237 (talk) 17:46, 15 February 2016 (UTC)Reply

Traits and Parametric Polymorphism

edit

After reading through this article, and looking at the examples, this seems to be describing what is called "parametric polymorphism" in other theoretical circles. I'm having trouble distinguishing between the two: they seem to be the same thing, as best as I can tell. If there are differences, could some examples be given? If it really is the same concept, just explained differently, could some explanations be added to that effect? 67.198.37.16 (talk) 16:07, 30 December 2021 (UTC)Reply

Removing the "too technical" maintenance template

edit

I would like to remove the "too technical" maintenance template. I have added a very simple (for programmers) opening paragraph to the "Characteristics" section. It explains in simple language what traits do and why they do it. The too technical "how" is explained later (if that's still too technical, I can work on that, too). However, I'm loathe to simply remove the maintenance template because I don't do a lot of editing here and I'd prefer someone else (familiar with programming) to review my work and comment on it. Overseasexile (talk) 17:09, 30 September 2022 (UTC)Reply

@Overseasexile and Fred Gandt: This cleanup tag was added to the article many years ago. Does the article still describe concepts that are too technical for readers to understand? Jarble (talk) 22:38, 30 January 2024 (UTC)Reply
Wow; 2012. We were so young ;) The article has changed a lot since that tag was added, so I just gave it a quick, fresh look and frankly it would still make little sense to a non expert. I'm not suggesting that it's worse than other articles on technical or niche subjects. WP:TECHNICAL gives simple guidance on how to present this kind of article, and TL;DR (the nutshell), we should:

strive to make each part of every article as understandable as possible to the widest audience of readers who are likely to be interested in that material.

I don't think it's unreasonable to suspect that a majority of readers will be here trying to learn about the concept rather than experts simply being interested in Wikipedia's coverage. There's a very short lead, so currently the rationale is doing the heavy lifting of introducing the subject; the first two sentences fly out of the corner swinging with:

In object-oriented programming, behavior is sometimes shared between classes which are not related to each other. For example, many unrelated classes may have methods to serialize objects to JSON.

Anyone who doesn't already know what all that means is going to be knocked out cold. The argument that interested-but-unfamiliar readers can click various links, or do their own searches to figure out what this article is trying to explain should never be offered. As an experienced and multilingual code wrangler, I know what this is talking about, but have seen this far too often in technical documentation, written in such a way that it can only be understood by people who already understand it; we need to make allowances for those who don't understand it. This is not to say that it should be dumbed down or that we should explain it like the readers are five.
Look at the lead of the PHP documentation:

PHP implements a way to reuse code called Traits.

Traits are a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance by enabling a developer to reuse sets of methods freely in several independent classes living in different class hierarchies.

It introduces the concept in a short, plain English sentence. Then terms like "single inheritance", "methods" and "classes" are mixed into plain English such that they are relatively understandable by their common meanings. If the distinction of single inheritance is cleared up, even a layman could get the gist. Perhaps we could aim for something more akin to that style/language?
It's 5 am and feels like it, so I'll take my leave here. I won't throw a hissy fit if the maintenance tag is removed but I do think some clarification for readers who aren't already familiar with the subject would still massively improve the article. Fred Gandt · talk · contribs 05:16, 1 February 2024 (UTC)Reply