Java Collections List : Converting from List '<Column <String1,String2>>' to 'List <String1>'

A

asil klin

I have a function that returns a list like this:-

List <Column <String1, String2>>

Next I want to pass this list to a 2nd function, but 2nd function just needs a list which contains only 1st part (string1) of the Column(s) of the above list.

So I want pass just this list to 2nd function:-

List <String1>

What would be the best way to do this ??

[my use case: Both the functions are from a library that I use to access database(Cassandra) for a web application. 1st function gives me a list of all columns which has two parts name(String1) and value(String2). So 1st function gives me a list of all columns(each of which has two strings) then I just need to use the list of column names to supply it to 2nd function that'll query the DB for those columns.]
 
D

Daniele Futtorovic

But you can accomplish much the same sort of thing, albeit with not
quite as concise a call site (but at least the entire collection doesn't
have to be duplicated). For example:


public interface Select<T, S>
{
S select(T t);
}


public class Iterables
{
public static <T, S> Iterable<S> Select(Iterable<T> source, Select<T, S>
select)
{
return new SelectIterable<T, S>(source, select);
}

private static class SelectIterable<T, S> implements Iterable<S>
{
private final Iterable<T> source;
private final Select<T, S> select;

public SelectIterable(Iterable<T> source, Select<T, S> select)
{
this.source = source;
this.select = select;
}

@Override
public java.util.Iterator<S> iterator()
{
return new Iterator(source.iterator());
}

private class Iterator implements java.util.Iterator<S>
{
private final java.util.Iterator<T> source;

public Iterator(java.util.Iterator<T> source)
{
this.source = source;
}

@Override
public boolean hasNext()
{
return source.hasNext();
}

@Override
public S next()
{
return SelectIterable.this.select.select(source.next());
}

@Override
public void remove()
{
throw new UnsupportedOperationException();
}
}
}
}


public class Column
{
private final String string1;
private final String string2;

public Column(String string1, String string2)
{
this.string1 = string1;
this.string2 = string2;
}

public String getString1() { return string1; }
public String getString2() { return string2; }
}


import java.util.ArrayList;
import java.util.List;

public class Main
{

/**
* @param args
*/
public static void main(String[] args)
{
List<Column> columns = new ArrayList<Column>();

columns.add(new Column("1", "A"));
columns.add(new Column("2", "B"));
columns.add(new Column("3", "C"));

method2(Iterables.Select(columns, new Select<Column, String>()
{
public String select(Column column)
{
return column.getString1();
}
}));
}

private static void method2(Iterable<String> names)
{
for (String name : names)
{
System.out.println(name);
}
}

}

This is what I'd suggest, too. Although I'd call it 'map' rather than
'select'. And I would recommend going the whole way and making it a
(read-only) collection (by extending AbstractCollection) or a
(read-only) List (by extending AbstractList), rather than using only
Iterable. Iterable is OK, but lacks useful features (notably, size())
for the more than basic uses. And since you're writing some code
already, might as well put in a little extra effort and get the whole bang.

I've written a little framework exactly like this some time ago. It is
insanely useful -- which shouldn't come as a surprise for anyone who's
ever heard of functional programming.

Note that the main advantage is that this approach is that it reflects
modifications of the underlying object transparently, and thus blends in
very nicely with an object-oriented structure.
 
D

Daniele Futtorovic

The word "select" simply came from my exposure to .NET. Actually, I
find the word "project" (as a verb) to be more appropriate, though I
agree "map" is fine too.

I don't think the precise name is going to matter too much. :)
Sure.


It will depend on how one intends to use it. Again, because I am
following the .NET model, Iterable is the first choice only due to
that.

However, it's worth pointing out that Iterable allows for sequences
larger than 2GB items, while extending AbstractList or
AbstractCollection, because those classes use an int to describe
their length (and in the case of AbstractList, to enumerate as
well).

Good point; I hadn't thought of that. Still, as the underlying structure
is already one that is constrained by the 2^31 -1 limit (being, in the
OP's case, a java.util.List), and considering how the overwhelming
majority of use-cases would fall hither of that limit, I think it would
be safe to code for these uses. Might of course make the Iterable
available, too.

Also, using Iterable means that the code is usable for a broader
range of inputs. I.e. is more re-usable. Extending AbstractList or
AbstractCollection will limit the uses to wrapping lists or
collections.

Now I'm not sure you got what I meant. I meant that the content-mapping
code you showed for Iterable structures could be extended so that the
"view" objects would be Collections, when mapping the contents of any
class implementing Collection, or Lists, when mapping the contents of
any class implementing List; and that it's very easy to do by making the
"view" Object extend Abstract(Collection|List), because you only have a
very few methods to implement (provided you make them read-only -- if
they're writable it becomes slightly more tricky).

I agree that Iterable is an interface that serves broader purposes and
can be implemented by a wider range of objects than Collection et al.,
but nevertheless a great share of the code (my code, at least) consists
of working with Collections. It's fine if it's broad, but not if it
being broad lessens its usefulness.

..NET addresses that lack by including the extension method Count()
(in my code, that would show up as a static method in the Iterables
class), which checks for common interfaces that support a direct
retrieval of the collection length, and if those are not available,
then enumerates the entire collection as a fall-back.

Is that the equivalent of this "defender methods" stuff I've been
hearing about?

I'm not sure I'd call that the _main_ advantage. In fact, it can be a
bit of a pitfall in .NET, as chained enumerators are all re-run each
time you enumerate the last link of the chain.

Not only is it a potential performance issue, variable capturing can
result in some non-intuitive (and often unintended) results, because
even the parameters of the enumerations may be changed after the
fact, having effect on subsequent enumerations of the new enumerable
object.

But it definitely can be a very handy aspect of the approach, if one
is careful to mind the implications of the implementation.

Sorry but you totally lost me there.

I wouldn't claim for a second that these things are going to be very
efficient. To me, the main use is as a specific "view" of a given
structure, short-term objects which I'm going briefly to manipulate and
then discard. In those cases, there is next to no performance impact,
because what the view is doing, I would have to do if I didn't have it
-- it just hides it and provides a handy syntax, making the application
logic clearer.
 
A

Arne Vajhøj

I respect Goetz, but it's a lousy name. IMO.

He explains the name in the text.

I don't have a problem with it.

But I think that the headline should be "virtual extension methods"
because that is what it is all about. The "defender methods" is
just a part of it.

Arne
 
A

Arved Sandstrom

He explains the name in the text.

I don't have a problem with it.

But I think that the headline should be "virtual extension methods"
because that is what it is all about. The "defender methods" is
just a part of it.

Arne
I know he explained it; I read the paper. :) But it was an unnecessary
and cutesy name. What's wrong with virtual extension method? If Goetz'
pet name takes off then it'll be just more useless jargon to confuse
novices...and without having read the specific explanation for it, the
name isn't even meaningful.

Like I said, I respect the guy a great deal. But I'll take him up on his
implied out, when he says "you could call these “public defenderâ€
methods...". I could, but I won't. :)

AHS
 
R

Roedy Green

What would be the best way to do this ??

you pretty well have to create a new list and copy the items over one
at a time.
--
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.
..
 
L

Lew

@glegroupsg2000goo.googlegroups.com>, (e-mail address removed) says...
I have a function that returns a list like this:-

List<Column<String1, String2>>

Next I want to pass this list to a 2nd function, but 2nd function just needs a list which contains only 1st part (string1) of the Column(s) of the above list.

So I want pass just this list to 2nd function:-

List<String1>

What would be the best way to do this ??
[my use case: Both the functions are from a library that I use to
access database(Cassandra) for a web application. 1st function gives
me a list of all columns which has two parts name(String1) and value
(String2). So 1st function gives me a list of all columns(each of
which has two strings) then I just need to use the list of column
names to supply it to 2nd function that'll query the DB for those
columns.]

Naive Solution:

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

This does not fulfill the OP's condition that the list's base type be 'String1'.

A singularly poorly-named type, to be sure, but the one they asked for.
 
D

Daniele Futtorovic

I don't know if I understand what you mean either. I wouldn't want to
have to write the code three different times, implementing Iterable,
List, _and_ Collection. But that sounds like what you're proposing.

Yes, of course.

So, given:

interface Mapper<In, Out> {
Out map( In in );
}

You'd have (possibly statically somewhere):

<In, Out> Iterable<Out> createProjection( final Iterable<? extends
In> iterable, final Mapper<? super In, ? extends Out> mapper );


<In, Out> Collection<Out> createProjection( Collection<? extends
In> coll, Mapper<? super In, ? extends Out> mapper );

<In, Out> List<Out> createProjection( List<? extends In> list,
Mapper<? super In, ? extends Out> mapper );

And for the less faint-hearted:

<K, In, Out> Map<K, Out> createProjection( Map<K, ? extends In>
map, Mapper<? super In, ? extends Out> mapper );

And for the truly brave:

<K, In, Out> SortedMap<K, Out> createProjection( SortedMap<K, ?
extends In> map, Mapper<? super In, ? extends Out> mapper );

If that's too much code to write for you, considering it's a toolset and
the power it brings, then might as well stay in bed, if I may say so.

In a full-blown implementation, you can provide List- and
Collection-like features in the Iterables class in the same way I
pointed out a size() method can be implemented: check for List or
Collection and use that implementation if present, otherwise iterate
through the Iterable to achieve it "the hard way".

Disagreed. The projection should be isomorphic. If you need size and
only have an Iterable to work with, then something's wrong with your
data structures in the first place.

<snip />'d the rest due to agreement.
 
L

Lew

Nitpicking.
I understood rather that the OP was asking for an algorithm to extract
one of both values. Changing the types to the own requirements is even
more trivial.

So you think attention to detail doesn't matter.

You are wrong.

"Nitpicking", as you attempt to disparage it, is vital to good programming. I
guess you're not a good programmer.

Learn to nitpick. The difference between 'String1' and 'String' is likely to
be significant in the real world. Your casual attitude will create bugs.
 
L

Lars Enderin

So you think attention to detail doesn't matter.

You are wrong.

"Nitpicking", as you attempt to disparage it, is vital to good
programming. I guess you're not a good programmer.

Learn to nitpick. The difference between 'String1' and 'String' is
likely to be significant in the real world. Your casual attitude will
create bugs.

Come on!
It's obvious that the OP did not intend that String1 and String2 should
be anything other than String. He used 1 and 2 to indicate which of the
String's should be placed in the derived List.
 
L

Lew

Come on!
It's obvious that the OP did not intend that String1 and String2 should

You call it "obvious". In my work I have been corrected many, many times for
assuming what I thought was "obvious", only to find out the specification was
intended as stated.
be anything other than String. He used 1 and 2 to indicate which of the
String's should be placed in the derived List.

You base that on zero evidence, only your own assumptions. I, on the other
hand, assume the OP meant precisely what he wrote. But you go right ahead and
invent interpretations for him that are not what he said, sport.
 
L

Lew

..on zero evidence.

Huh? He wrote it. That's not "zero" evidence. It's the evidence of the
actual post. Go back and read it. You will see:
So I want pass just this list to 2nd function:-

List <String1>

There's your evidence, right there. Right in black and white. Concretely.
Posted and archived. Look. Right there. It says, "String1". See?

Think I'm misquoting him? You can check for yourself.
 
A

Andreas Leitgeb

Lew said:
Huh? He wrote it. That's not "zero" evidence.

That ${someone} wrote ${something} is not "evidence" for
that ${someone} actually meant ${something}.

It's generally a strong indication, so your assumption wasn't
generally weak, but still it's no evidence.

Otoh, the stranger ${something} is (e.g. using String1 without
further explanation of it), the weaker is even the indication.
 
L

Lew

That ${someone} wrote ${something} is not "evidence" for
that ${someone} actually meant ${something}.

Of course it is.

What other evidence do you have forwhat they mean?
It's generally a strong indication, so your assumption wasn't
generally weak, but still it's no evidence.

"Indication" is a synonym for "evidence", so you just disproved your
own thesis.
Otoh, the stranger ${something} is (e.g. using String1 without
 further explanation of it), the weaker is even the indication.

It's the only evidence you have.

How can you say that what someone says is not evidence of what they
mean? That's crazy talk!

If you're not going to be intellectually honest, I'm not going to
play.
 
L

Lars Enderin

2011-03-03 18:00, Lew skrev:
Of course it is.

What other evidence do you have forwhat they mean?


"Indication" is a synonym for "evidence", so you just disproved your
own thesis.


It's the only evidence you have.

How can you say that what someone says is not evidence of what they
mean? That's crazy talk!

If you're not going to be intellectually honest, I'm not going to
play.

You are being ridiculous. The OP has not returned to the thread (scared
off by you?) we have no way to tell exactly what he meant with:

"I have a function that returns a list like this:-

List <Column <String1, String2>>

Next I want to pass this list to a 2nd function, but 2nd function just
needs a list which contains only 1st part (string1) of the Column(s) of
the above list.

So I want pass just this list to 2nd function:-

List <String1>

What would be the best way to do this ??

[my use case: Both the functions are from a library that I use to access
database(Cassandra) for a web application. 1st function gives me a list
of all columns which has two parts name(String1) and value(String2). So
1st function gives me a list of all columns(each of which has two
strings) then I just need to use the list of column names to supply it
to 2nd function that'll query the DB for those columns.]"


There is no evidence that his problem definition was meant to be
rigorous. The most likely interpretation is that String1 and String2
stand for the first and second String. Note the reference to "string1".
His problem formulation may be deficient, but you are being anal.

It's much less likely that he actually refers to two new types, String1
and String2.
 
L

Lew

Lars said:
It's much less likely that he actually refers to two new types, String1
and String2.

That's a different statement from, "There's no evidence that he
actually refers to two new types."

You can make (in this case unfounded) assertions about likelikhood and
I won't question that. But to claim there's "no evidence" when we
have the actual verbiage from the OP is stupid. Of course there's
evidence. Maybe not conclusive, but it's evidence.

You are the one being ridiculous making statements countervailing
claims I have not made. I said I chose to believe what the OP said,
instead of inventing a different meaning, and you all dumped a load of
manure on me claiming there's "no evidence" that the OP meant what he
said. Well, the statement is evidence in and of itself. You call
that "ridiculous". But it's true nonetheless.

What is ridiculous is to insist that the OP meant something
*different* from what he said with no evidence. The burden of proof
is on the assertion that the meaning is different. It's exactly the
kind of stupid assumption you all are making, "They *must* have meant
something different from the spec", that gets programmers in trouble.

I've been called to account by customers for this kind of mistake.
It's not theoretical.
 
A

Andreas Leitgeb

Lew said:
That ${someone} wrote ${something} is not "evidence" for
that ${someone} actually meant ${something}.
Of course it is.
What other evidence do you have forwhat[sic] they mean?

Your definition of "evidence" seem to be incompatible.

Wikipedia says:
"Evidence in its broadest sense includes everything that is
used to determine or demonstrate the truth of an assertion.
[...]
Evidence is the currency by which one fulfills the burden
of proof."

That doesn't sound like synonym to indication, to me.

Oh, and by your own logic&terms, we have now strong "evidence",
that you *meant* to create the new word "forwhat"...
 

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

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top