ā Generic function with conditional type based logic inside
How can I make something like this work? I want the user to either be able to get a list of ints or strings.
17 Replies
I want to avoid boxing as well
And I don't want to duplicate the logic
I don't know why it thinks it needs to implicitly convert. The types will match up because I checked them before
First of all a generic method should work for all types it accepts.
If a method cannot act on all possible values for T (on a conceptual level), you need to restrict the generic down to a point where that is possible.
But what are you exactly trying to accomplish with this method, what is your goal?
I want to avoid having to write two functions that are 90% identical @Joschi
yes, I agree. this feels wrong.
What you could do to make this work is to force the user to provide a function that can convert your
int i
to T
.
So your signature could be something like List<T> Foo<T>(Func<int, T> func)
.
Now you could use IEnumerable<T>
instead of list and convert this to a generator with yield return
.
Then you may realise that you reinvented Enumerable.Range(0, 10).Select(x => x.ToString())
.I like your first two points, I will try to do something like that. For the third, this example is just something small that I could post on discord without including a bunch of extra crap.
I suspected as much. But I always think it's a bit funny, that code often suddenly evolves into LINQ, as soon as loops and returning Enumerables of any kind are involved.
I will post my actual version when I get it done
Feel free to ping me
will do, thanks
@Joschi
Looks good. Would you give me an example of what
fileToHash
would do?HashSet<string> allHashesString = FileUtils.GetFileHashesDirectory(dirA, FileUtils.GetFileHashString);
Here is the call
Here is the rest of the classOk interesting. Why don't you just settle on a format for you hashes, like always use
byte[]
or string
?I don't know what I want yet
I did some benchmarking to see if there was a big difference but there isn't enough of one to warrant using byte[] over string
Interestingly you could also express your method in pure LINQ
Directory.EnimeratFiles(directory).Select(x => new FileInfo(x)).Select(hashingFunc).ToHashSet()
would be equivalent.
š
Anyways if you use that often having a dedicated function is a good thing.
But if you don't know what you actually want yet, I would suggest that you move on from trying to make the "best convenience function you can" to other more critical parts of your application.
And then you may realise, what actually fits your use case the best.I agree with all your points except that this is also a learning experience. If I didn't try to do it this backwards way I would not have seen the
Func<>
way of doing it that is much simpler than what i had in mind
I am going to benchmark the non-linq and linq version and see if there is a noticable differenceMemory consumption would be interesting in that benchmark, because you create a fixed size
HashSet
but there will be cases in which you will have less elements than your size. Because if that is not an expected scenario, there would be no need to use a HashSet
.It will be a minutes because I have to figure out this git/hub thing first
@Joschi
This is in a directory with ~140 image files
most time is probably spent on computing the hash
thanks for your help @Joschi