Implicit Conversion from SortClause to SortExpression

Posts   
 
    
simmotech
User
Posts: 1024
Joined: 01-Feb-2006
# Posted on: 21-Feb-2018 11:11:45   

Is there any reason this cannot be implemented?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39589
Joined: 17-Aug-2003
# Posted on: 21-Feb-2018 11:20:46   

They're not the same, so why would it be implemented? (SortExpression contains 1 or more SortClauses) But a little bit of context might be necessary when /where you need this wink

Frans Bouma | Lead developer LLBLGen Pro
simmotech
User
Posts: 1024
Joined: 01-Feb-2006
# Posted on: 26-Feb-2018 18:28:13   

My sorting queries use a single SortClause 99% of the time, therefore I have always found it a pain to have to wrap it in something else so it can be used in a Fetch.

I like compact code, so instead of writing:

var sortExpression = new SortExpression(ResourceItemStatusFields.DueDate | SortOperator.Ascending);

I prefer this:

var sort = ResourceItemStatusFields.DueDate | SortOperator.Ascending;

But there are no overloads in Adapter.FetchXXX() which accept SortClauses. (and adding more permutations to Adapter is something neither of us want I bet. stuck_out_tongue_winking_eye )

Adding an implicit conversion means being able to use my SortClauses directly without needing additional overloads.

Remember that <sortClause> & <sortClause> already combine to a SortExpression so you must have thought that hiding "new SortExpression(..." must have been a good thing.

Actually, the same with FilterBucket too. If no relations are required then let me just pass a Predicate instead and have it implicitly converted to a FilterBucket (via PredicateExpression if necessary).

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39589
Joined: 17-Aug-2003
# Posted on: 27-Feb-2018 11:15:53   

Adding implicit conversions here isn't going to work, as it doesn't make any sense to do so: the types are not equivalent. E.g. an int and a short, you could argue they're the same when you have a number that fits in a short. But a sortclause and a sort expression, you can't argue they're the same thing, sorry.

However it matters of course where you use the sortclauses simple_smile In queryspec for instance, the OrderBy() method accepts sortclauses, so you don't need a sortexpression, you can just pass the sortclause created by the operator or Ascending()/Descending() queryspec extension methods.

I agree, wrapping a predicate in a relationpredicatebucket or a sortclause in a sortexpression is kind of verbose, though it's the low-level API, and in general one should use one of the other APIs like queryspec to formulate the query. Adding more overloads indeed won't be an option wink

What you could do is defining 2 extension methods, SortAscending() and SortDescending() which work on an IEntityField2/IEntityFieldCore and create a sortclause and return a SortExpression with that sortclause. Not ideal, but the implicit conversions won't be added, so that's what could help you (or use queryspec queries wink )

Frans Bouma | Lead developer LLBLGen Pro
simmotech
User
Posts: 1024
Joined: 01-Feb-2006
# Posted on: 27-Feb-2018 15:39:16   

I know they are not equivalent and not the same thing. But that is not what an implicit conversion is about.

An implicit conversion is allowed between any two types as long as the conversion is guaranteed not to cause a loss of data. This is a perfect and simple example of that.


// On SortExpression class
public static implicit operator SortExpression(SortClause sortClause)
{
    return new SortExpression(sortClause)
}

Now anywhere a SortExpression is expected, you can use a SortClause.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39589
Joined: 17-Aug-2003
# Posted on: 27-Feb-2018 17:27:57   

I know what an implicit conversion means/is, the main issue I have with this particular case is that they're not similar, so an implicit conversion really doesn't make any sense (to me at least). What could be done is an extension method perhaps sortClause.ToExpression(), but that is almost the same amount of typing as new SortExpression()...

Implicit conversions to me are only valid if there's a conversion to be expected and you otherwise need a cast but can leave it to the implicit conversion, e.g. the value '10' can be an int or a short. Converting x into y just because it's convenient doesn't make it a valid use case for an implicit conversion IMHO, as it's hidden, and doesn't make any sense (to me) that it is there.

So, I get your point and I agree it's verbose and should have been differently (and I have cursed a LOT about e.g. requiring new RelationPredicateBucket(predicate) instead of the damn predicate, but the API is there I can't change it anymore... wink ), but I'm not going to add it, sorry simple_smile

Frans Bouma | Lead developer LLBLGen Pro