On Tue, 25 May 2010 10:01:48 -0400, Jacob Carlborg <d...@me.com> wrote:

On 2010-05-25 15.38, Steven Schveighoffer wrote:
On Tue, 25 May 2010 09:26:20 -0400, Jacob Carlborg <d...@me.com> wrote:

On 2010-05-24 21.08, Steven Schveighoffer wrote:

Don't user interface objects have data? If a UI component is an
interface, how does it expose access to its data? For example, a .NET
ListView control contains an Items property which you can use to access
the elements in the list view. The Items property returns a
ListViewItemCollection which implements IList, IContainer, and
IEnumerable. I've found these types of abstractions useful when
adding/iterating, etc.
-Steve


I would say that is a bad design, I would go with the MVC pattern. For
example, you have a ListView and when it's ready to display, say row
3, it calls your delegate and request you to return the item that
should be visible on row 3. Then it's up to you to store the items in
some appropriate data structure, like a list or array.

I don't know if a delegate is enough to implement the pattern. What you
need is a set of delegates that perform operations on the container. Oh
wait, that's an interface!

What I was trying to say is that a ListView should not contain a data structure. I try to explain that I want to say in code instead:

auto data = new Item[10];
auto listView = new ListView;
listView.numberOfRows = size_t delegate (ListView lv) {
    return data.length;
}
listView.itemAtRow = Item delegate (ListView lv, size_t row) {
     return data[row];
}

Yes, I get that. What I'm saying is this is basically an interface. The difference is that the interface is not required to be declared on the container class, and requires 2 words of storage in the ListView per function instead of 1 word for all the functions.

Another way to do this is:

listView.items = data;

Where listView.items is an interface that contains the functions you need. If the set of functions is complex, then using the delegates could be tedious.

It's just a different way of doing it. There are benefits to both ways. Using the delegates is more flexible because a delegate does not need to be defined in a class with a predefined interface being implemented. It's also much easier to build a bunch of delegates on the fly rather than build an interface implementation.

-Steve

Reply via email to