Default Interfaces: possible Java extension?

T

Tom McGlynn

A commonly held principle for good programming is that we should
minimize dependencies on details of the implementation. One way to do
that in Java is with statements like:

List<String> names = new ArrayList<String>();
vs
ArrayList<String> names = new ArrayList<String>();

where the variable we use to hold the object has a type which only
allows (absent casts or reflection) use of the general contract for
List's without any visibility into the details of ArrayList's
implementation.

Here's a thought I've had for a small extension to Java that would
take this a little further. In the first example above, even though
we don't worry about the implementation after we get our list, we did
have to explicitly pick one kind of list. So...

Add a new optional element in the definition of an interface which
defines a class that does the default implementation of the
interface. E.g.,

interface List<T> default ArrayList<T> { ...}

An interface which has a default may be used in a constructor as:

List<String> name = new List<String>();

When this happens, the default class for the interface is substituted
at compilation time. If there is no default, or it is not accessible
then this is a compile time error.

This should be fully upwardly compatible, invalidating no existing
code. I don't think it would be hard to implement (e.g., a special
static field in the interface's class file) and it allows more
isolation of code from implementation. It also allows a programmer to
document a preferred implementation.

It always seems a bit odd when I'm writing code when I have to import
ArrayList and use that class just the one time. It seems like code
could be a bit cleaner using this extension.

Are there other ways to do this? A factory method requires knowing
the class the factory resides in and I can't really think of other
patterns that address this. E.g., one could add
newSet(), newList() and newMap() methods to Collections but that's not
especially elegant to my eye since there's no special language
relation between the List interface and the Collections class.

Just a thought for the weekend.

Regards,
Tom McGlynn
 
E

Eric Sosman

A commonly held principle for good programming is that we should
minimize dependencies on details of the implementation. One way to do
that in Java is with statements like:

List<String> names = new ArrayList<String>();
vs
ArrayList<String> names = new ArrayList<String>();

where the variable we use to hold the object has a type which only
allows (absent casts or reflection) use of the general contract for
List's without any visibility into the details of ArrayList's
implementation.

Here's a thought I've had for a small extension to Java that would
take this a little further. In the first example above, even though
we don't worry about the implementation after we get our list, we did
have to explicitly pick one kind of list. So...

Add a new optional element in the definition of an interface which
defines a class that does the default implementation of the
interface. E.g.,

interface List<T> default ArrayList<T> { ...}

An interface which has a default may be used in a constructor as:

List<String> name = new List<String>();

It seems to me that (in most cases, anyhow) an "interface with
a default implementation" is known as a "class." That is, with

DefaultList<String> name = new DefaultList<String>();

.... the thing on the right could be anything at all that extends
DefaultList. So, what have you gained? Maybe I'm missing something
(wouldn't be the first time), but I don't see the need.
It always seems a bit odd when I'm writing code when I have to import
ArrayList and use that class just the one time. It seems like code
could be a bit cleaner using this extension.

// Look, Ma, no one-shot imports!
List said:
Are there other ways to do this? A factory method requires knowing
the class the factory resides in and I can't really think of other
patterns that address this. E.g., one could add
newSet(), newList() and newMap() methods to Collections but that's not
especially elegant to my eye since there's no special language
relation between the List interface and the Collections class.

I think that's the crux: There's no special relationship between
an interface and its many implementations; the relationship is one-way.
Adding the other-way relation -- the ability of an interface to name a
class and say "This is My beloved Son, in Whom I am well pleased" --
doesn't seem to me to add much utility.

Besides, a hundred forty-two experts would immediately blog about
why you should override the default. ;-)
 
O

Owen Jacobson

On 2/11/2011 9:20 PM, Tom McGlynn wrote:
....

....


I think that's the crux: There's no special relationship between
an interface and its many implementations; the relationship is one-way.
Adding the other-way relation -- the ability of an interface to name a
class and say "This is My beloved Son, in Whom I am well pleased" --
doesn't seem to me to add much utility.

This proposal also "bakes in" a circular dependency between an
interface (List<T>) and its default implementation (ArrayList<T>), such
that there is no way to compile or load either class without the other.
While such circularity is sometimes hard to avoid (enums with
per-constant bodies, for example, are inherently circular), they're not
recommended style and they can lead to hard-to-debug classloading
problems if you're not careful.

