DDevelopment & Design

Girls gonna code

Programming is not just a guy thing. Rails Girls Warsaw wants to prove it this weekend. Girls and women are going to learn building web applications with Ruby on Rails.

Programming is not just a guy thing. Rails Girls Warsaw wants to prove it this weekend. Girls and women are going to learn building web applications with Ruby on Rails.

The idea is to help girls to get familiar with the technology and equip them with the skills needed to create and code  their own web applications. All under the supervision of professional coaches and in a warm and creative atmosphere.

Rails Girls was born in Finland and nowadays their workshops are held all around the world. They come to Warsaw for the second time. And for the second time the event is supported by TouK.

Some immpresions from the first edition you can find here.

— Previous article

Takie Flaszki wspieramy

Next article —

WJUG o testach

You May Also Like
DDevelopment & Design

Writing JAXB in Groovy

Suppose you want write a jaxb class in groovy. Why? Because you do not have to write these all getters, setters and other methods. You only have to write your fields down.@XmlRootElement@HashCodeAndEquals@ToStringclass Person { String firstName String ...
DDevelopment & Design

33rd Degree day 3 review

At the last day of the conference, I've decided to skip the first presentations, and get some sleep instead. I was afraid that Venkat's show is going to be too basic, I will see Jacek Laskowski talking about closure at 4Developers, which I'm kind of s...
DDevelopment & Design

Private fields and methods are not private in groovy

I used to code in Java before I met groovy. Like most of you, groovy attracted me with many enhancements. This was to my surprise to discover that method visibility in groovy is handled different than Java!

Consider this example:

class Person {
private String name
public  String surname

private Person() {}

private String signature() { "${name?.substring(0, 1)}. $surname" }

public String toString() { "I am $name $surname" }
}

How is this class interpreted with Java?

  1. Person has private constructor that cannot be accessed
  2. Field "name" is private and cannot be accessed
  3. Method signature() is private and cannot be accessed

Let's see how groovy interpretes Person:

public static void main(String[] args) {
def person = new Person()   // constructor is private - compilation error in Java
println(person.toString())

    person.@name = 'Mike'       // access name field directly - compilation error in Java
println(person.toString())

    person.name = 'John'        // there is a setter generated by groovy
println(person.toString())

    person.@surname = 'Foo'     // access surname field directly
println(person.toString())

    person.surname = 'Bar'      // access auto-generated setter
println(person.toString())

println(person.signature()) // call private method - compilation error in Java
}

I was really astonished by its output:

I am null null
I am Mike null
I am John null
I am John Foo
I am John Bar
J. Bar

As you can see, groovy does not follow visibility directives at all! It treats them as non-existing. Code compiles and executes fine. It's contrary to Java. In Java this code has several errors, pointed out in comments.

I've searched a bit on this topic and it seems that this behaviour is known since version 1.1 and there is a bug report on that: http://jira.codehaus.org/browse/GROOVY-1875. It is not resolved even with groovy 2 release. As Tim Yates mentioned in this Stackoverflow question: "It's not clear if it is a bug or by design". Groovy treats visibility keywords as a hint for a programmer.

I need to keep that lesson in mind next time I want to make some field or method private!