Constrained genericity: Difference between revisions

Ada allows various constraints to be specified in parameters of generics.

A formal type constrained to be derived from certain base is one of them:

 

package Nutrition is

subtype Food_Box is Food_Vectors.Vector;

 

The package Nutrition defines an interface of an eatable object, that is, the procedure Eat. Then a generic container package is defined with the elements to be of some type derived from Food. Example of use:

overriding procedure Eat (Object : in out Banana) is null;

package Banana_Box is new Food_Boxes (Banana);

overriding procedure Eat (Object : in out Tomato) is null;

package Tomato_Box is new Food_Boxes (Tomato);

The Tomato_Box can only contain tomatoes; the Banana_Box can only contain bananas. You can only create boxes of eatable objects.

 

Types which are eatable would have to implement the

<code>IEatable</code> interface and provide an <code>Eat</code> method.

{

void Eat();

Type constraints in type parameters can be made via the <code>where</code> keyword, which allows us to qualify T.

In this case, we indicate that the type argument must be a type

that is a subtype of <code>IEatable</code>.

 

class FoodBox<T> where T : IEatable

{

List<T> food;

For example, an eatable Apple:

{

public void Eat()

System.Console.WriteLine("Apple has been eaten");

}

C# also has the interesting functionality of being able to require that a generic type have a default constructor. This means that the generic type can actually instantiate the objects without ever knowing the concrete type. To do so, we constrain the where clause with an additional term "new()". This must come after any other constraints. In this example, any type with a default constructor that implements IEatable is allowed.

 

class FoodMakingBox<T> where T : IEatable, new()

}

}

 

=={{header|C++}}==

{{works with|C++11}}

Uses static assertion to disallow instantiations on incorrect types

struct can_eat //Detects presence of non-const member function void eat()

{

//Following leads to compile-time error

//FoodBox<brick> practical_joke;

 

=={{header|Common Lisp}}==

 

The only shortcoming here is that the compiler isn't required to enforce the type specifications for the arrays. A custom insert function, however, could remember the specified type for the collection, and assert that inserted elements are of that type.

 

(defclass inedible-food (food) ())

"Return an array whose elements are declared to be of type (and

eatable food)."

 

=={{header|Crystal}}==

Similar to Ruby version, but shows error at compile-time.

def eat

end

FoodBox.new([Apple.new, Apple.new])

FoodBox.new([Apple.new, Carrot.new])

 

{{out}}

=={{header|D}}==

===Template Version===

 

