Talk:Collection of Collections Is a Code Smell - Revision history

Kevlin: Talk:Collection of Collections is a Code Smell moved to Talk:Collection of Collections Is a Code Smell

Kevlin — Sun, 05 Jul 2009 21:45:37 GMT

Talk:Collection of Collections is a Code Smell moved to Talk:Collection of Collections Is a Code Smell

←Older revision

Revision as of 21:45, 5 July 2009

Kcpeppe: Talk:Code Smell, Collection of Collections moved to Talk:Collection of Collections is a Code Smell: better title

Kcpeppe — Mon, 02 Mar 2009 14:30:40 GMT

Talk:Code Smell, Collection of Collections moved to Talk:Collection of Collections is a Code Smell: better title

←Older revision

Revision as of 14:30, 2 March 2009

Kcpeppe at 13:56, 4 February 2009

Kcpeppe — Wed, 04 Feb 2009 13:56:51 GMT

←Older revision		Revision as of 13:56, 4 February 2009
Line 22:		Line 22:
	Hi Michael,		Hi Michael,

-	Nice review. I don't want to use Generics for a number of reasons. The foremost reason is that it distracts from my main point which still applies with or without the use of generics. ~~Also, this code differs in functionality from the code that~~ I'~~m using in my~~ example. ~~The use of and performance penalty of~~ using ~~an iterator is unnecessary. I can also argue against the use of~~ Generics ~~in this case with the claim that designing with generics~~ robs you of a home for behaviors ~~that are associated with the relationships and other state that would be expressed in the missing design element (the missing class)~~.	+	Nice review. I don't want to use Generics for a number of reasons. The foremost reason is that it distracts from my main point which still applies with or without the use of generics. I don't want to get tunneled on this specific example. There are others that are more complex in nature where using Generics robs you of have home for associated behaviors.

	Kevlin pointed out a second point, CompoundKey. Ok, well whats in a name ;-). It is a technical object that represents a kind of CompositeKey. So, I guess I could have named it PersonNameCompositeKey signifying its specialization.		Kevlin pointed out a second point, CompoundKey. Ok, well whats in a name ;-). It is a technical object that represents a kind of CompositeKey. So, I guess I could have named it PersonNameCompositeKey signifying its specialization.

	Kirk		Kirk

Kcpeppe at 13:54, 4 February 2009

Kcpeppe — Wed, 04 Feb 2009 13:54:10 GMT

←Older revision		Revision as of 13:54, 4 February 2009
Line 22:		Line 22:
	Hi Michael,		Hi Michael,

-	Nice review. I don't want to use Generics for a number of reasons. The foremost reason is that it distracts from my main point which still applies with or without the use of generics. Also, this code differs in functionality from the code that I'm using in my example. The use of and performance penalty of using an iterator is unnecessary. I can also argue against the use of Generics in this case with the claim that designing with generics robs you of a home for behaviors that are associated with the relationships and other state that would be expressed in the missing design element (the missing class)~~. In other words, this is not an appropriate use of Generics IMHO and I certainly wouldn't condone it by giving it a place in an example~~.	+	Nice review. I don't want to use Generics for a number of reasons. The foremost reason is that it distracts from my main point which still applies with or without the use of generics. Also, this code differs in functionality from the code that I'm using in my example. The use of and performance penalty of using an iterator is unnecessary. I can also argue against the use of Generics in this case with the claim that designing with generics robs you of a home for behaviors that are associated with the relationships and other state that would be expressed in the missing design element (the missing class).

-	~~Kirk~~	+	Kevlin pointed out a second point, CompoundKey. Ok, well whats in a name ;-). It is a technical object that represents a kind of CompositeKey. So, I guess I could have named it PersonNameCompositeKey signifying its specialization.

	Kirk		Kirk

Kcpeppe at 13:41, 4 February 2009

Kcpeppe — Wed, 04 Feb 2009 13:41:16 GMT

←Older revision		Revision as of 13:41, 4 February 2009
Line 20:		Line 20:
	--[[User:Michael Hunger\|Michael Hunger]] 18:36, 26 January 2009 (PST)		--[[User:Michael Hunger\|Michael Hunger]] 18:36, 26 January 2009 (PST)

-	Hi Michael, ~~Because~~ it distracts from my main point which still applies with or without the use of generics. ~~Maybe~~ this example is ~~too simple to expose~~ the ~~dangers~~ of ~~only relying on~~ generics for the ~~solution~~. In this ~~case there is no behavioral loss to using generics. However, that~~ is not ~~always the case~~.	+	Hi Michael,
		+
		+	Nice review. I don't want to use Generics for a number of reasons. The foremost reason is that it distracts from my main point which still applies with or without the use of generics. Also, this code differs in functionality from the code that I'm using in my example. The use of and performance penalty of using an iterator is unnecessary. I can also argue against the use of Generics in this case with the claim that designing with generics robs you of a home for behaviors that are associated with the relationships and other state that would be expressed in the missing design element (the missing class). In other words, this is not an appropriate use of Generics IMHO and I certainly wouldn't condone it by giving it a place in an example.
		+
		+	Kirk

	Kirk		Kirk

Kcpeppe at 13:29, 4 February 2009

Kcpeppe — Wed, 04 Feb 2009 13:29:20 GMT

←Older revision		Revision as of 13:29, 4 February 2009
Line 19:		Line 19:

	--[[User:Michael Hunger\|Michael Hunger]] 18:36, 26 January 2009 (PST)		--[[User:Michael Hunger\|Michael Hunger]] 18:36, 26 January 2009 (PST)
		+
		+	Hi Michael, Because it distracts from my main point which still applies with or without the use of generics. Maybe this example is too simple to expose the dangers of only relying on generics for the solution. In this case there is no behavioral loss to using generics. However, that is not always the case.
		+
		+	Kirk

Michael Hunger: New page: Why not name the CompoundKey by its DomainName i.e. ''Name''. And indexing persons to FirstName, LastName is just one view on a PeopleList. That generic List for people could have differen...

Michael Hunger — Tue, 27 Jan 2009 02:36:00 GMT

New page: Why not name the CompoundKey by its DomainName i.e. ''Name''. And indexing persons to FirstName, LastName is just one view on a PeopleList. That generic List for people could have differen...

New page

Why not name the CompoundKey by its DomainName i.e. ''Name''. And indexing persons to FirstName, LastName is just one view on a PeopleList. That generic List for people could have different projections for different views (indices) that use their own indexing. e.g. something like this (just typed in here not thrown at a compiler)

<pre>
class People {
private final Collection<Person> people=new ArrayList<Person>();
public People(Collection<Person> people) {
this.people.addAll(people);
}
public <T extends Projection> SortedMap<T,Person> projectTo(T index) {
SortedMap<T,Person> projection=new TreeMap<T,Person>();
for (Person person : people) {
projection.put(index.from(person), person);
}
return projection;
}
</pre>

[http://www.jexp.de/demotivators/cascading_collections.jpg Cascading Collection Poster]

--[[User:Michael Hunger|Michael Hunger]] 18:36, 26 January 2009 (PST)