unable to overwritel toString() via MOP in some cases

There are other cases that do not work. Some of them require additional code to be fixed.

Date.metaClass.toString = {-> "silly"}

assert new Date().toString() == "silly"

// similar
assert "".plus(new Date()) != "silly"
assert [new Date()].toString() != ["silly"].toString()

// but also e.g.
assert "".leftShift(new Date()).toString() != "silly"
assert "silly".isCase(new Date()) == false

def s = new StringBuffer("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa")
s[1..5] = new Date()
assert s.indexOf("silly") == -1

But since

String.metaClass.toString = {-> "silly"}
StringBuffer.metaClass.toString = {-> "silly"}
StringBuilder.metaClass.toString = {-> "silly"}

assert "hello world".toString() == "hello world"
assert new StringBuffer("hello world").toString() == "hello world"
assert new StringBuilder("hello world").toString() == "hello world"

what seems to be intent, it is probably a good idea to have a faster invocation for classes that don't allow overriding toString().

I updated the title, because this issue is not about GString, it is about the toString() method in general

as reason why toString here does not work as you seem to expect it to work. Whenever Javacode is calling the toString method we don't get the Groovy version you added here using EMC. As for Lists this happens because the format method uses the Java code only. In guess we would need to rewrite that code in Groovy.

As for the second block... these calls should work I think... which means all of the three asserts should fail

assert "".plus(new Date()) != "silly"
assert [new Date()].toString() != ["silly"].toString()

would both work as expected with the fix to InvokerHelper.format() mentioned above, whereas e.g.

assert "".leftShift(new Date()).toString() != "silly"
assert "silly".isCase(new Date()) == false

would require to modify the respective method's code.

I'm somewhat concerned about Groovy's performance and the scalability of applications that use Groovy as a central technology (e.g. Grails). So I'm not sure if it would be a good idea to let users override e.g. String#toString(), StringBuffer#toString(), and other prominent methods of such classes. Compared to Java, a method call in Groovy is really expensive. Running through the MOP twice, e.g. for a simple string concatenation, surely does not improve this situation.

leftShift is a GDK method... if leftShift calls the dynamic toString method, then there is no problem, because of course you can replace the toString method, you just need code that respects the dynamic aspect. of course the same goes for isCase

I stumbled over this problem the last days and found this issue.

It seems that the solution is posted in GROOVY-2732 and a patch is supplied there.

Can anyone apply the patch and commit the source so this patch is available in the next release.

Best wishes,
Martin Meel
____
Edit:
Got the source now and saw the comment in InvokerHelper.java

The patch fixes some issues but breaks others - 40 breakages in the build for instance including StackOverflow errors. The patch should be regarded as no more than a signpost pointing towards a proper fix. Further contributions/discussion welcome of course.

FYI: A call to toString{} would print the metaClassed values