Delegation (in OO) is the act of one object (the original object) forwarding a request (method call) from itself to another object (the delegate). Some claim that inheritance is a special case of (can be modeled by) delegation; however there are different styles of delegation.
See also WhatIsDelegation for a discussion of definitions. If more precise terminology is available, feel free to ReFactor this page.
Calling this non-polymorphic is somewhat dubious. Avoiding inheritance does not make you free of polymorphic behavior. Polymorphism does not depend on inheritance (see ConfusionAboutInheritance). The Bridge pattern has delegation, and a layer of indirection, therefore it's polymorphic (according to WhatIsDelegation; see also PolyMorphism).
An example from PrototypeBasedProgramming that might help:
What happens in a prototype language in the following case: object A delegates to object B; object A calls a method f on itself, which gets delegated to B; then B calls a method g on itself. If A also has a version of g, does that version get called (like in a traditional class-based language)? If so, that means that there always is an implicit "real" object beneath the curtain? -- StephanHouben
In the one prototype object language I've used in anger commercially, called Vision, the normal case is indeed that A's version of g is called, using
^self g
in the definition of f in the super-object (forget the ^ and it could be Smalltalk). Whereas
^here g
^current g
both explicitly call g as defined in B, the super-object. But whereas ^here keeps the original sub-object A in view for future method calls, ^current causes A to be forgotten and the computation to proceed simply as a message send to B. Easy isn't it?
Despite this necessary complication, the idioms of prototype-based programming have a lot going for them. Even JavaScript may help bringing some of this into the mainstream perhaps.
-- RichardDrake