Help with function name

I created a module of Text functions, M_Text, similar to the module I had created for String. I will soon release it publicly and it includes such conveniences as Repeat, Squeeze, Expand, ReplaceLineEndings, and more.

I also included functions that recreate the classic framework behavior of Left, Right, and Mid. I called these LeftAtMost, RightAtMost, and MidAtMost since they will return the requested number of characters if they can, or something less otherwise. For example, if dim t as text = "123", t.Left( 4 ) will raise an exception while t.LeftAtMost( 4 ) will return “123”.

Except I don’t love the names. I want something descriptive, not something like LeftLikeClassic, and I’d love to get suggestions.

What about…

t.LeftMax(4)
t.RightMax(4)

That’s not bad. If you started typing t.L… and saw an autocomplete list that included “Left, LeftMax_MTC” (I used the _MTC extension for all my global methods to avoid conflicts), would you immediately understand, or at least remember, the difference?

I think the purpose of the method might not be obvious before first use (like any new method I suppose), but after using it a couple of times it would definitely be easy to remember the difference IMO.

Why don’t you have the same method name with the extension _MTC?

Just FYI
We actually deliberately didn’t make Left right etc work like this as it can cause silent & hard to find bugs.
Suppose you write code that is like

dim s as string = t.left(4)

and then use s not realizing that its an empty string

In fact a lot of the new framework has been designed to make errors or bad assumptions, like this, much more obvious & things you have to deliberately handle or deal with instead of hiding them away like Left etc used to

Understood, and no objection to the change-of-course. It’s just that there are often times where I won’t know how many characters are in a string, and don’t care either. These functions will fill that need.

The extension is only meant to avoid conflicts and, mentally, you should strip it away. That would leave you with two functions called Left.

Oh I get that it can make it easy to port code but the number of bug reports that suffer from this sort of self induced problem is way more than 0. They do a left of a string and get something less than however many characters them assume they got that many.

IMHO code that can deal with 4 or less maybe should have code right there to make it obvious when you come back to read it in 6 months
Something like
dim s as text = t.left( min( t.Length, 4) )
makes it VERY clear that this can deal with up to 4 characters
That way the criteria of “I CAN work properly with 4 or less” is right there not hidden away elsewhere

My two cents would have been to name your new method “AtMostNLeftCharacters” :stuck_out_tongue:
Something to help remind the reader down the road.

I agree with the sentiment, but not the suggestion. :slight_smile:

Your entitled to your opinion. Regardless of how wrong it is :stuck_out_tongue:

That is most often the case for me when using Left. I have to say the behavior of Left in the classic framework has NEVER caused a bug for me and was usually whatI wanted… For myself it looks like the new framework just makes more work in a lot of cases…

This reminds me of the Val discussion in that the Old framework behavior, while not strict, works fine for most cases and is convenient for most real world uses. New framework seems to equal more drudgery more than anything else!

-Karen ( Who is admittedly lazy! :wink: (

PS as for name: LeftMaxText(Extends theString as Text,Chars as Integer) As Text

How about -
GiveMeAtLeastThisManyCharactersButDontBeADickIfThereArentEnough ?

I’ll be honest, I’m aware of two problems with my suggestion :

  1. I’m in a REALLY bad mood, and
  2. I’ve not bothered to read the post trail well enough to know if that is indeed the action of the proposed function.

Feel free to make me aware of more …

Ok, that made me laugh.

Karen, the function will only show up for Text, so the trailing “Text” would be redundant. I’ll take that as a second vote for LeftMax.

Should be
GiveMeNoMoreThanThisManyCharactersButDontBeADickIfThereArentEnoughAndHideAssumptionsWhenThereArent

I just like code that has assumptions like this stated right there in plain sight
You might write a lot of error checking code following the current use of left to make sure you got at least 3 characters or if you got fewer its something you can handle
That’s OK too

Lots of people don’t and get bit

I would call it LeftMaxChar

+1 LeftMax. Short and sweet. (Left would be even better :slight_smile: )

I must admit I’m not a big fan of the nanny-state new framework.

The new framework is just pushing the assumptions that were implicit in things like Left, Right, etc out in a way someone, not you, could plausibly read your code in the future & not have to consult the LR on every method call to the framework to see what it may or may not do and how it might silently fail to do what you expected (like return < 3 characters when you ask for 3)

When I started here it took me forever to get up to speed because assumptions were hidden in code and in calls to the framework and the use of Variants (evil evil evil) and the magic they’d do. It made tracking down bugs VERY time consuming.
Anyone hate that VCP files would flip flop values from string to integer etc ? VARIANTS ! :stuck_out_tongue:
I’ve been hunting those causes for nearly 7 years.

So, and this IS only my personal opinion, things like the old LEFT, or Kems new replacement, that can silently fail to return what I asked for should be loud & obnoxious when they do. This way my code can, in code, put the assumptions I’m making about how to deal with such a situation right there where it matters and where I need to worry about it.

Now IF YOU ALREADY test for getting less than what you asked for then you’re already doing exactly what I wrote should be done just using if then or select case instead of an exception.
You wrote your code in a way that the assumptions ARE present right where the data is being munged about.

ie/ IF you’ve already done this

    dim t as text = s.Left(3)
    if t.Length() <> 3 then
       // some error handling code
    end if

its not fundamentally different than

    try
       dim t as text = s.Left(3)
    catch
       // some error handling code
    end try

you have error handling either way (and in the case of the exception you don’t always evaluate the IF thereby gaining tiny speed ups all over the place)

In the case you DONT care the new framework simply makes you make it VERY explicit you dont care by writing

    try
       dim t as text = s.Left(3)
    end try

But at least IF you do write this when you have a bug and come back to it later instead of wondering if

       dim t as text = s.Left(3)

is just a dumb mistake on your part and you forgot to handle the exception or a real but
If you see that you wrote

    try
       dim t as text = s.Left(3)
    end try

you can see that NO you DID in fact realize that there could be cases where you got less than you asked for and that you thought about it at the time (albeit maybe incorrectly)

I like being able to write more correct code initially & being forced to state my assumptions right there.
In order to do that today I end up often writing at least the same amount of code as with the new framework.

YMMV

In the interests of rambling and potential nonsense, how about a multi-faceted return value? I’m a bit drunk now so words might not be my friends :

myRetVar=IndeterminateLeftFunc(myStr,4)

would return

myRetVar.Value

and

myRetVar.Caveats

or something like that. So you would have your 3 chars (for example) plus something telling you that there weren’t 4 chars to be had. Could provide a consistent way to report on unexpected results that are not entirely incorrect given the mood of the people rather than strict computational rationale but not completely what might have been expected. You can then choose to ignore it at your will.

Not sure that helps any as it’s all just sugar coated laziness :slight_smile: