Re: [groovy-user] cast
Francesco Pasqualini schrieb:
> Hi Guillaume,
> you say*:*
>
> << groovy is able to "coerce" types to boolean values as needed (for
> instance where conditional expressions are required like in if or while
> constructs) >>
>
> I think this is a great feature.
>
> But - exuse me if I insist - why groovy is not able to convert string to
> number (for example in math expresion like 4/'2' and numeric context ) ?
>
> I hope you agree that this could be a smart feature.
in a if and while the context is quite clear. you have a syntactic hint
that a boolean will be used here. in an expression x/y you don't have a
hint as of what types will be used for x and y.
I am very much against uncontrolled type changes, especially in
combination with operators. I really don't want let Groovy go the C++
road to operation overloading hell. We already have one case that
changes it type in a not so good controlable way.. and that is when a
GString is converted into a String... But I think we can life with that,
if it is the only exception, and it is only there because GString can
not be a sub class of String.
So if the String does get promoted to an int, then there would be still
the way of providing additional div methods. But think about it... what
sense does String#div(int) have? Or Integer#div(String)? I don't see a
reason the justifies adding them, by only looking at the method
signature... They don't make much sense.
If you still want ot have that, then you have two ways: change the
MetaClass of String and Integer to add these methods or add them using a
category. In any way you get what you wanted to have.
I only have problems adding this to the main language
bye blackdrag
--
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
RSS Feed