Skip to main content

Operator new factories

11 replies [Last post]
scolebourne
Offline
Joined: 2003-06-20

Proposal:
Add support for overloading the operator new. This proposal specifically rejects general operator overloading.

Rationale:
Many systems start small and grow large over time. Often, the initial phases have relatively little formal architecture or design, thus the most simple approach is taken. For example, object creation is performed using new

Person person = new Person();

As the system grows, architecture can become more advanced, requirements can change, and there may be a need to change a class to a singleton, or pool instances, or otherwise share. But the only way to do this at present is to change everywhere where new is used to a static factory method.

Person person = Person.createPerson();

This is a potentially huge change, and either involves messy deprecation, or breaking the code. The JDK has examples of this - consider new Boolean().

Change:
The Java language should be changed to support operator overloading of the new keyword, that can return an alternative object instead of instantiating one if required. Thus:

Person person = new Person();
is changed by the compiler to
Person person = Person.new();
if there is a static method called new()

Note that the method name new() must return a non-null object of the type Person. If 'new Person()' is called in there then the compiler substitution does not occur.

Summary:
General operator overloading is evil as you can change + to be - or some such. Operator new factories is a much more restricted case that deals with a common, and hard to work around, business scenario.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tsinger
Offline
Joined: 2003-06-10

Well, from time to time, API changes are necessary. This is called Refactoring and a very important part of any project.

I don't think, Java should be changed in that way, that you don't need to change your API.

IMHO, there are only two reasons for changing Java:
- catch often occuring errors at compile time (e.g. const or notnull references) and
- make your intention more clear (e.g. enhanced for-loop in Java 5)

--
Tom

paulrivers
Offline
Joined: 2004-03-04

tsinger - I almost agree, but there's other subtle reasons.

A language change may be needed to implement general, simple, straightforward things that you have to write over and over again. Like the enhanced-for loop. Or generics - you're always casting, over and over again.

Also, a language change may make these general, simple, straightforward things simpler (which also makes your intention clear). My favorite pet peeve in java is that whole get/set thing. I wish you could just declare properties. (This may be basically the same as your "make your intention more clear" item).

jarouch
Offline
Joined: 2004-03-04

They are not but it can be good feature if we have way to enforce class to implement static method.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4093687

jdavi
Offline
Joined: 2003-06-11

+1

When I was a newbee I looked very hard for an equivalent of the "readResolve" for serialization, but applicable to constructors ;-)

Cheers
JD

distiller
Offline
Joined: 2004-10-07

Just use AspectJ. You know you want to.

tsinger
Offline
Joined: 2003-06-10

-1

If you use a decent IDE (e.g. IDEA), it can create the factory upon user request and converts all calls to the constructor to use that factory.

Tom

scolebourne
Offline
Joined: 2003-06-20

That assumes that you have access to all the code that calls your code. In large-scale enterprise systems you often don't, because you've distributed your API.

zander
Offline
Joined: 2003-06-13

Changing from instances to a singleton and expecting the code which uses it to still work even with the above means you have probably never made such a change or you made it a singleton for very wrong reasons.

Simply said; if you made an API change as large as this; you will most certainly make code break since the basic behavior will change. Its best to let the code stop compiling as well.

trinition
Offline
Joined: 2003-07-29

It seems you would need some sort of restriction. PErson itself would have to become uninstantiatable. If its not, consider this code someone could write:

public class Person {
public static Person new() {
return new Person(); // This causes infinite loop!
}
}

Instead, one should be forced to delcare Person as abstract so that the commented line above would never compile.

But then what of interfaces? You wisely state how one could evolve form having as simple Person object to needing a framework, so we'd need a static new method in the base class [b]or interface[/b] for Person. I don't think static methods are allowed in interfaces today. Personally, I think they should be; however, even in this case, one could make a narrow rule for allowing static "new" methods in interfaces.

scolebourne
Offline
Joined: 2003-06-20

The new Person() within the static new() method creates a 'new' Person exactly as now, calling the constructor.

scolebourne
Offline
Joined: 2003-06-20

So has no one had a problem needing to change instantiation to factories?