Computer Science Canada

A challenge

Author:  wtd [ Mon Jul 09, 2007 12:14 pm ]
Post subject:  A challenge

What did I do wrong in the following code?

code:
class Foo {
   public int[] bar() {
      /* code omitted */
   }
}

class Baz {
   private Foo f;

   public Baz() {
      f = new Foo();
   }

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

Author:  Dan [ Mon Jul 09, 2007 2:47 pm ]
Post subject:  RE:A challenge

Are we sposted to reply by posting or PMing you :p. Also are there sposted to be more then one thing wrong?

Author:  wtd [ Mon Jul 09, 2007 3:34 pm ]
Post subject:  RE:A challenge

There is supposed to be one thing wrong. Or at least, I am looking for one thing specifically.

The code omitted is not the problem. Assume that it returns an array of ints via some mechanism that is irrelevant to the question.

Please post. First come, first serve.

Author:  Dan [ Mon Jul 09, 2007 4:15 pm ]
Post subject:  RE:A challenge

Well i could be wrong but public qux() needs a return type in it's deftion or has to have void.

I don't think this is what you meant tho. I have not seen a for loop done like that so i am not shure if it would work, i shall look at it more latter.

Author:  wtd [ Mon Jul 09, 2007 4:57 pm ]
Post subject:  RE:A challenge

Indeed, it is not what I had in mind.

The loop is a 1.5+ for-each loop.

Author:  wtd [ Mon Jul 09, 2007 7:17 pm ]
Post subject:  RE:A challenge

For fun, in another language:

code:
class Foo {
   public def bar: Array[Int] = /* Code omitted */
}

class Baz {
   private val f: Foo = new Foo

   public def qux {
      for (val i <- f.bar) println(i)
   }
}

Author:  PaulButler [ Mon Jul 09, 2007 9:37 pm ]
Post subject:  RE:A challenge

I can't see anything that would prevent the code from compiling, is the mistake in the OOP design?

Should you have done the printing function inside the Foo class instead of the Baz class? Since you are printing the output of the Foo.bar method, it doesn't make sense to stick it in another class which is not used in the printing process.

Author:  wtd [ Mon Jul 09, 2007 9:53 pm ]
Post subject:  RE:A challenge

No. Good thoughts, but you're not even close. Smile

Author:  OneOffDriveByPoster [ Mon Jul 09, 2007 11:01 pm ]
Post subject:  Re: A challenge

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


Call to f.bar() can return null. Do not know if that is what you are looking for though.

Author:  wtd [ Tue Jul 10, 2007 5:08 am ]
Post subject:  RE:A challenge

It is not. Smile

Author:  Aziz [ Wed Jul 11, 2007 12:00 pm ]
Post subject:  RE:A challenge

The classes should be public...

Author:  Aziz [ Wed Jul 11, 2007 12:02 pm ]
Post subject:  RE:A challenge

And be in separate, properly named files. Though, again, perhaps not what you're looking for.

Author:  OneOffDriveByPoster [ Wed Jul 11, 2007 2:27 pm ]
Post subject:  Re: RE:A challenge

PaulButler @ Mon Jul 09, 2007 9:37 pm wrote:
Should you have done the printing function inside the Foo class instead of the Baz class? Since you are printing the output of the Foo.bar method, it doesn't make sense to stick it in another class which is not used in the printing process.

Maybe Baz should extend Foo instead of having a private Foo member?

Author:  Aziz [ Wed Jul 11, 2007 5:15 pm ]
Post subject:  RE:A challenge

I think it's more of a logical/syntax error or even theory, as there is no clue to the business rules that would apply to this model. There could be an Baz object that contains a Foo, and uses the qux() method the print it's child's (a Foo) property that is returned from bar() (which happens to be an array of int)

Author:  wtd [ Wed Jul 11, 2007 7:11 pm ]
Post subject:  RE:A challenge

Aziz is starting to think along the right lines.

Author:  Aziz [ Thu Jul 12, 2007 8:00 am ]
Post subject:  RE:A challenge

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);
      }
   }
}

Author:  wtd [ Thu Jul 12, 2007 10:29 am ]
Post subject:  RE:A challenge

Nope. Smile

