Re: [groovy-user] Creating XML

It is close to ConfigSlurper format. You could convert using:

new ConfigSlurper().parse(str.replaceAll(/=\s*\{/, / \{/))

And from there output into XML using perhaps MarkupBuilder.

Paul.

On 1/05/2010 8:30 AM, citron wrote:
>
> Hi,
>
> I need to transform strings in this format into xml, any ideas how to do
> this?
>
> Thanks!
>
> def str ="""rootElement={
>                      someComplexSubElement={
>                              string1="sdfsf"
>                              string2="sdsssss"
>                      }
>                      someOtherComplexSubElement={
>                              string1="sdfsf"
>                              string2="sdsssss"
>                      }
>                      string1="yert"
>                      string2="selskdjf"
>            }"""

Re: [groovy-user] Unable to create a child instance when using a closure accessing private fields of the parent within the constructor

Hi Jochen,

Jochen Theodorou wrote:
> 
> 
> this is actually a design error in the MOP. Each way that would fix 
> this, will create other problems, so there cannot be a backwarts 
> compatible fix. We decided then to keep that till Groovy 2.0 and solve 
> this issue there once and for all. assigning to a local variable fixes 
> the problem. I am aware that is a somewhat ugly workaround, but better 
> than nothing.
> 
> 

thanks a lot for this information.  Does this mean the behavior will
probably change when this item of the roadmap is done:

* New Meta-Object Protocol

Currently, the roadmap shows ETAs up to version 1.8.  I guess we cannot
expect 2.0 to show up in 2010 or early 2011, can we?

Best regards + many thanks, Uli
--

-- 
View this message in context: http://old.nabble.com/Unable-to-create-a-child-instance-when-using-a-closure-accessing-private-fields-of-the-parent-within-the-constructor-tp28413103p28418916.html
Sent from the groovy - user mailing list archive at Nabble.com.

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

RE: [groovy-user] Creating XML

Re: [groovy-user] Unable to create a child instance when using a closure accessing private fields of the parent within the constructor

uli42 wrote:
[...]
> thanks a lot for this information.  Does this mean the behavior will
> probably change when this item of the roadmap is done:
> 
> * New Meta-Object Protocol
> 
> Currently, the roadmap shows ETAs up to version 1.8.  I guess we cannot
> expect 2.0 to show up in 2010 or early 2011, can we?

Groovy 2.0 won't come in 2010, that is quite sure. We will spend 2010 to 
  complete 1.8. We use 1.8 also to collect information on how to make a 
more efficient MOP, which then would go into Groovy 2.0. I think the 
most early date for Groovy 2.0 would be end of 2011.

bye blackdrag

--

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

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

    http://xircles.codehaus.org/manage_email

Re: [groovy-user] Pre-compiled classes

Anyone know how to use the MOP to add a toString method to a class that acts
as the native toString method would?

For example

MyClass.metaClass.toString = {//method}

So that this would act as the default toString, other than having to be
called like

def a = new Myclass
println a.toString

--

-- 
View this message in context: http://old.nabble.com/Pre-compiled-classes-tp28394606p28421627.html
Sent from the groovy - user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email

[groovy-user] default unique() not consistent with equals

DefaultGroovyMethods.unique() removes "all duplicated items, using the 
default comparator".  For non-Comparable classes, this defaults to 
comparing hashCode().  But, hashCode() is not unique and does not imply 
equals():

         def a = TimeZone.getTimeZone("US/Hawaii")
         def b = TimeZone.getTimeZone("Pacific/Honolulu")
         assert a != b
         assert a.hashCode() == b.hashCode()
         assert [a, b].unique() == [a, b]                 // <--------- 
this fails

The relevant part of NumberAwareComparator seems to be this:

             // since the object does not have a valid compareTo method
             // we compare using the hashcodes. null cases are handled by
             // DefaultTypeTransformation.compareTo
             int x1 = o1.hashCode();
             int x2 = o2.hashCode();
             if (x1==x2) return 0;
             if (x1<x2)  return -1;
             return 1;

Is there some reason for ignoring equals() on lowly, non-Comparable 
classes?  Why not do the following?  (Any problem for sort()?)

             if (o1.equals(o2)) return 0;
             int x1 = o1.hashCode(); // arbitrary comparison, but stable
             int x2 = o2.hashCode();
             if (x1==x2) { // fall back to arbitrary comparison of 
instance identity
                 x1 = System.identityHashCode(o1);
                 x2 = System.identityHashCode(o2);
             }
             if (x1<x2)  return -1;
             return 1;

Cheers,
11011011

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

    http://xircles.codehaus.org/manage_email

Re: [groovy-user] default unique() not consistent with equals

Re: [groovy-user] Pre-compiled classes

Re: [groovy-user] Unable to create a child instance when using a closure accessing private fields of the parent within the constructor

Hi Jochen,

Jochen Theodorou wrote:
> 
> Groovy 2.0 won't come in 2010, that is quite sure. We will spend 2010 to 
>   complete 1.8. We use 1.8 also to collect information on how to make a 
> more efficient MOP, which then would go into Groovy 2.0. I think the 
> most early date for Groovy 2.0 would be end of 2011.
> 

this is a good plan. But it means that I cannot depend on the fix for my
current project, which is fine. I thought a little bit about your remarks
related to MOP etc. and came to the conclusion that there might be a chance
to get the original approach working by using GroovyPP/Groovy++. Indeed, it
works. Basically, you only have to add the " <at> Typed" annotation to the
constructor.

So I think I'll do some more experiments based on this. Maybe in the end, I
will use groovy++ to compile all the library parts of the application and
groovy for the remaining things. On the other hand, things definitely get
more complex by doing this.

Thanks a lot for helping and good luck for the 1.8 release. I'm looking
forward to it.

Best regards, Uli
--

-- 
View this message in context: http://old.nabble.com/Unable-to-create-a-child-instance-when-using-a-closure-accessing-private-fields-of-the-parent-within-the-constructor-tp28413103p28425220.html
Sent from the groovy - user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email

Re: [groovy-user] Removing a metaClass method