A challenge

[Aziz]

Perhaps here:

Foo.java

code:

package ca.compsci.wtd.challenge; public class Foo {    public int[] bar() {       /* code omitted           will return object of type int[] */    } }

Baz.java

code:

package ca.compsci.wtd.challenge; public class Baz {    private Foo f;    public Baz() {       f = new Foo();    }    public void qux() {       for (int i : f.bar()) {          System.out.println(i);       }    } }

[wtd]

Nope.

[Aziz]

Okay, you must give us a hint. Is it syntax related? Or theory/good practice?

[wtd]

It has nothing to do with syntax, or how the classes are organized.

It has to do with what the code tells you about itself.

[Aziz]

Perhaps it is this...

Each Baz object has a single Foo object, which is created on construction. However, the constructor creates a default Foo object (no parameters). Thus each Baz object has exactly the exact same Foo object, and calling the quz() method of a Baz instance returns the exact same thing, no matter how many Baz's there are, since Foo's bar() method returns the same thing.

At the most basic of it all, there should be some static keywords in there.

[Aziz]

And btw, I don't know how this relates to type inferencing.

[wtd]

What does the body of qux tell you?

[Aziz]

code:

public void qux() {       for (int i : f.bar()) {          System.out.println(i);       }    }

The body of qux tells me:

- It is a public method
- It has no return type (or rather, void)
- It loops through every element if f.bar(), casting it to int
- It prints out each int as it goes

Also, indirectly:

- It performs an operation, not a function (prints values)
- Logic would be "For every integer in f.bar(), print it"

[PaulButler]

One of my first thoughts was that Java borrowed the const keyword from C++, in which case the qux() method should be const. But apparently that keyword is not in Java, so unless there is an equivalent keyword that isn't it either...

[Aziz]

wtd said "remember what you know about type inferencing"

[wtd]

Aziz @ Fri Jul 13, 2007 2:01 am wrote:

- Logic would be "For every integer in f.bar(), print it"

Now... what does this tell you about bar?

[Aziz]

It contains integers . . . I can kind of see where this is going, just not what the problem is.

[Aziz]

Or rather, since the for each construct in this case would be would be:

for (<T> var : <T>[])

(there is also the construct for(<T> var : Collection<T>) )

It implies that bar() return int[]

[wtd]

Which of those offers the wider range of flexibility?

[Aziz]

Flexibility? Collections of course.

Another thing I just noticed:

There is ambiguity - f.bar() could return int[] or Collection<Integer> (due to auto-boxing) (I'm referring to what the for loop is implying)