Hi
Straight to the point - I don't understand why System.Array derives
from IList (given the methods/properties actually on IList).
When designing an interface you specify a contract. Deriving from an
interface and only implementing some of it means something is wrong:
either the interface specification is wrong e.g. not minimal or the
derivation is wrong e.g. the type can't actually honour this contract.
Firstly, an array is fixed size so it doesn't make sense for it to
implement Add/Remove methods anyway (these appear on IList). So, they
throw exceptions but I don't think that Array should even need to be
implementing these in the first place!
Secondly, for an array, what does IList provide that System.Array
would not have otherwise? *Nothing* as far as I can see. So what's it
there for?
Thirdly, I think the actual current implementation is half-baked
anyway. For instance, get an IList from an Array with some objects and
call Clear. Then call Count. Then notice that Count isn't 0 - it
hasn't been synched by Clear. I realise that the specification of
Clear doesn't require this (see the docs) but still, you'd expect it
here.
Fourthly, I think the IList property IsFixedSize is strange. If a data
structure is fixed size it shouldn't have to implement Add/Remove
methods because it doesn't make sense. So there should be two separate
interfaces for fixed size data structures and for variable size data
structures.
These are just my ideas using really basic design guidelines. I'm
probably missing something or not seeing the full picture so some help
in this direction would be useful!
Thanks
Emma Middlebrook em************* *@fastmail.fm 4 7295
You should've started with the 4th item because an answer to it would kind
of eliminate #1. The fact that they made one interface instead of two - I'd
say it's just a matter of taste. I kind of like having one, - less hassle
when you need to find out if the collection is readonly - no need to query
another interface. Besides, IList has a good description, as documentation
states - "Represents a collection of objects that can be individually
accessed by index.". I think the design does not contradict the description.
I don't quite understand what's that confusing about #2? The fact that Array
is implementing IList is just a matter of followind the pattern - all
collection classes in .NET implement either/some/all of these: IEnumerable,
ICollection, IList. And some pieces of functionality are based on using the
interfaces. For instance you can bind Array or ArrayList to a grid because
they both expose IList...
As far as #3 goes - well contains the answer, doesn't it? The docs say:
"Implementation s of this method can vary in how they handle the
ICollection.Cou nt and the capacity of a collection. Typically, the count is
set to zero. The capacity can be set to zero or a default value, or it can
remain unchanged." Hmmm.... In this particular implementation, calling Clear
doesn't change Count.... but that's documented, right? :)
Sincerely,
Val.
"emma middlebrook" <em************ **@fastmail.fm> wrote in message
news:e2******** *************** ***@posting.goo gle.com... Hi
Straight to the point - I don't understand why System.Array derives from IList (given the methods/properties actually on IList).
When designing an interface you specify a contract. Deriving from an interface and only implementing some of it means something is wrong: either the interface specification is wrong e.g. not minimal or the derivation is wrong e.g. the type can't actually honour this contract.
Firstly, an array is fixed size so it doesn't make sense for it to implement Add/Remove methods anyway (these appear on IList). So, they throw exceptions but I don't think that Array should even need to be implementing these in the first place!
Secondly, for an array, what does IList provide that System.Array would not have otherwise? *Nothing* as far as I can see. So what's it there for?
Thirdly, I think the actual current implementation is half-baked anyway. For instance, get an IList from an Array with some objects and call Clear. Then call Count. Then notice that Count isn't 0 - it hasn't been synched by Clear. I realise that the specification of Clear doesn't require this (see the docs) but still, you'd expect it here.
Fourthly, I think the IList property IsFixedSize is strange. If a data structure is fixed size it shouldn't have to implement Add/Remove methods because it doesn't make sense. So there should be two separate interfaces for fixed size data structures and for variable size data structures.
These are just my ideas using really basic design guidelines. I'm probably missing something or not seeing the full picture so some help in this direction would be useful!
Thanks
Emma Middlebrook em************* *@fastmail.fm
From what you're saying, Val, I don't see how you could criticize an
interface like this one:
public interface IBoxer {
bool IsCerealBoxer {get;}
bool IsAthleticBoxer {get;}
bool IsCanineBoxer {get;}
void FillCerealInBox ();
void MoveAssemblyLin e();
void Yawn();
void RightPunch();
void LeftJab();
void BiteEar();
void Bark();
void PlayDead();
void Shake();
}
My point is that things that are different should be in different
interfaces. Read only arrays and variable size arrays have many things in
common. So do cereal boxers with athletic boxers. (Both are human, both have
jobs, etc.) But they don't have enough in common to warrant putting them in
the same interface.
I'm with ya, emma.
Chris
"Val Savvateev" <ov*********@me ridium.com_NO_S PAM> wrote in message
news:#u******** ******@TK2MSFTN GP09.phx.gbl... "emma middlebrook" <em************ **@fastmail.fm> wrote in message news:e2******** *************** ***@posting.goo gle.com... "Val Savvateev" <vs********@mer idium.com_NO_SP AM> wrote in message news:<uM******* *******@TK2MSFT NGP10.phx.gbl>. .. You should've started with the 4th item because an answer to it would kind of eliminate #1. The fact that they made one interface instead of
two - I'd say it's just a matter of taste. I kind of like having one, - less hassle when you need to find out if the collection is readonly - no need to query another interface. Besides, IList has a good description, as documentation states - "Represents a collection of objects that can be individually accessed by index.". I think the design does not contradict the description. I don't believe it's a matter of taste - an interface has an implicit contract. You can't argue that because the documentation says it can be used to access by index then it's OK. IList has semantics suitable for data structures whose size can vary. Not quite correct... Let's put it this way - IList sematics show that it
can be applied to structures of variable _or_ fixed size (depending on the
value of IsFixedSize property). The structures could also be readonly (you can
or cannot update particular elements based on the value of IsReadOnly property). I think you underestimate the presense of the mentioned properties. Also, isn't it logical after all that if you can update particular elements using an interface then you also should be able to add/remove the elements through the same interface....
If this interface was aimed at fixed size It was not. That's the point.
data structures then it's clearly wrong because fixed size data structures cannot be expected to implement some of its members e.g. Add/Remove!!
See value of IsFixedSize. I dont see any problem with that.
So, anyway, the IList itself is fine. It's just not appropriate to derive an Array from it.
Hmm... "just not apporpriate" is not quite an argument... Why not appropriate?
Some of the functionality you say you like should be factored out as it's orthogonal functionality to a list and maybe common to all data structures. Then there'd be nothing wrong with Array and other collections deriving from that new interface.
Well... I see your point, and it would be valid if the interface was
missing the two properties. I still think it was just matter of taste and let me illustrate why. If the design was your way it would contain two interfaces (or more) instead of single IList, something like this (pseudo-code):
IList { obect Item(index) {set;get;} int IdexOf(item) bool Contains(item) bool IsReadOnly }
IListManager { Add() Insert() Remove() Clear() ....etc }
Now imagine, I'm implementing my own datagrid. The grid should be editable and allow for deleting and adding items based on whether the list is fixedsize. My initialization code for both designes would be different... but just alittle........
In case of the proposed design: Init(object source) { IList _items = source as IList; IListManage _manager = source as IListManager; bool _isFixedSize = (_manager != null); }
In case of the current design I would not need to query for the manager interface and I would just use properties on IList:
Init(object source) { IList _items = source as IList; }
Datagrid would also be a good argument for having everything in one interface - when you see list of items on the screen it's either editable
or not (IsReadOnly) and you either can add/remove items or not (IsFixedSize).. ... "Manageabil ity" of the list does not disprove the fact that it's just a list.... I don't quite understand what's that confusing about #2? The fact that Array is implementing IList is just a matter of followind the pattern - all collection classes in .NET implement either/some/all of these: IEnumerable, ICollection, IList. And some pieces of functionality are based on
using the interfaces. For instance you can bind Array or ArrayList to a grid because they both expose IList... I'm not confused, it just seems wrong. What is your pattern - you just say some collections implement some interfaces?
Yep.... Ultimately all the collections in the library implement
IEnumerable (ICollection iherits IEnumerable, IList iherits ICollection) :
http://msdn.microsoft.com/library/en...collectionsien
umerableclassto pic.asp?frame=t rue Binding ... would explain a little further for my own education how this works and the importance of IList in this - that would be appreciated as I don't know much about binding. http://msdn.microsoft.com/library/en...windowsformsda
tagridclassdata sourcetopic.asp ?frame=true IList is the simplest structure that can be used in binding...
As far as #3 goes - well contains the answer, doesn't it? The docs
say: "Implementation s of this method can vary in how they handle the ICollection.Cou nt and the capacity of a collection. Typically, the
count is set to zero. The capacity can be set to zero or a default value, or it can remain unchanged." Hmmm.... In this particular implementation, calling Clear doesn't change Count.... but that's documented, right? :) Yes, I know but I still think that's bad, documented or not!
Well, you see, I told ya! - just a matter of taste ("i know, but...") ...
:) List the discussion....
Val
Cheers for your comments and discussion - I'm just saying really that the IList interface should be factored out so Array can derive from nicely defined interfaces each of which asks it to implement methods that it can actually do!
Emma Middlebrook em************* *@fastmail.fm
Sincerely, Val.
"emma middlebrook" <em************ **@fastmail.fm> wrote in message news:e2******** *************** ***@posting.goo gle.com... > Hi > > Straight to the point - I don't understand why System.Array derives > from IList (given the methods/properties actually on IList). > > When designing an interface you specify a contract. Deriving from an > interface and only implementing some of it means something is wrong: > either the interface specification is wrong e.g. not minimal or the > derivation is wrong e.g. the type can't actually honour this
contract. > > Firstly, an array is fixed size so it doesn't make sense for it to > implement Add/Remove methods anyway (these appear on IList). So,
they > throw exceptions but I don't think that Array should even need to be > implementing these in the first place! > > Secondly, for an array, what does IList provide that System.Array > would not have otherwise? *Nothing* as far as I can see. So what's
it > there for? > > Thirdly, I think the actual current implementation is half-baked > anyway. For instance, get an IList from an Array with some objects
and > call Clear. Then call Count. Then notice that Count isn't 0 - it > hasn't been synched by Clear. I realise that the specification of > Clear doesn't require this (see the docs) but still, you'd expect it > here. > > Fourthly, I think the IList property IsFixedSize is strange. If a
data > structure is fixed size it shouldn't have to implement Add/Remove > methods because it doesn't make sense. So there should be two
separate > interfaces for fixed size data structures and for variable size data > structures. > > These are just my ideas using really basic design guidelines. I'm > probably missing something or not seeing the full picture so some
help > in this direction would be useful! > > Thanks > > Emma Middlebrook > em************* *@fastmail.fm
I see your sarcazm, but I don't think your example is good enough, Chris.
You mention commonalities in your comments only. They're not expressed in
the desing at all. It is pretty normal that a list can be expanded or be of
a fixed size. It is also possible that a list can change behaviour with
time - become readonly for instance. On the other hand I don't think that
its pretty commong for a cereal boxer to bite ears off on the ring, or for
a doggy to end up yawning at an assembly line.
Well, here is an extreme of "correct" design that you guys will probably
like:
public interface IAthleticBoxer
{
void RightPunch();
}
public interface ICoolAthleticBo xer : IAthleticBoxer
{
void LeftJab();
}
public interface IMTysonKindOfBo xer : ICoolAthleticBo xer
{
void BiteEar();
}
Do you think there's something wrong with it (a hint - there is)?
Val.
"Chris Capel" <ch***@nowhere. com> wrote in message
news:%2******** **********@TK2M SFTNGP10.phx.gb l... From what you're saying, Val, I don't see how you could criticize an interface like this one:
public interface IBoxer { bool IsCerealBoxer {get;} bool IsAthleticBoxer {get;} bool IsCanineBoxer {get;}
void FillCerealInBox (); void MoveAssemblyLin e(); void Yawn();
void RightPunch(); void LeftJab(); void BiteEar();
void Bark(); void PlayDead(); void Shake(); }
My point is that things that are different should be in different interfaces. Read only arrays and variable size arrays have many things in common. So do cereal boxers with athletic boxers. (Both are human, both
have jobs, etc.) But they don't have enough in common to warrant putting them
in the same interface.
I'm with ya, emma.
Chris
"Val Savvateev" <ov*********@me ridium.com_NO_S PAM> wrote in message news:#u******** ******@TK2MSFTN GP09.phx.gbl... "emma middlebrook" <em************ **@fastmail.fm> wrote in message news:e2******** *************** ***@posting.goo gle.com... "Val Savvateev" <vs********@mer idium.com_NO_SP AM> wrote in message news:<uM******* *******@TK2MSFT NGP10.phx.gbl>. .. > You should've started with the 4th item because an answer to it
would kind > of eliminate #1. The fact that they made one interface instead of two - I'd > say it's just a matter of taste. I kind of like having one, - less hassle > when you need to find out if the collection is readonly - no need to query > another interface. Besides, IList has a good description, as documentation > states - "Represents a collection of objects that can be
individually > accessed by index.". I think the design does not contradict the description. I don't believe it's a matter of taste - an interface has an implicit contract. You can't argue that because the documentation says it can be used to access by index then it's OK. IList has semantics suitable for data structures whose size can vary.
Not quite correct... Let's put it this way - IList sematics show that it can be applied to structures of variable _or_ fixed size (depending on the value of IsFixedSize property). The structures could also be readonly (you can or cannot update particular elements based on the value of IsReadOnly property). I think you underestimate the presense of the mentioned properties. Also, isn't it logical after all that if you can update particular elements using an interface then you also should be able to add/remove the elements through the same interface....
If this interface was aimed at fixed size
It was not. That's the point.
data structures then it's clearly wrong because fixed size data structures cannot be expected to implement some of its members e.g. Add/Remove!!
See value of IsFixedSize. I dont see any problem with that.
So, anyway, the IList itself is fine. It's just not appropriate to derive an Array from it.
Hmm... "just not apporpriate" is not quite an argument... Why not appropriate?
Some of the functionality you say you like should be factored out as it's orthogonal functionality to a list and maybe common to all data structures. Then there'd be nothing wrong with Array and other collections deriving from that new interface.
Well... I see your point, and it would be valid if the interface was missing the two properties. I still think it was just matter of taste and let me illustrate why. If the design was your way it would contain two
interfaces (or more) instead of single IList, something like this (pseudo-code):
IList { obect Item(index) {set;get;} int IdexOf(item) bool Contains(item) bool IsReadOnly }
IListManager { Add() Insert() Remove() Clear() ....etc }
Now imagine, I'm implementing my own datagrid. The grid should be
editable and allow for deleting and adding items based on whether the list is fixedsize. My initialization code for both designes would be different... but just alittle........
In case of the proposed design: Init(object source) { IList _items = source as IList; IListManage _manager = source as IListManager; bool _isFixedSize = (_manager != null); }
In case of the current design I would not need to query for the manager interface and I would just use properties on IList:
Init(object source) { IList _items = source as IList; }
Datagrid would also be a good argument for having everything in one interface - when you see list of items on the screen it's either
editable or not (IsReadOnly) and you either can add/remove items or not (IsFixedSize).. ... "Manageabil ity" of the list does not disprove the
fact that it's just a list....
> I don't quite understand what's that confusing about #2? The fact
that Array > is implementing IList is just a matter of followind the pattern -
all > collection classes in .NET implement either/some/all of these: IEnumerable, > ICollection, IList. And some pieces of functionality are based on
using the > interfaces. For instance you can bind Array or ArrayList to a grid because > they both expose IList...
I'm not confused, it just seems wrong. What is your pattern - you just say some collections implement some interfaces?
Yep.... Ultimately all the collections in the library implement IEnumerable (ICollection iherits IEnumerable, IList iherits ICollection) :
http://msdn.microsoft.com/library/en...collectionsien umerableclassto pic.asp?frame=t rue Binding ... would explain a little further for my own education how this works and the importance of IList in this - that would be appreciated as I don't know much about binding.
http://msdn.microsoft.com/library/en...windowsformsda tagridclassdata sourcetopic.asp ?frame=true IList is the simplest structure that can be used in binding...
> As far as #3 goes - well contains the answer, doesn't it? The docs say: > "Implementation s of this method can vary in how they handle the > ICollection.Cou nt and the capacity of a collection. Typically, the count is > set to zero. The capacity can be set to zero or a default value, or
it can > remain unchanged." Hmmm.... In this particular implementation,
calling Clear > doesn't change Count.... but that's documented, right? :)
Yes, I know but I still think that's bad, documented or not!
Well, you see, I told ya! - just a matter of taste ("i know, but...")
.... :) List the discussion....
Val
Cheers for your comments and discussion - I'm just saying really that the IList interface should be factored out so Array can derive from nicely defined interfaces each of which asks it to implement methods that it can actually do!
Emma Middlebrook em************* *@fastmail.fm
> Sincerely, > Val. > > "emma middlebrook" <em************ **@fastmail.fm> wrote in message > news:e2******** *************** ***@posting.goo gle.com... > > Hi > > > > Straight to the point - I don't understand why System.Array
derives > > from IList (given the methods/properties actually on IList). > > > > When designing an interface you specify a contract. Deriving from
an > > interface and only implementing some of it means something is
wrong: > > either the interface specification is wrong e.g. not minimal or
the > > derivation is wrong e.g. the type can't actually honour this
contract. > > > > Firstly, an array is fixed size so it doesn't make sense for it to > > implement Add/Remove methods anyway (these appear on IList). So, they > > throw exceptions but I don't think that Array should even need to
be > > implementing these in the first place! > > > > Secondly, for an array, what does IList provide that System.Array > > would not have otherwise? *Nothing* as far as I can see. So what's it > > there for? > > > > Thirdly, I think the actual current implementation is half-baked > > anyway. For instance, get an IList from an Array with some objects and > > call Clear. Then call Count. Then notice that Count isn't 0 - it > > hasn't been synched by Clear. I realise that the specification of > > Clear doesn't require this (see the docs) but still, you'd expect
it > > here. > > > > Fourthly, I think the IList property IsFixedSize is strange. If a data > > structure is fixed size it shouldn't have to implement Add/Remove > > methods because it doesn't make sense. So there should be two separate > > interfaces for fixed size data structures and for variable size
data > > structures. > > > > These are just my ideas using really basic design guidelines. I'm > > probably missing something or not seeing the full picture so some help > > in this direction would be useful! > > > > Thanks > > > > Emma Middlebrook > > em************* *@fastmail.fm
yes, you're right. the current .NET collection structure is very stupid.
much better would be following structure:
interface IReadOnlyList
{
Prev();
Next();
Count();
}
interface IReadOnlyArray : IReadOnlyList
{
GetAt(); // indexer
}
interface IArray : IReadOnlyArray
{
SetAt(); // indexer
}
interface IList : IReadOnlyList
{
Add();
Remove();
Insert();
Clear();
}
interface IArrayList : IArray, IList
{
}
this is imho the perfect solution. there is an interface for every need
and it is still kept simple. and dont't understand why microsoft solved
it in such a stupid manner.
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it! This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
by: tsteinke |
last post by:
I noticed somthing. The native Array Types implement the IList
interface. However they do not contain all the methods in the
interfaces they implement. for example...
int test=new int;
test.Add(5); <<<< This is a Compile Error
However
if(test is IList)
|
by: Chris |
last post by:
Hi,
the specs for System.Array are :
public abstract class Array : ICloneable, IList, ICollection,
IEnumerable
but I can't use any of the functions presented by IList in my code
System.Array numbers = new int{1,2,5,6,7};
numbers.Add(1) --> NOT POSSIBLE Compiler error : 'System.Array' does
|
by: Jim Shaffer |
last post by:
Perhaps I have the wrong construct, or misunderstand arrays in vb (2003)....
I've loaded a two-dimensional array (168 by 28) into memory as AcctArray.
{Dim AcctArray (500,28) as string...}
The AcctArray is loaded from a Quickbooks table, so there's no intrinsic
dataset to assign as datasource....
I want to have a combo table (or list table or whatever), currently named
cbAccounts, that can scroll through and maybe select items in the...
|
by: Marcus |
last post by:
I have a couple of classes looking like this:
========================================
public class AdminSettingsData
{
public string adminSettingsPath;
public string adminSettingsFile;
public string usersSettingsPath;
|
by: Arthur Dent |
last post by:
How do you sort a generic collection derived from
System.Collections.ObjectModel.Collection?
Thanks in advance,
- Arthur Dent
| |
by: Jim Lewis |
last post by:
I'm trying to move a function into pyrex for speed. The python side
needs to pass a list to the pyrex function. Do I need to convert to
array or something so pyrex can generate tight code? I'm not clear how
to do this.
|
by: KK |
last post by:
Dear All
I have a small problem with using as operator on value type array.
Here is an example what I am trying to do.
using System;
using System.Collections.Generic;
using System.Text;
|
by: Tony Johansson |
last post by:
Hello!
The Array class implements these interfaces IClonable, IList, ICollection
and IEnumerable.
Note only interfaces are inherited and no classes so these interfaces will
be implemented in the derived class.
In Interface IList have a couple of members that is not available from the
Array object.
For example if I do the following
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
| |
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |