Collection vs. List vs. ??

[Jon Davis]

I'm managing "collection s" / "lists" (??) of objects that are internally
bound by an XML document, but I do NOT intend to offer an IEnumerator
interface.

For instance, with a root XML document, I might have:

<employees>
<employee><name >bob</name></employee>
<employee><name >carl</name></employee>
<employees>

... and I might have a C# class as such:

public class Employee {
public Employee(XmlNod e employeeNode) {
InnerEmployeeNo de = employeeNode;
}
private XmlNode InnerEmployeeNo de;

public string Name {
get {
return InnerEmployeeNo de.SelectSingle Node("name").In nerText;
}
}
}

.... and so now I have a "list" or "collection " of sorts as such:

public class EmployeeList {
public EmployeeList (XmlNode employeesNode) {
InnerEmployeesN ode = employeesNode;
}
private XmlNode InnerEmployeesN ode;
public Employee this[string name] {
get {
XmlNodeList employeeNodes =
InnerEmployeesN ode.SelectNodes ("employee") ;
foreach (XmlNode node in EmployeeNodes) {
if (node.SelectSin gleNode("name") == name) {
return new Employee(node);
}
}
return null;
}
}
}

So now my question is, what should I call this list type?
"EmployeeCollec tion"? "EmployeeLi st"? "EmployeeAr ray" in such a way that it
is not confusing. I myself am confused.

Thanks,
Jon

[Jay Glynn]

Re: Collection vs. List vs. ??

EmployeeNodeLis t since you are returning XmlNode.

"Jon Davis" <jon@REMOVE.ME. PLEASE.jondavis .net> wrote in message
news:ONYyTSLTDH A.2128@TK2MSFTN GP12.phx.gbl...[color=blue]
> I'm managing "collection s" / "lists" (??) of objects that are internally
> bound by an XML document, but I do NOT intend to offer an IEnumerator
> interface.
>
> For instance, with a root XML document, I might have:
>
> <employees>
> <employee><name >bob</name></employee>
> <employee><name >carl</name></employee>
> <employees>
>
> .. and I might have a C# class as such:
>
> public class Employee {
> public Employee(XmlNod e employeeNode) {
> InnerEmployeeNo de = employeeNode;
> }
> private XmlNode InnerEmployeeNo de;
>
> public string Name {
> get {
> return InnerEmployeeNo de.SelectSingle Node("name").In nerText;
> }
> }
> }
>
> ... and so now I have a "list" or "collection " of sorts as such:
>
> public class EmployeeList {
> public EmployeeList (XmlNode employeesNode) {
> InnerEmployeesN ode = employeesNode;
> }
> private XmlNode InnerEmployeesN ode;
> public Employee this[string name] {
> get {
> XmlNodeList employeeNodes =
> InnerEmployeesN ode.SelectNodes ("employee") ;
> foreach (XmlNode node in EmployeeNodes) {
> if (node.SelectSin gleNode("name") == name) {
> return new Employee(node);
> }
> }
> return null;
> }
> }
> }
>
> So now my question is, what should I call this list type?
> "EmployeeCollec tion"? "EmployeeLi st"? "EmployeeAr ray" in such a way that[/color]
it[color=blue]
> is not confusing. I myself am confused.
>
> Thanks,
> Jon
>
>[/color]

[Mark Mullin]

Re: Collection vs. List vs. ??

Why bother making an employee list at all ?

You've got a clear class here, Employee, that contains the name member
variable.

Instead of thinking of EmployeeList as an instance of a class, think
of listing employees as a static (global) method of Employee.

That is to say, the static gets called with the XmlNode, gobbles up
and instantiates the employees records, instantiating employees as it
does so (poof you're an employee), and then returns a Employee[] (or
ArrayList of.;. (or even Hashtable[empname,empInst ance].

If it turns out that you're _only_ creating employees within the
EmployeeList logic, then you can even go further, by making the
Employee constructor private. You call a public static
Employee.Employ eeListReader(Xm lNode someNode) and it returns a
collection to you.

HTH

MMM

"Jon Davis" <jon@REMOVE.ME. PLEASE.jondavis .net> wrote in message news:<ONYyTSLTD HA.2128@TK2MSFT NGP12.phx.gbl>. ..[color=blue]
> I'm managing "collection s" / "lists" (??) of objects that are internally
> bound by an XML document, but I do NOT intend to offer an IEnumerator
> interface.
>
>[/color]

[Jon Davis]

Re: Collection vs. List vs. ??

No, in this[int index] I'm returning an Employee object, and I intend to
make the XML binding transparent to users of this assembly.

Jon


"Jay Glynn" <jlsglynn@hotma il.com> wrote in message
news:eim0DBNTDH A.1288@tk2msftn gp13.phx.gbl...[color=blue]
> EmployeeNodeLis t since you are returning XmlNode.
>
> "Jon Davis" <jon@REMOVE.ME. PLEASE.jondavis .net> wrote in message
> news:ONYyTSLTDH A.2128@TK2MSFTN GP12.phx.gbl...[color=green]
> > I'm managing "collection s" / "lists" (??) of objects that are internally
> > bound by an XML document, but I do NOT intend to offer an IEnumerator
> > interface.
> >
> > For instance, with a root XML document, I might have:
> >
> > <employees>
> > <employee><name >bob</name></employee>
> > <employee><name >carl</name></employee>
> > <employees>
> >
> > .. and I might have a C# class as such:
> >
> > public class Employee {
> > public Employee(XmlNod e employeeNode) {
> > InnerEmployeeNo de = employeeNode;
> > }
> > private XmlNode InnerEmployeeNo de;
> >
> > public string Name {
> > get {
> > return InnerEmployeeNo de.SelectSingle Node("name").In nerText;
> > }
> > }
> > }
> >
> > ... and so now I have a "list" or "collection " of sorts as such:
> >
> > public class EmployeeList {
> > public EmployeeList (XmlNode employeesNode) {
> > InnerEmployeesN ode = employeesNode;
> > }
> > private XmlNode InnerEmployeesN ode;
> > public Employee this[string name] {
> > get {
> > XmlNodeList employeeNodes =
> > InnerEmployeesN ode.SelectNodes ("employee") ;
> > foreach (XmlNode node in EmployeeNodes) {
> > if (node.SelectSin gleNode("name") == name) {
> > return new Employee(node);
> > }
> > }
> > return null;
> > }
> > }
> > }
> >
> > So now my question is, what should I call this list type?
> > "EmployeeCollec tion"? "EmployeeLi st"? "EmployeeAr ray" in such a way that[/color]
> it[color=green]
> > is not confusing. I myself am confused.
> >
> > Thanks,
> > Jon
> >
> >[/color]
>
>[/color]

[Jon Davis]

Re: Collection vs. List vs. ??

> Why bother making an employee list at all ?[color=blue]
> You've got a clear class here, Employee, that contains the name member
> variable.
> Instead of thinking of EmployeeList as an instance of a class, think
> of listing employees as a static (global) method of Employee.[/color]

Why is irrelevant. The code sample is not what I'm using. And I intend to
make the XML binding transparent to the users of my assembly.

Jon


"Mark Mullin" <mullin@vibrant 3d.com> wrote in message
news:32ada3b5.0 307171911.5ec4c d5b@posting.goo gle.com...[color=blue]
> Why bother making an employee list at all ?
>
> You've got a clear class here, Employee, that contains the name member
> variable.
>
> Instead of thinking of EmployeeList as an instance of a class, think
> of listing employees as a static (global) method of Employee.
>
> That is to say, the static gets called with the XmlNode, gobbles up
> and instantiates the employees records, instantiating employees as it
> does so (poof you're an employee), and then returns a Employee[] (or
> ArrayList of.;. (or even Hashtable[empname,empInst ance].
>
> If it turns out that you're _only_ creating employees within the
> EmployeeList logic, then you can even go further, by making the
> Employee constructor private. You call a public static
> Employee.Employ eeListReader(Xm lNode someNode) and it returns a
> collection to you.
>
> HTH
>
> MMM
>
> "Jon Davis" <jon@REMOVE.ME. PLEASE.jondavis .net> wrote in message[/color]
news:<ONYyTSLTD HA.2128@TK2MSFT NGP12.phx.gbl>. ..[color=blue][color=green]
> > I'm managing "collection s" / "lists" (??) of objects that are internally
> > bound by an XML document, but I do NOT intend to offer an IEnumerator
> > interface.
> >
> >[/color][/color]

[Mark Mullin]

Re: Collection vs. List vs. ??

Why is Employee<listty pe> not equivalent to Collection of Employee ?

If you're going to create employee<somety peoflist>, what distinguishes
this list of employees from any other list beyond the contents of the
list? Is the list expected to perform operations on the set of
employees that cause it to be a specialization of an existing list
class ? If so, you may want to consider derivation from one of the
existing classes. What in your proposed architecture cares about a
set of employees as a tangible thing providing functionality distinct
from other sets of homogenous data ? Answers to those questions
should make the appropriate name leap out at you.

All that said, Employees might be perfectly fine, since you're trying
to have the name represent what it is, and you've indicated that the
nature of the list (list of XML nodes) ain't what it is.

Entia non sunt multiplicanda praeter necessitatem

[Jon Davis]

Re: Collection vs. List vs. ??

What in your proposed architecture cares about a[color=blue]
> set of employees as a tangible thing providing functionality distinct
> from other sets of homogenous data ?[/color]

None. I suppose I should ask in another way:

If I have a set of homogenous data that is indexed with this[...] and
nothing more (i.e. no IEnumerator), what is the base suffix for C# that is
considered legal in terms of standardization and readability? "-Collection"?
"-Set"?

Are you saying that the correct suffix is "-s"?
[color=blue]
> Why is Employee<listty pe> not equivalent to Collection of Employee ?[/color]

I could call it "collection of employee", but C# class names cannot be named
as such (with spaces) and it would break the conventions. So in translation
you're suggesting EmployeeCollect ion, but is it indeed a collection if it
does not implement IList, ICollection(??) , and so on?

Jon


"Mark Mullin" <mullin@vibrant 3d.com> wrote in message
news:32ada3b5.0 307180906.68179 284@posting.goo gle.com...[color=blue]
> Why is Employee<listty pe> not equivalent to Collection of Employee ?
>
> If you're going to create employee<somety peoflist>, what distinguishes
> this list of employees from any other list beyond the contents of the
> list? Is the list expected to perform operations on the set of
> employees that cause it to be a specialization of an existing list
> class ? If so, you may want to consider derivation from one of the
> existing classes. What in your proposed architecture cares about a
> set of employees as a tangible thing providing functionality distinct
> from other sets of homogenous data ? Answers to those questions
> should make the appropriate name leap out at you.
>
> All that said, Employees might be perfectly fine, since you're trying
> to have the name represent what it is, and you've indicated that the
> nature of the list (list of XML nodes) ain't what it is.
>
> Entia non sunt multiplicanda praeter necessitatem[/color]

[Jon Davis]

Re: Collection vs. List vs. ??

> > Why is Employee<listty pe> not equivalent to Collection of Employee ?

Incidentally, if you mean why shouldn't I just use a generic collection, the
answer is that a generic collection does not bind to specific XML like I
intend for it to. Nor do I want users of my assembly to have to futz with
type casting from Object.

(Please don't suggest that I just read the XML and spit out a set of objects
and throw it into a container, that is NOT disciplined C# coding. I bind to
XML because if an object changes, I want the XML to change immediately. It
is thread-safe, it is instance-safe, and it thereby eliminates a heck of a
lot of hassles. XML synchronization is the product I am selling!
http://www.powerblog.net/ )

Jon


"Jon Davis" <jon@REMOVE.ME. PLEASE.jondavis .net> wrote in message
news:eHkP7%23VT DHA.2252@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> What in your proposed architecture cares about a[color=green]
> > set of employees as a tangible thing providing functionality distinct
> > from other sets of homogenous data ?[/color]
>
> None. I suppose I should ask in another way:
>
> If I have a set of homogenous data that is indexed with this[...] and
> nothing more (i.e. no IEnumerator), what is the base suffix for C# that is
> considered legal in terms of standardization and readability?[/color]
"-Collection"?[color=blue]
> "-Set"?
>
> Are you saying that the correct suffix is "-s"?
>[color=green]
> > Why is Employee<listty pe> not equivalent to Collection of Employee ?[/color]
>
> I could call it "collection of employee", but C# class names cannot be[/color]
named[color=blue]
> as such (with spaces) and it would break the conventions. So in[/color]
translation[color=blue]
> you're suggesting EmployeeCollect ion, but is it indeed a collection if it
> does not implement IList, ICollection(??) , and so on?
>
> Jon
>
>
> "Mark Mullin" <mullin@vibrant 3d.com> wrote in message
> news:32ada3b5.0 307180906.68179 284@posting.goo gle.com...[color=green]
> > Why is Employee<listty pe> not equivalent to Collection of Employee ?
> >
> > If you're going to create employee<somety peoflist>, what distinguishes
> > this list of employees from any other list beyond the contents of the
> > list? Is the list expected to perform operations on the set of
> > employees that cause it to be a specialization of an existing list
> > class ? If so, you may want to consider derivation from one of the
> > existing classes. What in your proposed architecture cares about a
> > set of employees as a tangible thing providing functionality distinct
> > from other sets of homogenous data ? Answers to those questions
> > should make the appropriate name leap out at you.
> >
> > All that said, Employees might be perfectly fine, since you're trying
> > to have the name represent what it is, and you've indicated that the
> > nature of the list (list of XML nodes) ain't what it is.
> >
> > Entia non sunt multiplicanda praeter necessitatem[/color]
>
>[/color]