Author:  Aziz [ Thu Jul 12, 2007 12:17 pm ]
Post subject:  RE:A challenge

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

Author:  wtd [ Thu Jul 12, 2007 12:21 pm ]
Post subject:  RE:A challenge

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.

Author:  Aziz [ Thu Jul 12, 2007 12:30 pm ]
Post subject:  RE:A challenge

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 <b>static</b> keywords in there.

Author:  Aziz [ Thu Jul 12, 2007 12:34 pm ]
Post subject:  RE:A challenge

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

Author:  wtd [ Thu Jul 12, 2007 12:43 pm ]
Post subject:  RE:A challenge

What does the body of qux tell you?

Author:  Aziz [ Thu Jul 12, 2007 1:01 pm ]
Post subject:  RE:A challenge

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"

Author:  PaulButler [ Thu Jul 12, 2007 1:12 pm ]
Post subject:  RE:A challenge

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...

Author:  Aziz [ Thu Jul 12, 2007 1:19 pm ]
Post subject:  RE:A challenge

wtd said "remember what you know about type inferencing"

Author:  wtd [ Thu Jul 12, 2007 1:20 pm ]
Post subject:  Re: RE:A challenge

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?

Author:  Aziz [ Thu Jul 12, 2007 1:29 pm ]
Post subject:  RE:A challenge

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

Author:  Aziz [ Thu Jul 12, 2007 2:10 pm ]
Post subject:  RE:A challenge

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[]

Author:  wtd [ Thu Jul 12, 2007 3:51 pm ]
Post subject:  RE:A challenge

Which of those offers the wider range of flexibility?

Author:  Aziz [ Fri Jul 13, 2007 7:37 am ]
Post subject:  RE:A challenge

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)

Author:  wtd [ Fri Jul 13, 2007 10:49 am ]
Post subject:  RE:A challenge

And which type is more specific? The array, or the interface?

Author:  Aziz [ Fri Jul 13, 2007 11:56 am ]
Post subject:  RE:A challenge

Specific? The array, int[], or course. Collection<Integer> could be any Collection<Integer>, such as List<Integer>, LinkedList<Integer>, HashSet<Integer> etc etc.

Still don't see what problem this is leading to.

Author:  Aziz [ Fri Jul 13, 2007 12:04 pm ]
Post subject:  RE:A challenge

Alright, I get it. I'm not going to reveal it though....

A hint: The actual problem resides in the bar() method's declaration

Author:  UnusedUsername [ Fri Jul 27, 2007 9:39 am ]
Post subject:  Re: A challenge

Is it that bar() should return a Collection of Integers instead of a int[] because in the for-each loop, the Integer class would be autoboxed to an int anyway?

Author:  wtd [ Fri Jul 27, 2007 12:12 pm ]
Post subject:  RE:A challenge

You're close, but for the wrong reason, UnusedUsername. Smile

Author:  UnusedUsername [ Sun Aug 05, 2007 4:24 pm ]
Post subject:  Re: A challenge

Is the reason because the Integers would be unboxed (not autoboxed) to a int?

But if the return type was a Collection<Integer>, performance should be slower because of the boxing, but perhaps this is offset by the fact that Collection<Integer> is more general than int[]?

I'm still pretty clueless though.

Author:  wtd [ Sun Aug 05, 2007 10:34 pm ]
Post subject:  RE:A challenge

The return type of "int[]" is overly specific. Using an interface to specify the return type allows for more freedom to change the code in the future.

Author:  Chinmay [ Mon Feb 04, 2008 8:58 pm ]
Post subject:  Re: RE:A challenge

wtd @ Wed Jul 11, 2007 7:11 pm wrote:
Aziz is starting to think along the right lines.


I dont have any experience with JAVA but whatever I learn I try to learn perfect Mr. Green

Rolling Eyes Dosnt the baz class have to be public class and contain a main method otherwise this would not compile since it wouldnt make it an application

BooHoo

Author:  Tony [ Mon Feb 04, 2008 9:19 pm ]
Post subject:  Re: RE:A challenge

Chinmay @ Mon Feb 04, 2008 8:58 pm wrote:
it wouldnt make it an application

A piece of code does not need to be "an application" to compile and be valid. Think library files.


: