Generic Lists & the System.Predicate Delegate.
I may be missing something here, however I am baffled at the signature of the predicate delegate as defined for the Find methods of the generic List in 2.0.
Could somebody please enlighten me as to the lack of an additional parameter with which to pass in search criteria? I would have at least expected this to be overloaded with the option for something like the following:
System.Predicate(Of T)(obj As T, match As Object) As Boolean
This would make more sense to me. For my own purposes I have felt the need to pre-load any search criteria for my List searches into a higher-scope variable prior to hitting Find with the restrictive signature.
Thanks in advance for helping to clear this up for me.
Regards,
David Kennedy
[737 byte] By [
Satch78] at [2008-2-15]
I must say I am surprised at the lack of response when I see posts such as 'Creating a New OS' (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=870853&SiteID=1) which actually receive replies.
Come on people! Where are the real developers?
Perhaps if I express my dilemma in terms of C# it may elicit are more prompt reply. Here we go again people!
public delegate bool Predicate<T>(T obj)I think would make more sense with a signature such as:public delegate bool Predicate<T>(T obj, object match)Any comments as to why the framework team have defined it the way they have would be nice.Thanks again.
David
Satch78,
I cannot say I have a complete answer for you because I agree that the lack of an additional parameter does present a bit of an obstacle to flexible usage. I will however give you an answer to how I used the predicate.
The scenario is I have a generic collection of objects. I used two properties from the object to populate a drop down list. The text value was a human readable description, and the value was a special code. There are addtional values associated with the object, that at the point a selection is made from the drop down list I need to save to the database. So I used the .find() method and point my predicate at the following code:
Private Function findDivisionCode(ByVal object As BusinessObject) As Boolean
Return object.Code = dropdownList.SelectedValue
End FunctionThe end result is that I am able to very easily return the correct object dynamically based on the value passed in from my drop down list. I hope this helps you in some way. It could be that you are looking for an answer to why the .net team developed predicates to take only a single parameter, which as I said I have no idea why.
Thanks for the reply Justin,
Yes, you have identified my query regarding the .NET framework teams definition of this signature. You have adopted a similar usage of the new predicate to my own; the need to compare against a higher-scope variable, in your case the DropDownList control on your form. At least I doubt I am going crazy as I initially thought I must have missed some critical understanding of .NET generics, however it seems this is merely an oversight.
The only rational explanation for the restrictive signature I can comprehend is that of performance - clearly despite the inherent 'messiness' of macroscopic variables - it IS going to be more efficient to compare against the one object reference, as opposed to passing a 'copy' (ByVal) for each invocation of the predicate. This is a performance consideration that I believe should be left to the developer, as there are many cases when a light-weight list is employed & performance is not a critical factor.
Thanks again for the response, at least I seem to be on the right track with my understanding!
David
Aside from the obvious...
The definition of a predicate, even as applied within computer science, is the essence of 'something that is true of something'. By this formal definition, it precludes the use of a second parameter for search criteria, as this would function logically as 'something that is true of something in relation to something else', or 'something that is true of two things'.
This logic is encapsulated in the Boolean nature of the Predicate and I believe this could explain the teams' decision. I'd still like a final word from someone closer to the team as I am quite the curious type.
Despite this adherence to the logic of predicates, I find this restriction to be quite an annoyance at times.
Regards,
(DotNet) David
Try an anonymous delegate. Looks wacky, messes with the head when you ponder scope, and achieves what you want. (Disclaimer: I obviously made up this simplified code based on the working code up in my compiler right now. This communicates the basics of the approach and the syntax but may have a minor typo somewhere)
class Parent {
class Thingie {
public String name;
public String stuff;
}
private List<Thingie> myThings;
void SearchThings(String key)
{
Thingie found;
found = myThings.Find(delegate(Thingie thing) { return thing.name == key; });
if(null == found) {
// too bad...
} else {
// yay! got found.stuff
}
}
}
