passing a Factory to a method to create a generic instance

[Tom Anderson]

I wasn't. And, someone has written the "all-in-one" constructor for me:

in = new ObjectInputStream( inputStream );
room = (Room)in.readObject();

will do that. So if I had to I'd use some variation on that method. The OP
wanted a way to load objects with a single load method; that's what I was
trying to give him.

I got the impression his assignment involved a specified file format which
he had to read, BICWBW.

My opinion is that all types of design patterns are needed, and should
be used. Trying to force a pattern onto a design is going to make the
design brittle, hard to maintain, etc. Use builders where they are
needed. Use POJO were it's needed. Use EJB where it's needed.

Couldn't agree more. Patterns are specific solutions to specific problems:
applying them where the problem is absent is not a good thing!

Anyway, i think we've covered pretty much every angle on this problem. I'd
be impressed if the OP was still with us!

tom

 

[Mark Space]

Couldn't agree more. Patterns are specific solutions to specific
problems: applying them where the problem is absent is not a good thing!

Anyway, i think we've covered pretty much every angle on this problem.
I'd be impressed if the OP was still with us!

tom

Just wanted to point out this, which also talks about the builder pattern:

<http://developers.sun.com/learning/javaoneonline/2006/coreplatform/TS-1512.pdf>

 

[Tom Anderson]

Just wanted to point out this, which also talks about the builder pattern:

<http://developers.sun.com/learning/javaoneonline/2006/coreplatform/TS-1512.pdf>

Urgh. All that just because java doesn't have optional or keyword
parameters.

Also, i don't get his "intriguing possibility" on slide 10 - what is that?
A general-purpose no-arg factory? Why does he think that's better than a
Class? Didn't he notice that newInstance() went generic, and is now
typesafe? The advantage is that it can return subclasses, i guess.

tom

 

[Tom Anderson]

Oh, yeah, right, like that's a huge disadvantage for Java.

Did i say it was huge?

And what a huge boon those features would be - not.

Why not?

The combination of default parameters and keyword arguments is a simple,
clean and convenient way of managing complicated argument lists. Examples
from python - subprocess.Popen:

http://docs.python.org/lib/node528.html

And csv.reader, which can take a bunch of formatting parameters:

http://docs.python.org/lib/csv-contents.html
http://docs.python.org/lib/csv-fmt-params.html

Having defaults means that in the simple case, you can do:

rows = csv.reader(somefile)

But that if you do want to apply some tweaks, you can do:

rows = csv.reader(dialect="excel", skipinitialspace=True, lineterminator="\t")

No need for the routine author to write giant overloads, no need for the
caller to write loads of nulls or use a builder interface. It's a simple
and powerful way of managing complexity.

tom

 

[Roedy Green]

Is the idea to make a single method, outside of Room and Guest, which
returns an instance of, well, type <T>?

A factory method normally produces objects of Interface T. You would
not use the same factory method to create both a Room and a Guest
since you would need to cast the results.

 

[Tom Anderson]

A factory method normally produces objects of Interface T. You would
not use the same factory method to create both a Room and a Guest since
you would need to cast the results.

I think he means something like this:

interface HotelFactory
{
public <T> make(Class<T> cl, IOStream ios) ;
// cl is there purely to set the type
}

So you can do:

HotelFactory fac = ... ;
Room r = fac.make(Room.class, ios) ;
Guest g = fac.make(Guest.class, ios) ;

Which would be silly, but possible.

tom

 

[Arne Vajhøj]

The combination of default parameters and keyword arguments is a simple,
clean and convenient way of managing complicated argument lists.
Examples from python - subprocess.Popen:

http://docs.python.org/lib/node528.html

And csv.reader, which can take a bunch of formatting parameters:

http://docs.python.org/lib/csv-contents.html
http://docs.python.org/lib/csv-fmt-params.html

Having defaults means that in the simple case, you can do:

rows = csv.reader(somefile)

But that if you do want to apply some tweaks, you can do:

rows = csv.reader(dialect="excel", skipinitialspace=True,
lineterminator="\t")

No need for the routine author to write giant overloads, no need for the
caller to write loads of nulls or use a builder interface. It's a simple
and powerful way of managing complexity.

They could be added to the Java language.

But I don't know if they are worth the complexity.

We have already seen some complexity by adding variable
number of arguments.

Arne

PS: It would of course have to be something else than = to not break
existing code that passes a boolean expression.

 

[Tom Anderson]

They could be added to the Java language.

But I don't know if they are worth the complexity.

We have already seen some complexity by adding variable
number of arguments.

