Re: Why does Groovy do object conversion?

tugwilson wrote:

That's right.  It's a j.l.Number which is therefore also j.l.Object.

And for typing of primitives Groovy always autoboxes so 'int' is handled
the same as j.l.Integer (which is no different than BigDecimal in this
context).

I was not suggesting that GString should be a subclass of j.l.String, I
was pointing out that it is impossible that it could be.  Of course even
if it were possible it would be wrong because as I was saying GString is
dynamic and therefore not immutable while j.l.String is immutable.

I agree that coercing strings to number formats by default would be bad.
  A key reason is that such conversion may throw an exception and
moreover there would be problems with what kind of defaults would be
correct (like base and the like).

But it is proper to coerce any Object to a String because every class
implements 'String Object.toString()'.  And that is how Groovy coerces
GString, Number, and anything else to j.l.String.  Groovy does not give
special ad hoc handling to a random assortment of classes to j.l.String
but rather properly interprets the Java object model in a dynamic and
consistent way.

Actually that gives me an idea for a new Groovy Bean pattern to
generalize coercion.  You see, the thing that nags me about Groovy's
coercion of an object that implements 'String toString()' isn't that it
does it but that it isn't a generalized mechanism that other classes can
use.

> This behaviour undermines the claim that Groovy is a strongly typed language
> and, as such, is most undesirable.

I'm not interested in the "Is Groovy weakly or strongly typed?"
nonsense.  It is beyond debate that Groovy is much less strongly typed
than Java.  And the fact that Groovy supports duck typing (the weakest
form of typing you can have) makes it pretty funny for folks to claim
Groovy is strongly typed.

But if you want to insist Groovy is strongly typed anyhow, go right
ahead.  I'm not the one who wants to change what Groovy does, apart from
I'd greatly prefer Groovy to hide private members by default.  That
Groovy doesn't respect private scope defeats information hiding and
contracts which are fundamental principles of object orientation.  It
also violates Groovy's principle of least surprise.

So if you want Groovy to have a better type system, vote for 1875:

http://jira.codehaus.org/browse/GROOVY-1875

Jim


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email