I can't think of a use case for this outside of the collection types,
either, and there are already idioms for those. This feels like a
sublimated complaint about the standard library's choice of naming
conventions (List & ArrayList, rather than IList and List as with .Net
or informal protocols and list() like Python).

Interesting proposal, but I think it contains unfixable flaws.

-o
 
T

Tom McGlynn

This proposal also "bakes in" a circular dependency between an
interface (List<T>) and its default implementation (ArrayList<T>), such
that there is no way to compile or load either class without the other.
While such circularity is sometimes hard to avoid (enums with
per-constant bodies, for example, are inherently circular), they're not
recommended style and they can lead to hard-to-debug classloading
problems if you're not careful.

I can't think of a use case for this outside of the collection types,
either, and there are already idioms for those. This feels like a
sublimated complaint about the standard library's choice of naming
conventions (List & ArrayList, rather than IList and List as with .Net
or informal protocols and list() like Python).

Interesting proposal, but I think it contains unfixable flaws.

-o

While I hadn't thought of the circular dependency issue, I think that
the existence of such would depend upon the details of
implementation. If the interface included a direct reference to the
default class I think you'd be right. However suppose the interface
only has a reference to a string containing the name of the default
class. Then you can load and use the interface without loading the
default class. The compiler would know to use the class name for the
default class when the default was invoked in a constructor.

Other use cases:

This approach comes into play when interfaces are used to describe a
root type of a set of objects with different implementations, where
the root type describes the object as a whole. In many cases (perhaps
most) interfaces are used to describe only one aspect of a more
complex object (this object can move, or this object needs to be
validated, ...). You would not want to use defaults in this second
case, since you can't allocate only one aspect of an object.

In my own experience one of my long term projects involves combining
and manipulating images and my code has sets of classes for coordinate
systems, projections, samplers, classes that find objects. I would
have found it convenient to be able to say
Sampler samp = new Sampler();
to get a default sampler than to have
Sampler samp = SamplerFactory.createSampler(null);
which is more or less what I have to do now. The current approach is
a much tighter coupling of the invoking code to the sampler
implementation -- I need to know the interface, the factory class and
method, and how one gets the default. It would be nice to loosen it
up a bit. I probably wouldn't change my existing code much -- but I
would change the way I write new code.

However you are certainly correct that were this extension made, most
of the times that I'd use it would with collections. I don't think
that's a serious flaw -- collections are as basic to Java as arrays
and I use them in essentially any serious program.

Does this address the flaws you saw?

Responding more directly to Eric's comments...

I'm sure you're right that we'd bitterly complain about whatever
choices were made for defaults!

Why do I think it could be useful to bless a particular implementation
of the interface? My thought is that it's a good idea for code to
have minimal knowledge of the implementation of the objects they use.
Using defaults, the knowledge explicit in the invoking code is
reduced. The information burden moves from the invoker to the
framework designer and the temptation on the invoker to use special
features of a particular implementation is reduced.

I.e., if I want a list is it a good thing for me to have to explicitly
choose between ArrayList and TreeList and LinkedList? It's certainly
essential that I am able to make a choice if I need it, but I think it
would be better better if I can also say 'I don't care. Just give me
a list.'

Regards,
Tom McGlynn


Regards,
Tom McGlynn
 
L

Lew

While I hadn't thought of the circular dependency issue, I think that
the existence of such would depend upon the details of
implementation. If the interface included a direct reference to the
default class I think you'd be right. However suppose the interface
only has a reference to a string containing the name of the default
class. Then you can load and use the interface without loading the
default class. The compiler would know to use the class name for the
default class when the default was invoked in a constructor.

Other use cases:

This approach comes into play when interfaces are used to describe a
root type of a set of objects with different implementations, where
the root type describes the object as a whole. In many cases (perhaps
most) interfaces are used to describe only one aspect of a more
complex object (this object can move, or this object needs to be
validated, ...). You would not want to use defaults in this second
case, since you can't allocate only one aspect of an object.

In my own experience one of my long term projects involves combining
and manipulating images and my code has sets of classes for coordinate
systems, projections, samplers, classes that find objects. I would
have found it convenient to be able to say
Sampler samp = new Sampler();
Hideous.

