TeamDesk Knowledge Base & Support

   Home      FAQ      Forum      Idea Exchange      Ask a Question      My Stuff      Help   
  
[Not]Left/Right breaking change
At the moment, variations of Left/NotLeft/Right/NotRight functions that take a string as a second parameter interpret the string as a **list of characters** to search for. In other words, Left("ABC", "CB") will return "A" because second argument is interpreted as "to search for either C or B".

Yet, there are situations where you need to strip the text to the left/right of **substring** and such functions are missing in TeamDesk.

While we could add, say Before/NotBefore/After/NotAfter family of functions that will interpret second argument as substring to search for, this would lead to bloating the functions runtime. Or we can simply change an intepretation of the second parameter for existing Left/NotLeft/Right/NotRight functions but this will lead to a breaking change.

We've done a quick analysis of formulas currently in use and found out that vast majority of Left() family calls search for a single character - these calls won't be affected by a change. In few remaining cases it seems the administrator though that second parameter should be interpreted as substring. From all applications we've checked we've found the only call where second parameter specifies **the list of characters** but this call can be easily replaced with Part() function.

So, what do you think? Are you using Left and family with the list of characters? If you don't remember you can search for "Left(" and "Right(" using the box located in a side bar of the setup section
ID
492
Category
Setup
Author

Kirill Bondar  Staff 
Date Created
2/23/2012 4:40:50 AM
Date Updated
3/23/2012 8:04:16 AM
Status
Implemented
Score
40
Promoted By
Rick CogleyLiquid RapidFrédérik_Dussault
Kirill Bondar  Staff 
Comments
gerardo garcia 2/23/2012 8:24:25 AM
Hello Kirill. I´m ok with the change, stripping for substring sounds more useful.

I have searched for the use of Left/Right in my application and seems I am using it to search for a single character in all cases and not a list of characters. To be honest I havent realized that I could use it that way. But I feel safe that if needed I could use the Part() function or some workaround.
Frédérik_Dussault 2/23/2012 9:20:26 AM
It will have no impact on us as we do not actual use left/right
Arnold Hakobyan 2/23/2012 11:57:55 PM
As the change is announced on time, it won't cause any problem I guess. Surely no problem with me at least.
Philipp Matuschka (MMB) 2/24/2012 3:15:07 PM
I am pretty sure that this will not cause me any problems. I don't really use string functions much
Liquid Rapid 2/27/2012 2:54:01 AM
I like it. I use these functions in many places in many different apps, and not one of them uses the list-of-characters option. I just did a search to confirm that.

In fact, I've wanted to use the second parameter as a substring in the past, and had to find other ways to do it. Having that functionality built in would be useful for me.

My vote is yes to the change.
Rick Cogley 2/27/2012 3:06:27 AM
Yes, this will help us.
Denis Barry-Smith 2/28/2012 7:10:25 AM
I think you are creating a set of functions which are in conflict with the commonly accepted way of interpreting the left function in other programming languages. In other programming languages the left function returns the leftmost substring after splitting the string at the desired position. Similarly for the right function which returns the rightmost substring following the split location. Currently you conform to this interpretation, after the change you will not and this would be another source of confusion for people like me who program in other languages. I suggest you add another set of functions to add this functionality, similar to the TRIM function found in TSQL and other languages, and maintain as much commonality as possible in ways of interpreting your functions compared to other programming languages.
Kirill Bondar  Staff  2/28/2012 7:23:28 AM
@Denis: for each functions in the family we have two versions that differ by the second argument: it can be either a number specifying the position to split - that's how most programming languages define string operations; or a string. We are not going to touch the functionality of positional versions. Here we are speaking about the change in the interpretation of second argument specified as a string.
Denis Barry-Smith 2/28/2012 7:29:32 AM
Could this be more confusing or am I seeing it wrong?
left("Happyness", 6) = "Happy"
left("Happyness", 'n') = "ness"
Kirill Bondar  Staff  2/28/2012 7:38:48 AM
At the moment Left("Happyness", "n") = "Happy".

Please note that at the moment we are interpreting second argument as a **list** of characters - we are returning the string to the left of any character found in a second argument.

E.g. Left("abcbd", "cb") is "a".

We are going to change the interpretation of the second string from character list to a substring to search for to let previous example to return "ab".

If you Left() calls specify a single character like majority of existing calls do, there would be no difference in behavior.
Denis Barry-Smith 2/28/2012 7:44:05 AM
Ok Thats a bit clearer Thanks
Kirill Bondar  Staff  3/23/2012 8:04:16 AM
While examining existing formulas for [Not]Left/Right calls I found quite common pattern:

Right([Column], Len([Column]) - 1)

to get all the characters except the first one, mainly in the context of capitalizing first letter. Instead of Right() you can use NotLeft([Column], 1) that will do exactly the same, but this way you can get rid of Len() call.

Generally, if N does not exceed text length, the following is true:

[Column] = Left([Column], N) & NotLeft([Column], N)

Thus to capitalize first letter you can use

Upper(Left([Column], 1)) & Lower(NotLeft([Column], 1))
Feedback
 
Back to Search Results