New Considered Harmful

This page posits that the primitive "new" operator common to many ObjectOrientedProgramming languages be ConsideredHarmful. This is not a suggestion that "new" be eliminated, but rather that it be replaced by other primitives.

The evidence stacked against "new" is not insignificant. There exists a plethora of DesignPatterns aimed to achieve flexibility, ConfigurableModularity, extensibility at the time of 'setup' for an object graph. These include AbstractFactory with PluginArchitecture, AbstractConstructor, DependencyInjection, ConstructorInjection, SetterInjection, SingletonPattern each suggest that something different is needed when it comes to PrimitivesAndMeansOfComposition for ObjectOrientedProgramming languages. Additionally, there are other 'setup' time concerns related to distribution, privacy or secrecy, persistence, redundancy, memory management, and so on, complete with its own gamut of DesignPatterns (ContainerManagedPersistence, SmartPointer, etc.). The collision of setup-time concerns between configuration and object management can, without extreme care, easily result in BigBallOfMud frameworks (a problem exacerbated further by Static ManifestTyping).

I can only suggest that the setup-time decisions and DesignPatterns introduce a rather strong MissingFeatureSmell.

Let us consider a typical implementation of "new". The basic responsibilities for this primitive are: Further, it inherits properties from the above that may be cause for concern: A valid question is: Which is the greater responsibility of "new"? to create a new object? or to return an object name?

To answer "creating a new object" is to ignore the prevalence of the SingletonPattern and of data-driven access to abstractions of external systems (cameras, printers, clocks, random-number-generators).

Thus I posit that the answer is "to return an object name".

And, if so, I would posit that we really ought to have a primitive named something other than "new". I.e. NewConsideredHarmful.

There are alternatives to "new", especially based around the AbstractConstructor and possibly the FirstClass construction of 'object configurations'. My own stab at doing so introduces a primitive named "construct" which applies to an object-configuration introduced by "configure" (with configurations in turn composed by FunctionalProgramming). A fairly trivial configuration would be to create an object-configuration consisting of a name for exactly one object - which already exists. Constructing that configuration would return the name for the existing object. Trivial? Yes. But it does illustrate the distinction between "construct" on a configuration vs. "new" on a class'.

Under-the-hood, my language also supports AbstractFactory PluginArchitecture for DistributedSystems (described in the AbstractFactory page), which essentially operates as something of a distributed, persistent version of a ForeignFunctionInterface. However, this is not available from the general language without explicit injection of an object that grants access to the AbstractFactory and so is subject to the ObjectCapabilityModel.

Based on my (rather DistributedSystems-biased) experience, I submit the following suggestions and reasoning towards designs that replace "new":

View edit of November 10, 2014 or FindPage with title or text search