Re: [groovy-dev] Suggestion of an improvement for MetaClassImpl.setProperty
Hi,
Here is a new patch (generated with git format-patch rather than git diff),
however it is very similar to the previous and I may have missed something about
patches...
I tried putting each class in its own file and a separate main, compiling each at
a time with groovyc, and then executing the main but got the same result (the raw
map returned).
Regards,
Mathieu Bruyen
On Wed 2/05/12 16:27, Cédric Champeau cedric.champeau@... wrote:
> Hi Mathieu,
>
> I'm trying to apply your patch onto master, but it fails with
> "corrupt patch". Whatever, I'm wondering if your technique doesn't
> work only because both Address and User are compiled in the same
> source file. Could you test, for example, compiling Address, then User
> and eventually, a script using both?
>
> Le 02/05/2012 15:07, Mathieu Bruyen a crit : Hello,
>
> I stumbled upon a problem with type erasure when using the default
> map constructor, with a script like:
>
> class Address {
> String street
> int zip
> }
> class User {
> String name
> List addresses
> }
> def u = new User([
> name: 'Foo',
> addresses: [
> [street: '36, Foo road', zip: 12345],
> [street: '37, Bar road', zip: 6789]
> ]
> ])
> println u.addresses
>
> In that case u.addresses will be a list of maps, containing the raw
> map that has been given as parameter (the script echoes [[street:36,
> Foo road, zip:12345], [street:37, Bar road, zip:6789]]).
>
> After digging a bit I found that the MetaClassImpl.setProperty
> method does not care about generics even if they are available (and in
> that case they are). I tried play a bit with the available information
> and come to a prototype, as seen in the patch (to be applied on commit
> 762924186670e40e088c2bbb5bc5a205f7c7118b). In the patch I added a
> method to get generic parameters on CachedMethod, a type
> transformation that creates a list with types all objects inside it
> and the hack in MetaClassImpl.
>
> The patch is really just a prototyping and would need to define a
> real interface to get generic information from MetaMethod as well as a
> proper way of doing the conversion. The problem is of course not
> restricted to lists, and it would have to be made for a larger set of
> types (to me for Map and Collection (all that implements collection at
> once, not one solution for each individual type)) but I first wanted
> to know if there was an interest for such a feature before polishing
> what I did.
>
> I spotted two downsides of this approach:
> * depending on how the code is written sometimes types will be
> enforced and sometimes it would be raw maps
> * if the user used a specific collection type (like an unmodifiable
> or a concurrent one) that would be converted with this approach to a
> default type like HashMap, ArrayList, ...
>
> So my question, are you interested in such a feature?
>
> Regards,
> Mathieu Bruyen
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> http://xircles.codehaus.org/manage_email [1]
>
> -- Cdric Champeau SpringSource - A Division Of VMware
> http://www.springsource.com/ [2] http://twitter.com/CedricChampeau [3]
>
>
> Links:
> ------
> [1] http://xircles.codehaus.org/manage_email
> [2] http://www.springsource.com/
> [3] http://twitter.com/CedricChampeau
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
I was thinking of raising a JIRA for this, but found there already is one[3]. So, would it be worthwhile to submit a pull request for GROOVY-4998?
RSS Feed