Content deleted Content added
Jerryobject (talk | contribs) WP:REFerence WP:CITation parameters: adds, fills, reorders, respaces, update-standardizes. WP:LINKs: needless WP:PIPEs > WP:NOPIPEs, update-standardizes, underscores > spaces, adds. WP:COPYEDITs WP:EoS: WP:TERSE, clarify. Template:Quote, Template:Main article updates > Template:Blockquote, Template:Main. MOS:FIRSTABBReviation define before WP:ABBR. Cut needless carriage return in paragraphs. WP:SLASHes > comma+space. |
Jerryobject (talk | contribs) m Cut needless whitespace characters, carriage returns, in sections: standardize, aid work via small screens. |
||
Line 34:
Such software entities are known as ''generics'' in [[Ada (programming language)|Ada]], [[C Sharp (programming language)|C#]], [[Delphi (software)|Delphi]], [[Eiffel (programming language)|Eiffel]], [[F Sharp (programming language)|F#]], [[Java (programming language)|Java]], [[Nim (programming language)|Nim]], [[Python (programming language)|Python]], [[Go (programming language)|Go]], [[Rust (programming language)|Rust]], [[Swift (programming language)|Swift]], [[TypeScript]], and [[Visual Basic .NET]]. They are known as ''[[parametric polymorphism]]'' in [[ML (programming language)|ML]], [[Scala (programming language)|Scala]], [[Julia (programming language)|Julia]], and [[Haskell]] (Haskell terminology also uses the term "generic" for a related but somewhat different concept).
The term "generic programming" was originally coined by [[David Musser]] and [[Alexander Stepanov]]{{sfn|Musser|Stepanov|1989}} in a more specific sense than the above, to describe a programming paradigm whereby fundamental requirements on data types are abstracted from across concrete examples of algorithms and [[data structure]]s and formalized as [[Concept (generic programming)|concepts]], with [[generic function]]s implemented in terms of these concepts, typically using language genericity mechanisms as described above.
== Stepanov–Musser and other generic programming paradigms ==
Generic programming is defined in {{harvtxt|Musser|Stepanov|1989}} as follows,
{{Blockquote
Line 81 ⟶ 79:
===In object-oriented languages===
When creating container classes in statically typed languages, it is inconvenient to write specific implementations for each datatype contained, especially if the code for each datatype is virtually identical. For example, in C++, this duplication of code can be circumvented by defining a class template:
<syntaxhighlight lang="Cpp">
Line 115 ⟶ 112:
====Generics in Ada====
[[Ada (programming language)|Ada]] has had generics since it was first designed in 1977–1980. The standard library uses generics to provide many services. Ada 2005 adds a comprehensive generic container library to the standard library, which was inspired by C++'s [[standard template library]].
Line 125 ⟶ 121:
=====Example=====
The specification of a generic package:
Line 180 ⟶ 175:
=====Advantages and limits=====
The language syntax allows precise specification of constraints on generic formal parameters. For example, it is possible to specify that a generic formal type will only accept a modular type as the actual. It is also possible to express constraints ''between'' generic formal parameters; for example:
Line 195 ⟶ 189:
Unlike C++, Ada does not allow specialised generic instances, and requires that all generics be instantiated explicitly. These rules have several consequences:
* the compiler can implement ''shared generics'': the object code for a generic unit can be shared between all instances (unless the programmer requests inlining of subprograms, of course). As further consequences:
** there is no possibility of code bloat (code bloat is common in C++ and requires special care, as explained below).
Line 257 ⟶ 250:
There are four primary drawbacks to the use of templates: supported features, compiler support, poor error messages (usually with pre C++20 [[Substitution failure is not an error|SFINAE]]), and [[code bloat]]:
# Templates in C++ lack many features, which makes implementing them and using them in a straightforward way often impossible. Instead programmers have to rely on complicated tricks which leads to bloated, hard to understand and hard to maintain code. Current developments in the C++ standards exacerbate this problem by making heavy use of these tricks and building a lot of new features for templates on them or with them in mind.
# Many compilers historically had poor support for templates, thus the use of templates could have made code somewhat less portable. Support may also be poor when a C++ compiler is being used with a [[Linker (computing)|linker]] that is not C++-aware, or when attempting to use templates across [[Library (computer science)#Shared libraries|shared library]] boundaries.
Line 268 ⟶ 260:
====Templates in D====
The [[D (programming language)|D]] language supports templates based in design on C++. Most C++ template idioms
▲The [[D (programming language)|D]] language supports templates based in design on C++. Most C++ template idioms carry over to D without alteration, but D adds some functionality:
* Template parameters in D are not restricted to just types and primitive values (as it was in C++ before C++20), but also allow arbitrary compile-time values (such as strings and struct literals), and aliases to arbitrary identifiers, including other templates or template instantiations.
* Template constraints and the <code>static if</code> statement provide an alternative to respectively C++'s [[Concepts (C++)|C++ concepts]] and <code>if constexpr</code>.
Line 309 ⟶ 299:
=====Code generation=====
In addition to template metaprogramming, D also provides several features to enable compile-time code generation:
* The <code>import</code> expression allows reading a file from disk and using its contents as a string expression.
* Compile-time reflection allows enumerating and inspecting declarations and their members during compiling.
Line 338 ⟶ 326:
====Genericity in Eiffel====
Generic classes have been a part of [[Eiffel (programming language)|Eiffel]] since the original method and language design. The foundation publications of Eiffel,<ref>''Object-Oriented Software Construction,'' Prentice Hall, 1988, and ''Object-Oriented Software Construction, second edition,'' Prentice Hall, 1997.</ref><ref>''Eiffel: The Language,'' Prentice Hall, 1991.</ref> use the term ''genericity'' to describe creating and using generic classes.
Line 385 ⟶ 372:
====Genericity in .NET [C#, VB.NET]====
Generics were added as part of [[.NET Framework#.NET Framework 2.0|.NET Framework 2.0]] in November 2005, based on a research prototype from Microsoft Research started in 1999.<ref>[https://docs.microsoft.com/en-us/archive/blogs/dsyme/netc-generics-history-some-photos-from-feb-1999 .NET/C# Generics History: Some Photos From Feb 1999]</ref> Although similar to generics in Java, .NET generics do not apply [[type erasure]],{{sfn|Albahari|2022}}{{rp|208-209}} but implement generics as a first class mechanism in the runtime using [[Reification (computer science)|reification]]. This design choice provides additional functionality, such as allowing [[Reflective programming|reflection]] with preservation of generic types, and alleviating some of the limits of erasure (such as being unable to create generic arrays).<ref>[https://www.ondotnet.com/pub/a/dotnet/2005/10/17/interview-with-anders-hejlsberg.html C#: Yesterday, Today, and Tomorrow: An Interview with Anders Hejlsberg]</ref><ref>[https://www.artima.com/intv/generics2.html Generics in C#, Java, and C++]</ref> This also means that there is no performance hit from runtime [[Type conversion|casts]] and normally expensive [[Boxing (computer science)|boxing conversions]]. When primitive and value types are used as generic arguments, they get specialized implementations, allowing for efficient generic [[Collection class|collections]] and methods. As in C++ and Java, nested generic types such as Dictionary<string, List<int>> are valid types, however are advised against for member signatures in code analysis design rules.<ref>[https://msdn.microsoft.com/en-us/library/ms182144.aspx Code Analysis CA1006: Do not nest generic types in member signatures]</ref>
Line 607 ⟶ 593:
===Functional languages===
====Genericity in Haskell====
The [[type class]] mechanism of [[Haskell]] supports generic programming. Six of the predefined type classes in Haskell (including <code>Eq</code>, the types that can be compared for equality, and <code>Show</code>, the types whose values can be rendered as strings) have the special property of supporting ''derived instances.'' This means that a programmer defining a new type can state that this type is to be an instance of one of these special type classes, without providing implementations of the class methods as is usually necessary when declaring class instances. All the necessary methods will be "derived" – that is, constructed automatically – based on the structure of the type. For example, the following declaration of a type of [[binary tree]]s states that it is to be an instance of the classes <code>Eq</code> and <code>Show</code>:
Line 668 ⟶ 653:
====Clean====
[[Clean (programming language)|Clean]] offers generic programming based [[#PolyP|PolyP]] and the [[#Generic Haskell|Generic Haskell]] as supported by the GHC ≥ 6.0. It parametrizes by kind as those but offers overloading.
|