Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Implicit Conversion from SortClause to SortExpression
 

Pages: 1
LLBLGen Pro Runtime Framework
Implicit Conversion from SortClause to SortExpression
Page:1/1 

  Print all messages in this thread  
Poster Message
simmotech
User



Location:

Joined on:
01-Feb-2006 15:43:00
Posted:
1006 posts
# Posted on: 21-Feb-2018 11:11:45.  
Is there any reason this cannot be implemented?
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37476 posts
# 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
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
simmotech
User



Location:

Joined on:
01-Feb-2006 15:43:00
Posted:
1006 posts
# 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:
Code:
var sortExpression = new SortExpression(ResourceItemStatusFields.DueDate | SortOperator.Ascending);


I prefer this:
Code:
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. Tongue)

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).

  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37476 posts
# 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 Regular Smiley 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
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
simmotech
User



Location:

Joined on:
01-Feb-2006 15:43:00
Posted:
1006 posts
# 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.

Code:

// 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.
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37476 posts
# 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 Regular Smiley


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.