to get a default sampler than to have
Sampler samp = SamplerFactory.createSampler(null);
which is more or less what I have to do now. The current approach is
a much tighter coupling of the invoking code to the sampler
implementation -- I need to know the interface, the factory class and
method, and how one gets the default. It would be nice to loosen it
up a bit. I probably wouldn't change my existing code much -- but I
would change the way I write new code.

However you are certainly correct that were this extension made, most
of the times that I'd use it would with collections. I don't think
that's a serious flaw -- collections are as basic to Java as arrays
and I use them in essentially any serious program.

Does this address the flaws you saw?

Just because you like 'ArrayList' doesn't mean that I do. The benefit (not
having to type five extra characters in the assignment) is laughably
microscopic. Bad idea.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|
 
E

Eric Sosman

[...]
In my own experience one of my long term projects involves combining
and manipulating images and my code has sets of classes for coordinate
systems, projections, samplers, classes that find objects. I would
have found it convenient to be able to say
Sampler samp = new Sampler();
to get a default sampler than to have
Sampler samp = SamplerFactory.createSampler(null);
which is more or less what I have to do now. The current approach is
a much tighter coupling of the invoking code to the sampler
implementation -- I need to know the interface, the factory class and
method, and how one gets the default. It would be nice to loosen it
up a bit. I probably wouldn't change my existing code much -- but I
would change the way I write new code.

Something still eludes me. You can do exactly what you've
shown, with today's Java as it stands -- if Sampler is a class.
It still seems to me that "interface with default implementation"
is not distinguishable from "class."

Are you looking for some kind of back-door multiple inheritance?
I don't see how "interface with default implementation" would be
of any help there: You could (and can) write

class Whitmans implements Sampler, Edible

.... but you'd still need to provide implementations for both. You
could not rely on the "default implementation" of Sampler to
implement Edible, nor vice versa.
However you are certainly correct that were this extension made, most
of the times that I'd use it would with collections. I don't think
that's a serious flaw -- collections are as basic to Java as arrays
and I use them in essentially any serious program.

Does this address the flaws you saw?

Responding more directly to Eric's comments...

I'm sure you're right that we'd bitterly complain about whatever
choices were made for defaults!

Why do I think it could be useful to bless a particular implementation
of the interface? My thought is that it's a good idea for code to
have minimal knowledge of the implementation of the objects they use.
Using defaults, the knowledge explicit in the invoking code is
reduced. The information burden moves from the invoker to the
framework designer and the temptation on the invoker to use special
features of a particular implementation is reduced.

I.e., if I want a list is it a good thing for me to have to explicitly
choose between ArrayList and TreeList and LinkedList? It's certainly
essential that I am able to make a choice if I need it, but I think it
would be better better if I can also say 'I don't care. Just give me
a list.'

And if the default List is some kind of highly-available multi-
machine synchronized-via-RMI-and-secured-with-crypto behemoth? "Ah,
but I know it isn't," you say -- but there you are again, cozying up
with the details of the implementation. (And backing away from "I
don't care," too.) To paraphrase the late Ken Olsen: When did you
last buy a default car?

Or, what if Java 1.9 changes the default implementation from
ArrayList to KoKoLittleList, and the latter turns out to be a poor
fit for your usage pattern? You were happy with the default not
because it was the default, but because it was ArrayList -- except
that now it isn't, and you're no longer happy.

I'll grant this much: It would be nice if Vectors and Hashtables
and StringBuffers in existing code magically transmuted to ArrayLists
and HashMaps and StringBuilders wherever possible. (In a sense, this
already happens with some StringBuffers.) But it seems to me that the
"wherever possible" is the Achilles' heel of the matter; the compiler
is ill-equipped to find such opportunities unaided.
 
D

Daniele Futtorovic

Add a new optional element in the definition of an interface which
defines a class that does the default implementation of the
interface. E.g.,

interface List<T> default ArrayList<T> { ...}

An interface which has a default may be used in a constructor as:

List<String> name = new List<String>();

When this happens, the default class for the interface is substituted
at compilation time. If there is no default, or it is not accessible
then this is a compile time error.

Adding yet more things that happen behind the scenes? That may possibly
make writing code require less thought, but make understanding code yet
more difficult?

No fucking thanks.
 
T

Tom McGlynn

Just because you like 'ArrayList' doesn't mean that I do.  

If you don't like the default you can always allocate an explicit
class. This only comes into play when you don't care what kind of
list you have. For me that's probably 90% of the time when I'm
allocating lists.

....The benefit (not
having to type five extra characters in the assignment) is laughably
microscopic.  Bad idea.

Good thing then that saving characters wasn't the reason for the
suggestion. Thanks for your careful and considered response.

Regards,
Tom McGlynn
 
I

Ian Pilcher

Are there other ways to do this? A factory method requires knowing
the class the factory resides in and I can't really think of other
patterns that address this. E.g., one could add
newSet(), newList() and newMap() methods to Collections but that's not
especially elegant to my eye since there's no special language
relation between the List interface and the Collections class.

public interface MyInterface {
static Class<? extends MyInterface> defaultImpl = MyImpl.class;
void foo();
}

public class MyImpl implements MyInterface {
public void foo() {}
}

Writing some sort of factory method that is passed MyInferface.class and
uses reflection to return an instance of MyImpl should be relatively
straitforward.
 
I

Ian Pilcher

Writing some sort of factory method that is passed MyInferface.class and
uses reflection to return an instance of MyImpl should be relatively
straitforward.

Taking things a step further, you could write a factory class that maps
the class names of interfaces to the class names of your preferred
implementations and do the same thing, with no need to modify the
interfaces.

Of course, you would have to decide which implementation of Map to use.
;-)
 