struct FoodBox(T) if (IsEdible!T) {

 

//FoodBox!Car carsBox; // Not allowed

 

===Interface Version===

 

struct FoodBox(T : IEdible) {

FoodBox!Carrot carrotBox; // OK

//FoodBox!Car carBox; // Not allowed

 

=={{header|E}}==

It is surely arguable whether this constitutes an implementation

of the above task:

def Eatable {

to coerce(specimen, ejector) {

def makeFoodBox() {

return [].diverge(Eatable) # A guard-constrained list

 

=={{header|Eiffel}}==

The "eatable" characteristic is modeled by a deferred class (deferred classes are similar to abstract classes in some other languages).

 

deferred class

EATABLE

end

end

 

Class <code lang="eiffel">EATABLE</code> can then be inherited by any other class, with the understanding that the inheriting class will have to provide an implementation for the procedure <code lang="eiffel">eat</code>. Here are two such classes, <code lang="eiffel">APPLE</code> and <code lang="eiffel">PEAR</code>:

 

class

APPLE

end

end

 

 

class

PEAR

end

end

 

Instances of the generic class <code lang="eiffel">FOOD_BOX</code> can contain any types of <code lang="eiffel">EATABLE</code> items. The constraint is shown in the formal generics part of the class declaration for <code lang="eiffel">FOOD_BOX</code>:

 

class

FOOD_BOX [G -> EATABLE]

 

end

 

So, any declaration of type <code lang="eiffel">FOOD_BOX</code> can constrain its contents to any particular eatable type. For example:

 

my_apple_box: FOOD_BOX [APPLE]

 

The entity <code lang="eiffel">my_apple_box</code> is declared as a <code lang="eiffel">FOOD_BOX</code> which can contain only apples.

Of course, constraining a particular <code lang="eiffel">FOOD_BOX</code> to all types which are eatable is also allowed, and could be appropriate in certain cases, such as:

 

my_refrigerator: FOOD_BOX [EATABLE]

 

Here's a small application that uses a <code lang="eiffel">FOOD_BOX</code> constrained to contain only apples:

 

class

APPLICATION

-- A pear

end

 

Notice that an instance of <code lang="eiffel">PEAR</code> is also created, and a line of code is present as a comment which would attempt to place the pear in the apple box:

 

-- my_apple_box.extend (one_pear)

 

If the comment mark "--" were removed from this line of code, an compile error would occur because of the attempt to violate <code lang="eiffel">my_apple_bos</code>'s constraint.

including inheritance relationships and interface implementation.

But for this task, the natural choice is an explicit member constraint.

when ^a: (member eat: unit -> string) // with an explicit member constraint on ^a,

(items:^a list) = // a one-argument constructor

 

// an instance of a Banana FoodBox

 

=={{header|Forth}}==

Needs the FMS-SI (single inheritance) library code located here:

http://soton.mpeforth.com/flag/fms/index.html

include FMS-SILib.f

:class Eatable

anapple aFoodBox add:

aFoodBox test \ => successful eat successful eat

 

=={{header|Fortran}}==

In Fortran all checkes are done at compile time, in particular a dummy argument has to conform class.

module cg

implicit none

end program con_gen

 

{{out}}

ifort -o cg cg.f90

1

Error: Type mismatch in argument 'f' at (1); passed TYPE(brick_t) to CLASS(eatable)

</pre>

 

=={{header|Go}}==

Go's interfaces do exactly what this task wants.

Eatable looks like this:

eat()

And the following is all it takes to define foodbox as a slice of eatables.

The result is that an object of type foodbox can hold objects of any type that implements the eat method (with the function signature specified in eatable.)

The definition of foodbox though, doesn't even need to enumerate the functions of eatable, much less call them. Whatever is in the interface is okay.

Here is an example of an eatable type.

 

func (f peelfirst) eat() {

// peel code goes here

fmt.Println("mm, that", f, "was good!")

The only thing it takes to make peelfirst eatable is the definition of the eat method. When the eat method is defined, peelfirst automatically becomes an eatable. We say it ''satisfies'' the interface. Notice that "eatable" appears nowhere in the definition of peelfirst or the eat method of peelfirst.

 

Here is a complete program using these types.

 

import "fmt"

f0 := fb[0]

f0.eat()

{{out}}

<pre>

=={{header|Haskell}}==

A ''type class'' defines a set of operations that must be implemented by a type:

We just require that instances of this type class implement a function <tt>eat</tt> which takes in the type and returns a string (I arbitrarily decided).

 

The <tt>FoodBox</tt> type could be implemented as follows:

The stuff before the <tt>=></tt> specify what type classes the type variable <tt>a</tt> must belong to.

 

We can create an instance of <tt>Eatable</tt> at any time by providing an implementation for the function <tt>eat</tt>. Here we define a new type <tt>Banana</tt>, and make it an instance of <tt>Eatable</tt>.

instance Eatable Banana where

We can declare existing types to be instances in the exact same way. The following makes <tt>Double</tt> an eatable type:

Another way to make an existing type eatable is to declare all instances of another type class instances of this one. Let's assume we have another type class <tt>Food</tt> which looks like this;

Then we can make all instances of Food eatable using <tt>munch</tt> for <tt>eat</tt> with the following instance declaration:

 

==Icon and {{header|Unicon}}==

In Unicon, new types can be defined as classes. The solution shown

follows the Scala approach.

 

class Eatable:Class()

if FoodBox([Fish("salmon")]) then write("Edible") else write("Inedible")

if FoodBox([Rock("granite")]) then write("Edible") else write("Inedible")

 

Sample run:

=={{header|J}}==

Implementation:

isEdible=:3 :0

0<nc<'eat__y'

collection=: collection, y

EMPTY

An edible type would be a class that has a verb with the name 'eat' (the task "eatable" requirement is checked on an object or class reference using the static method <code>isEdible_Connoisseur_</code>).

 

 

For example:

eat=:3 :0

smoutput'delicious'

And here is a quicky demo of the above:

lunch=:'' conew 'FoodBox'

a1=: conew 'Apple'

george=: conew 'Connoisseur'

add__lunch george

 

=={{header|Java}}==

Types which are Eatable would have to implement the

<code>Eatable</code> interface and provide an <code>eat</code> method.

{

void eat();

Type constraints in type parameters can be made via the <code>extends</code> keyword, indicating in this case that the type argument must be a type that is a subtype of <code>Eatable</code>.

 

class FoodBox<T extends Eatable>

{

public List<T> food;

Similarly a generic method can constrain its type parameters

This <code>T</code> does not necessarily have to be defined in the class declaration. Another method may be declared like this:

public <T extends Eatable> void bar(){ }

which has no indication of where <code>T</code> is coming from. This method could be called like this:

The <code>foo</code> method from before can figure out <code>T</code> from its parameter, but this <code>bar</code> method needs to be told what T is.

 

{{works with|Julia|0.6}}

Julia allows user defined types with inheritance. Misuse of a type generally produces a compile time error message.

eat(::Edible) = "Yum!"

 

b = Brick(125.0)

eat(c)

 

{{out}}

 

We then define a generic class, FoodBox, whose type parameter, T, is constrained to an Eatable type and instantiate it using both the Cheese and Meat types:

 

interface Eatable {

beef.eat()

println("Full now!")

 

{{out}}

{{trans|D}}

===Template Version===

 

template < T >

// var carBox: FoodBox< Car >; // Not allowed

static assert( not trait(compiles, func() { var carBox: FoodBox< Car >; } ));

 

 

===Interface Version===

 

{

public func eat(): void;

// var carBox: FoodBox< Car >; // Not allowed

static assert( not trait(compiles, func() { var carBox: FoodBox< Car >; } ));

 

=={{header|Nemerle}}==

 

interface IEatable

}

 

{{out}}

<pre>nom..nom..nom

 

=={{header|Nim}}==

Eatable = concept e

eat(e)

 

for f in fs:

 

=={{header|Objeck}}==

All generic 'T' types associated with the FoodBox must implement the 'Eatable' interface. Generic constrains may either be an interface or a sub-classed type.

 

interface Eatable {

plums : FoodBox<Plum>;

}

 

=={{header|Objective-C}}==

Types which are Eatable would have to implement the

<code>Eatable</code> protocol and provide an <code>eat</code> method.

- (void)eat;

Type constraints in type parameters can be made via the <code>:</code> keyword, indicating in this case that the type argument must be a type that is a subtype of <code>id<Eatable></code>.

 

=={{header|OCaml}}==

 

A module type defines a set of operations that must be implemented by a module:

type t

val eat : t -> unit

We just require that module instances of this module type describe a type <tt>t</tt> and implement a function <tt>eat</tt> which takes in the type and returns nothing.

 

The <tt>FoodBox</tt> generic type could be implemented as a ''functor''

(something which takes a module as an argument and returns another module):

type elt = A.t

type t = F of elt list

let make_box_from_list xs = F xs

 

We can create a module that is an instance of <tt>Eatable</tt> by specifying a type providing an implementation for the function <tt>eat</tt>. Here we define a module <tt>Banana</tt>, and make it an instance of <tt>Eatable</tt>.

 

module Banana : Eatable with type t = banana = struct

type t = banana

let eat _ = print_endline "I'm eating a banana"

 

We can also create modules that use an existing type as its <code>t</code>. The following module uses <tt>float</tt> as its type:

type t = float

let eat f = Printf.printf "I'm eating %f\n%!" f

Then, to make a FoodBox out of one of these modules, we need to call the functor on the module that specifies the type parameter:

module FloatBox = MakeFoodBox (EatFloat)

 

let my_box = BananaBox.make_box_from_list [Foo]

Unfortunately, it is kind of cumbersome in that, for every type parameter

we want to use for this generic type, we will have to explicitly create a module

Tests for identity need to be performed at runtime using mechanisms

such as the object isA method.

call dinnerTime .pizza~new

call dinnerTime .broccoli~new

return

end

{{out}}

<pre>I can't eat that!

=={{header|OxygenBasic}}==

Generic but not too generic I trust.

macro Gluttony(vartype, capacity, foodlist)

'==========================================

 

print MrG.WeightGain 'result 15.75

 

=={{header|Phix}}==

Needs 0.8.1+

=== using generic types ===

 

class foodbox

printf(1,"%s line %d error: %s\n",{e[E_FILE],e[E_LINE],e[E_USER]})

end try

{{out}}

<pre>

Of course you could trivially create a fruit-only foodbox just by changing the one line(ie 8) to add(fruit food).<br>

What is much harder(/left as an exercise) is to dynamically change those kinds of restrictions at run-time.

string name

procedure eat(); -- (virtual)

end try

lunchbox2.add(milkshake)

{{out}}

<pre>

 

=={{header|PicoLisp}}==

 

(dm eat> ()

(let (Box (new '(+FoodBox)) Eat (new '(+Eatable)) NoEat (new '(+Bla)))

(set> Box Eat) # Works

{{out}}

<pre>$384320489 -- Object is not eatable

By doing so they will be forced to implement <code>eat</code>.

 

(module+ test (require tests/eli-tester))

 

;; Show that you cannot make a food-box from the non-edible<%> semolina cannot

(implementation? semolina% edible<%>) => #f

 

All the tests pass. Look at the tests to see what generates an exception (i.e.

=={{header|Raku}}==

(formerly Perl 6)

 

class Cake { method eat() {...} }

 

my Yummy $foodbox .= new;

{{out}}

 

=={{header|Ruby}}==

def initialize (*food)

raise ArgumentError, "food must be eadible" unless food.all?{|f| f.respond_to?(:eat)}

p Foodbox.new(Apple.new, "string can't eat")

# => test1.rb:3:in `initialize': food must be eadible (ArgumentError)

 

=={{header|Rust}}==

// This declares the "Eatable" constraint. It could contain no function.

trait Eatable {

//let _fb3 = FoodBox::<bool>::new();

}

 

=={{header|Sather}}==

eat;

end;

loop box.elt!.eat; end;

end;

The GNU Sather compiler v1.2.3 let the "box2" pass, even though it shouldn't. Read e.g. [http://www.gnu.org/software/sather/docs-1.2/tutorial/parameterized1751.html this tutorial's section]

 

This specific constrain, for the type to contain a particular method,

can be written as this:

 

class FoodBox(coll: List[Eatable])

}

 

A more extensive discussion on genericity in Scala and some of the constrains

that can be imposed can be found on [[Parametric Polymorphism]].

 

=={{header|Sidef}}==

 

class Fruit { method eat { ... } }

 

say FoodBox(Fruit(), Apple()).dump #=> FoodBox(food: [Fruit(), Apple()])

 

=={{header|Swift}}==

Types which are Eatable would have to conform to the <code>Eatable</code> protocol

and provide an <code>eat</code> method.

func eat()

Type constraints in type parameters can be made via the <code>:</code> syntax, indicating in this case that the type argument must be a type that is

a subtype of <code>Eatable</code>.

var food: [T]

Similarly a generic function or method can constrain its type parameters

 

=={{header|Wren}}==

Wren is dynamically typed and so any constraint on class instantiation can only be checked at run time.

class Eatable {

eat() { /* override in child class */ }

System.print()

items.add(Bicycle.new())

 

{{out}}

 

This is a slightly different take on the task, keeping the editables and rejecting the garbage.

fcn eat{ println("munching ",self.topdog.name); }

}

if(garbage) println("Rejecting: ",garbage);

}

{{out}}

<pre>

 

<!-- Place omit from templates below here -->

{{omit from|ALGOL 68|it isn't immediately obvious that ALGOL 68 is object oriented}}

{{omit from|BBC BASIC}}

{{omit from|C|type system doesn't support this}}

{{omit from|Mathematica}}

{{omit from|Maxima}}

{{omit from|Perl|not statically typed}}

{{omit from|Python|not statically typed}}

{{omit from|Scheme|not statically typed}}

{{omit from|Clojure|not statically typed}}

{{omit from|ZX Spectrum Basic|Does not support user defined datatypes}}