In Smalltalk, we say that each object decides for itself how it responds to a message. This is called polymorphism. The same message selector may be sent to objects of different Classes. The shape (morph) of the computation is different depending on the specific class of the many (poly) possible classes of the object receiving the message.

I think RSpec should provide around(:context)/around(:all). Not because of any particular use case, but simply for API consistency. It's much simpler to tell users "there are 3 kinds of hooks (before, after and around) and each can be used with any of 3 scopes (example, context and suite)". Having some kinds of hooks work with only some kinds of scopes makes the API inconsistent and forces us to add special case code to emit warnings and also write extra documentation for this fact.

@entry = Entry.create! entryable: Spot.new(params.require(:spot).permit(:address)) redirect_to @entry # Redirects to e.g. /spots/47, with 47 being the newly created Entry id.

Epics can contain both issues and epics as children

I wouldn't consider it switching behavior. Ultimately it's including a module -- either a manually defined and referenced one from the user, or a RSpec::Core::SharedExampleGroupModule created for the user when they defined the shared example group and referenced via the group name.

Uber::Option implements the pattern of taking an option, such as a proc, instance method name, or static value, and evaluate it at runtime without knowing the option's implementation.

Please note that the actual task doesn’t have to be a proc! Use a class, constant, object, as long as it exposes a #call method it will flow.

Please note that I/O works for both “simple” tasks as well as nested activities.

a task in an activity can be any callable Ruby object

Your actual logic happens in tasks, the labeled boxes. A task may be any callable Ruby object, an instance method or even another activity.

polymorphic method inside shape class, its possible to discriminate them. without if’s.

Record filters allow you to require an instance of a particular class (or one of its subclasses) or a value that can be used to locate an instance of the object. If the value does not match, it will call find on the class of the record. This is particularly useful when working with ActiveRecord objects.

You can also create an anonymous interface on the fly by passing the methods option.

*initialize* also supports passing resources (also attributes if you would # like to) manually

You can only make object-safe traits into trait objects. Some complex rules govern all the properties that make a trait object safe, but in practice, only two rules are relevant. A trait is object safe if all the methods defined in the trait have the following properties: The return type isn’t Self. There are no generic type parameters.

Trait Objects Perform Dynamic Dispatch Recall in the “Performance of Code Using Generics” section in Chapter 10 our discussion on the monomorphization process performed by the compiler when we use trait bounds on generics: the compiler generates nongeneric implementations of functions and methods for each concrete type that we use in place of a generic type parameter. The code that results from monomorphization is doing static dispatch, which is when the compiler knows what method you’re calling at compile time. This is opposed to dynamic dispatch, which is when the compiler can’t tell at compile time which method you’re calling. In dynamic dispatch cases, the compiler emits code that at runtime will figure out which method to call.

To many people, polymorphism is synonymous with inheritance. But it’s actually a more general concept that refers to code that can work with data of multiple types. For inheritance, those types are generally subclasses. Rust instead uses generics to abstract over different possible types and trait bounds to impose constraints on what those types must provide. This is sometimes called bounded parametric polymorphism.

abstracted interfaces, where the implementations can be changed and multiple implementations could be created and polymorphically substituted for each other.

Be aware that compilers typically, but not always, return string. Some compilers, such as the one configured with rehype-react, return other values (in this case, a React tree).

Here, when x is a Boolean value then the section tag acts like an if conditional, but when x is an array then it acts like a foreach loop.

This would be a component that is meant to be styled by its parents, and it would make no logical sense to have every possible type of style available inside the Link component. If I wanted to turn one of these anchor tags into a button, another into a nav-link, and another into a footer link, I should be able to. There's no reason that there shouldn't be a feature to treat a component like a normal HTML element.

Commonly the above definition is called the identity function. But in fact we should think of it as a whole family of functions. We should really say that id is an identity function for all types a. In other words, for every type T you might come up with, there is an identity function called id, which is of type T -> T. This is the type-checker’s view anyway, and by turning on the RankNTypes extension we can be explicit about that in our code: {-# LANGUAGE RankNTypes #-} id :: forall a. a -> a id x = x

In other words you cannot choose the definition of a value based on its type (for now).

the Add functions seem to work generically over various types when looking at the invocations, but are considered to be two entirely distinct functions by the compiler for all intents and purposes

chose the term ad hoc polymorphism to refer to polymorphic functions that can be applied to arguments of different types, but that behave differently depending on the type of the argument to which they are applied (also known as function overloading or operator overloading)

A language that features polymorphism allows developers to program in the general rather than program in the specific. $(document).ready(function() { recordAdModuleData(2964, "impressions","Dictionary Ad"); });

polymorphism cuts down the work of the developer because he can now create a sort of general class with all the attributes and behaviors that he envisions for it. When the time comes for the developer to create more specific subclasses with certain unique attributes and behaviors, the developer can simply alter code in the specific portions where the behaviors differ. All other portions of the code can be left as is.

export function assignForwardedRefs(forwardedRef, refToAssign) { if (forwardedRef) { if (typeof forwardedRef === 'function') { forwardedRef(refToAssign) } else { forwardedRef.current = refToAssign } } }

Dynamic dispatch

Here the method subtypePolymorphic() has no type parameters, so it’s parametrically monomorphic. Nevertheless, it can be applied to values of more than one type as long as those types stand in a subtype relationship to the fixed Base type which is specified in the method signature — in other words, this method is both parametrically monomorphic and subtype polymorphic.