I think the complexity is actually rather less than that - all that the
combination of defaults and keywords change allows is for callers to (a)
omit any number of parameters from the end of a call and (b) supply any
omitted parameters by keyword. The definition just involves writing some
defaults. There's no magic boxing of varargs into arrays or anything like
that. It's still more to know, of course, but it's not particularly
complex.

The one complex thing i can think of is inheritance. If i declare:

class Foo {
void bar(int i=23) ;
}

Clients can say:
Foo foo = ... ;
foo.bar(42) ;
foo.bar() ;

If i want to subclass Foo, do i have to override bar(int), bar(),
bar(int=default), or what? Can i inherit the default? Python is untyped,
so this is a non-issue - a message gets sent, a method gets located, or
else there's an error. In java, though, we have to have rules about this.

PS: It would of course have to be something else than = to not break
existing code that passes a boolean expression.

Arne, please don't tell me you're confusing = and ==!

tom

 

[Arne Vajhøj]

That looks strikingly like two overloads of bar(), one with an int
parameter one without. From the client's point of view, doesn't that
make the int argument optional?

Java supports optional arguments, just not with the syntax you wanted.

Optional arguments is strictly a "called" thing not a "caller" thing.

Arne

 

[Arne Vajhøj]

I think the complexity is actually rather less than that - all that the
combination of defaults and keywords change allows is for callers to (a)
omit any number of parameters from the end of a call and (b) supply any
omitted parameters by keyword. The definition just involves writing some
defaults. There's no magic boxing of varargs into arrays or anything
like that. It's still more to know, of course, but it's not particularly
complex.

The one complex thing i can think of is inheritance. If i declare:

class Foo {
void bar(int i=23) ;
}

Clients can say:
Foo foo = ... ;
foo.bar(42) ;
foo.bar() ;

If i want to subclass Foo, do i have to override bar(int), bar(),
bar(int=default), or what?

In general I find it confusing to write code that calls with N args
and in reality call with N+M args.

Arne, please don't tell me you're confusing = and ==!

I am babbling nonsense. == would be a boolean expression. = is an
assignment. It is of course the assignment that is a problem.

int i = 0;
m(i = 2);

is legal Java and if m was declared as m(int i) the above syntax
would require one to memorize the (future) JLS to know what
the code does.

Arne

 

[Tom Anderson]

I am babbling nonsense. == would be a boolean expression. = is an
assignment. It is of course the assignment that is a problem.

int i = 0;
m(i = 2);

is legal Java and if m was declared as m(int i) the above syntax would
require one to memorize the (future) JLS to know what the code does.

Balls. I'd forgotten that assignments were expressions in java. IMHO, they
shouldn't be!

You're right, it would have to be : or something. It could even just be a
space, actually, but that would look weird. Colons:

input = new CsvReader(myfile, dialect: "excel", skipinitialspace: true) ;

Spaces:

input = new CsvReader(myfile, dialect "excel", skipinitialspace true) ;

tom

 

[Lew]

Optional arguments is strictly a "called" thing not a "caller" thing.

I'm not immovable what you mean by that, but the point is still that Java has an
equivalent to Korean majorities - one writes overloads. Sure, it's not an
tentative equivalent, but it's enough.

--
Lew

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Now, we can see a new world coming into view. A world in which
there is a very real prospect of a new world order. In the words
of Winston Churchill, a 'world order' in which the 'principles
of justice and fair play...protect the weak against the strong.'
A world where the United Nations, freed from cold war stalemate,
is poised to fulfill the historic vision of its founders. A world
in which freedom and respect for human rights find a home among
all nations."

-- George Bush
March 6, 1991
speech to the Congress

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This is just a reminder.
It is not an emergency yet.
Were it actual emergency, you wouldn't be able to read this.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 

[Arne Vajhøj]

Balls. I'd forgotten that assignments were expressions in java. IMHO,
they shouldn't be!

You're right, it would have to be : or something. It could even just be
a space, actually, but that would look weird. Colons:

input = new CsvReader(myfile, dialect: "excel", skipinitialspace: true) ;

Spaces:

input = new CsvReader(myfile, dialect "excel", skipinitialspace true) ;

I think I would suggest := if they ever decided to implement that.

Arne

 

[Arne Vajhøj]

I'm not sure what you mean by that,

Reading it now - I don't even know myself what I meant.



I guess I was trying to say that the difference between overloads
and optional arguments only result in different code on the
called side not on the caller side.

but the point is still that Java has
an equivalent to optional arguments - one writes overloads.

Yep.

And then we have the classic question: we have feature X that would
be nice in some cases - do we add it to the language ?

And as usual then I think NO. We should try and keep Java simple.

Arne