T

Tom McGlynn

On 2/12/2011 9:34 AM, Tom McGlynn wrote:

     Something still eludes me.  You can do exactly what you've
shown, with today's Java as it stands -- if Sampler is a class.
It still seems to me that "interface with default implementation"
is not distinguishable from "class."

If I make a class the top of the hierarchy, then all subsequent
implementations are locked into that inheritance tree. This idea
allows you the flexibity to create
a list or sampler completely independently of the default version. So
in cases where you needn't know anything about the implementation you
can create your object easily. In cases where you need a custom object
your are completely free to build one of your own. And of course you
still have the opportunity to pick one from the set that is defined in
the supplied API. There is maximum choice and maximum decoupling
between the framework and your code.

     Are you looking for some kind of back-door multiple inheritance?
I don't see how "interface with default implementation" would be
of any help there: You could (and can) write

        class Whitmans implements Sampler, Edible

... but you'd still need to provide implementations for both.  You
could not rely on the "default implementation" of Sampler to
implement Edible, nor vice versa.

As discussed upthread many usages of default interfaces would not be
appropriate, in particular interfaces that are used to describe one
aspect of more complex object.
....

     And if the default List is some kind of highly-available multi-
machine synchronized-via-RMI-and-secured-with-crypto behemoth?  "Ah,
but I know it isn't," you say -- but there you are again, cozying up
with the details of the implementation.  (And backing away from "I
don't care," too.)  To paraphrase the late Ken Olsen: When did you
last buy a default car?

     Or, what if Java 1.9 changes the default implementation from
ArrayList to KoKoLittleList, and the latter turns out to be a poor
fit for your usage pattern?  You were happy with the default not
because it was the default, but because it was ArrayList -- except
that now it isn't, and you're no longer happy.

That's a quality of implementation issue. Suppose Java 1.9's
implementation of ArrayList is broken? Or take your first example
positively. If there's a new wonderful
version of Lists your code might start running faster without any
change on your
part. Great stuff. If you've got a list where the access to the list
is critical
to the performance ofthe code and you know the best usage pattern,
then maybe you want
to explicitly use that. The vast majority of my lists (or objects of
any kind) are not performance critical.
     I'll grant this much: It would be nice if Vectors and Hashtables
and StringBuffers in existing code magically transmuted to ArrayLists
and HashMaps and StringBuilders wherever possible.  (In a sense, this
already happens with some StringBuffers.)  But it seems to me that the
"wherever possible" is the Achilles' heel of the matter; the compiler
is ill-equipped to find such opportunities unaided.

Alas, as you say this can't help there.


Regards,
Tom
 
T

Tom McGlynn

On 2/11/2011 6:20 PM, Tom McGlynn wrote:
...> Add a new optional element in the definition of an interface which


...

You may be interested in messages with "defender" in the subject inhttp://mail.openjdk.java.net/pipermail/lambda-dev/, the archive for the
mailing list (e-mail address removed)

The defender method idea is different, but closely related. It would let
the writer of an interface specify a default for a method. The primary
use-case is adding methods to an interface without forcing immediate
changes to all implementing classes.

For example, the defender method for a new optional method could simply
throw UnsupportedOperationException.

I think you could learn a lot about the relevant issues by reading the
discussion.

Patricia

Thanks Patricia, that looks pretty interesting.

Regards,
Tom McGlynn
 
L

Lew

Tom said:
If I make a class the top of the hierarchy, then all subsequent
implementations are locked into that inheritance tree. This idea
allows you the flexibity to create
a list or sampler completely independently of the default version. So
in cases where you needn't know anything about the implementation you
can create your object easily. In cases where you need a custom object
your are completely free to build one of your own. And of course you
still have the opportunity to pick one from the set that is defined in
the supplied API. There is maximum choice and maximum decoupling
between the framework and your code.
...

Maybe this will give you enough of what you're looking for:
http://cr.openjdk.java.net/~briangoetz/lambda/Defender Methods v3.pdf
part of
http://cr.openjdk.java.net/~briangoetz/lambda/

http://gafter.blogspot.com/2010/08/couple-of-comments-on-defender-methods.html

http://www.baptiste-wicht.com/2010/05/java-7-add-public-defender-methods-to-java-interfaces/

This serves a different primary purpose but might suffice for what you're
seeking. Otherwise I simply fail to see what it costs just to name a class
that you want instead of letting the interface pick it, or to use a factory
method. Keeping it anonymous with a slightly shorter syntax, while I see an
argument for a little benefit, just doesn't seem worth changing the language
for such slight benefit. Especially if other mechanisms already slated for
inclusion help soften the blow.
 
L

Lew

Daniele said:
Adding yet more things that happen behind the scenes? That may possibly
make writing code require less thought, but make understanding code yet
more difficult?

No fucking thanks.

+1.
 
A

Arne Vajhøj

While I hadn't thought of the circular dependency issue, I think that
the existence of such would depend upon the details of
implementation. If the interface included a direct reference to the
default class I think you'd be right. However suppose the interface
only has a reference to a string containing the name of the default
class. Then you can load and use the interface without loading the
default class. The compiler would know to use the class name for the
default class when the default was invoked in a constructor.

Using a string in that way is the equivalent of using reflection
every time you use the new.

And it will not have any compile time check whether the class
exists or not.

If the compiler checks then the circular ref is back!

Arne
 
A

Arne Vajhøj

A commonly held principle for good programming is that we should
minimize dependencies on details of the implementation. One way to do
that in Java is with statements like:

List<String> names = new ArrayList<String>();
vs
ArrayList<String> names = new ArrayList<String>();

where the variable we use to hold the object has a type which only
allows (absent casts or reflection) use of the general contract for
List's without any visibility into the details of ArrayList's
implementation.

Here's a thought I've had for a small extension to Java that would
take this a little further. In the first example above, even though
we don't worry about the implementation after we get our list, we did
have to explicitly pick one kind of list. So...

Add a new optional element in the definition of an interface which
defines a class that does the default implementation of the
interface. E.g.,

interface List<T> default ArrayList<T> { ...}

An interface which has a default may be used in a constructor as:

List<String> name = new List<String>();

When this happens, the default class for the interface is substituted
at compilation time. If there is no default, or it is not accessible
then this is a compile time error.

This should be fully upwardly compatible, invalidating no existing
code. I don't think it would be hard to implement (e.g., a special
static field in the interface's class file) and it allows more
isolation of code from implementation. It also allows a programmer to
document a preferred implementation.

It always seems a bit odd when I'm writing code when I have to import
ArrayList and use that class just the one time. It seems like code
could be a bit cleaner using this extension.

Are there other ways to do this? A factory method requires knowing
the class the factory resides in and I can't really think of other
patterns that address this. E.g., one could add
newSet(), newList() and newMap() methods to Collections but that's not
especially elegant to my eye since there's no special language
relation between the List interface and the Collections class.

The features is based on assumptions that:
- there are one implementation class that is special compared
to other implementation classes
- that implementation class is create at the same time as the
interface

Those assumption are not always met.

It violates good OO principles by interface having
some dependency on implementations.

To accomplish something similar in a better way look at the
DI/IoC frameworks that allows you to configure an implementation
to produce a certain interface.

Arne
 
S

Skydiver

Aren't we overlooking the obvious here?

private static <T> List<T> newList () { return new ArrayList<T>(); }

....

List<String> myList = newList();


and let generics type inference do the rest.

Now your default lists (in that class, anyway) are ArrayLists and you're
not repeating both List and String on every construction.

Smart javac or jit can inline the static method, too.

And if you suddenly decide you prefer LinkedList to ArrayList you can
change it for the entire class in one place.

And you can locally override by way of

List<String> myList = new SpecificListClass<String>();
 
R

Roedy Green

interface List<T> default ArrayList<T> { ...}

Without changing Java, you could get something of the effect by using
an abstract base class instead of an interface with a static "create"
method, which is a factory that might create any conceivable
implementation of the interface.

Code of the form

HashMap<String,String> h = new HashMap<String,String>( size );

violates the principle of telling a computer each fact in only one
place, as do (SomeClass) casts.

Map<String,String> h = new HashMap<String,String>( size );

is not much better. The first could in some modified Java be
abbreviated:

HashMap<String,String>( size ) h;

But there is nothing obvious you could do with the second.



--
Roedy Green Canadian Mind Products
http://mindprod.com
Refactor early. If you procrastinate, you will have
even more code to adjust based on the faulty design.
..
 
T

Tom McGlynn

I wanted to thank all of you for your comments. While it seems clear
that they're not going to be holding up Java 7 to include this idea, I
found the discussion interesting and fun. The only technical issue
that seemed to come up (i.e., related to feasibility as opposed to
desirability) was Owen Jacobson's note about the need to worry about
circular references, but I think that's pretty easy to address.

A number of people noted that you can build frameworks for getting
default classes using either an abstract root or more complex
structures possibly using reflection. All of these require that the
user know of some particular class which has the factory method or
equivalent. This couples us with some particular class hierarchy.
The motivation for me in doing this was to loosen such couplings. A
couple of comments noted that this meant more was happening under the
hood and they didn't like that. Indeed the intent is to allow -- but
not require -- the user of the framework to know less and make fewer
choices.

Particia Shanahan and Lew noted some similarities with public defender
methods which are now being actively developed as an extension. While
these is some overlap in the sense that both delegate responsibility
from one type to another, they are in some ways opposite in their
intent. My understanding is the motivation for public defender
methods is to be able to extend interfaces (again especially
collections) without actually having to rewrite all of the classes. I
don't think what I'm suggesting is particularly useful in any kind of
retrofitting, both the framework developer and the user need to be
aware of this extension for it to be useful. Also, the delegation
works in precisely the opposite direction. E.g., for public defenders
if I have an array list object and I want to be able to use a new
method (e.g., reverse()) which has no implementation in the class, I
can go back to a default implementation that's defined in the
interface. [I'm intrigued to see that the implementation is rather
like that used in Perl objects but that's a different thread.] Here
the delegation occurs in the other direction, from the interface to a
particular class implementing it.

Were the idea of defaults to go further then a lot of the issues that
are currently being addressed with regard to public defender methods,
how to deal with inheritance and such would need to be clarified, but
that's a bit premature now. My few thoughts here suggested that it
would be hard to do inheritance of defaults when an interface is
extended so it's easiest to just say they would not be inherited by
extending interfaces.

It does seem like this and public defenders might belong in some more
generic framework for handling delegation in Java. I can see on the
web suggestions for syntax for object delegation in Java that go back
at least a dozen years, but I don't think there are any immediate
plans for it. Public defenders and these interface defaults are a
kind of implementation delegation (delegating implementation of
methods and constructors respectively). I gather that public defender
methods are the only bits we're likely to see in the next few years.

Again thanks to all.

Tom McGlynn
 
A

Arne Vajhøj

I wanted to thank all of you for your comments. While it seems clear
that they're not going to be holding up Java 7 to include this idea, I
found the discussion interesting and fun. The only technical issue
that seemed to come up (i.e., related to feasibility as opposed to
desirability) was Owen Jacobson's note about the need to worry about
circular references, but I think that's pretty easy to address.

That is not a very descriptive summary.

I think it is more accurate to say that almost everybody considered
it a very bad idea and that there were several issues mentioned, which
could not be addressed.

Arne
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top