One of the most common features of object-oriented programming is the use of constructors and destructors, but most people don't put a lot of thought into how it affects the structure of a language. The first issue is, not all object-oriented languages support them. For example, the most common one is Javascript, and the desire to have them actually contributed greatly to it being mangled. Java also doesn't having destructors.
The second issue is that the context in which objects are created and disposed is not always apparent. In C#, an object is not guaranteed to be destroyed when it goes out of scope. In fact, it tends to linger in the garbage collector for some time, so you have to manually dispose or finalize the object, thus defeating the purpose of a destructor altogether.
The third issue is name mangling. The languages that do use constructors and destructors have a somewhat ridiculous naming scheme that uses the name of the class itself. You may not think of this as an issue, but consider in C++ that the tilde (~) is not a valid character for identifiers. The constructor can also cause issues if you're working with both C and C++ code. For example, in an older version of my engine, I had a C struct called Matrix and a function to create it:
Code: Select all
typedef struct Matrix Matrix;
struct Matrix
{
float cell[4][4];
}
void Matrix_Matrix(Matrix *_this, const float *value);
Code: Select all
class Matrix
{
public: Matrix(const float *value);
};
The fourth issue is error handling. Because constructors can't return a value, the only way to handle errors in a constructor is to wrap the object in a try/catch statement, which leads to a secondary headache; freeing resources after an error, which pushed some languages to evolve to having "with", "using", and "finally" statements.
The fifth issue is by far the biggest...multithreading and asynchronous operations. When dealing with multiple threads or asynchronous operations, the user may need to provide several event handlers and setup additional properties or things like semaphores. Just too much to be passed to a constructor. Additionally, they don't consider that fact that the object could be disposed in one of several threads. If thread 1 disposes of the object while thread 2 is using it, you could get a crash. Or an even worse example, if thread 1 disposes of the object while thread 2 has a semaphore locked and thread 3 is waiting for permission, you've could have yourself a nasty deadlock.
I did come up with simple solution to this though. I'm not sure if it's ever been done before, but I've personally never seen it done. It's to create an agent that manages events, properties, and semaphores for an object. It's kinda similar to how .NET does events for it's controls, but bundled together. For example:
Code: Select all
Agent agent = new Agent();
agent.eventHandler.Add(FileOpenEventHandler, MyFileOpenHandler);
agent.eventHandler.Add(FileCloseEventHandler, MyFileCloseHandler);
agent.eventHandler.Add(FileReadEventHandler, MyFileReadHandler);
agent.eventHandler.Add(FileErrorEventHandler, MyFileErrorHandler);
File file = new File(filePath, FileMode.Read, agent);
void MyFileOpenHandler(Agent agent, FileOpenEventArgs e)
{
Debug.Log("File was opened");
}
void MyFileCloseHandler(Agent agent, FileCloseEventArgs e)
{
agent.eventHandler.Clear();
}
void MyFileReadHandler(Agent agent, FileReadEventArgs e)
{
Debug.Log(e.progress.ToString());
}
void MyFileErrorHandler(Agent agent, FileErrorEventArgs e)
{
Debug.Error(e.ToString());
}-----------------------------
So in summary, are constructors and destructors 100% evil? No... But they do have quirks and issues surrounding them, and as we progress towards a multi-tasking world, we may have to address them more seriously in future; perhaps in "the next big language".
Please take this with a grain of salt. The major purpose of this poll is to help myself come to a conclusion about the path I'm wanting to take with one of the libraries I'm working on. If you have anything else to add, some comments to make, some insults to throw (I'm sure there will be), please share your opinion.
Advertising
