Good shout on using String.split_at/2 on the implementation, Zach. It is
one of the concerns I raised in the original PR and your solution is quite
elegant.

Which also brings another point: if the implementation is 6 LOC (I believe
the first two clauses are not strictly necessary), then there is even less
reason to add it to Elixir.

On Sun, Nov 20, 2022 at 5:43 AM Zach Daniel <zachary.s.dan...@gmail.com>
wrote:

> It would be great to come up with some kind of heuristic and/or consistent
> philosophy on what belongs in the standard library, to guide these
> discussions. Some kind of rubric could make these kinds of conversations
> easier or even prevent them entirely. For me, the main guiding principles
> are whether or not there is exactly one right way to do the thing in
> question, how ubiquitous the need for it is, and how obvious the
> implementation is (on the flipside, how much we can prevent people from
> hidden gotchas they wouldn't even think to reach for a library for).
>
> For example, the implementation actually requires only adding padding if
> the string has been trimmed at all, and I'd bet there are lots of
> suboptimal implementations out there. Ben's above isn't quite right, since
> the idea is to only add the ellipses if it truncated the string, and then
> it should only add exactly the string provided (not pad it out to the full
> length of the string).  Since a performant implementation probably might
> not be quite as obvious to the less experienced (with elixir or in
> general), and this seems like a relatively common operation (for rendering
> strings in UIs or emails or w/e), I feel like a std library implementation
> could be warranted.
>
> Something like this would probably be better since it avoids checking the
> string length (a linear time operation) and also avoids things like
> multiple slice operations in favor of a single traversal up to "length".
>
> ```
> def truncate("", 0, _), do: ""
> def truncate(_, 0, padding), do: padding
>
> def truncate(string, length, padding) when length > 0 do
>   case String.split_at(string, length) do
>     {leading, ""} -> leading
>     {leading, _} -> leading <> padding
>   end
> end
> ```
>
>
>
> On Sat, Nov 19 2022 at 9:45 PM, Ben Wilson <benwilson...@gmail.com>
> wrote:
>
>> This seems reasonably straight forward to implement in your own code base:
>>
>> ```
>> def truncate(string, length, padding \\ ".") do
>>   string
>>   |> String.slice(0, length)
>>   |> String.pad_trailing(String.length(string), padding)
>> end
>> ```
>>
>> Not seeing a strong need to include it in the standard library. Just my
>> $0.02
>> On Saturday, November 19, 2022 at 2:12:19 PM UTC-5 Kip wrote:
>>
>>> That is comes from Laravel, not PHP core may be an indication it is
>>> better implemented in a library?  If there is momentum towards adding it to
>>> the String module I think `String.truncate` would feel more natural to me
>>> (its also what Ruby uses).
>>>
>>> Its difficult to make guarantees about the printable width though since
>>> characters like ZWJ and Bidi text would mean that to do this properly is
>>> not a simple or straight forward situation.  For that reason I don't
>>> personally think it belongs in Elixir itself.
>>>
>>> On Saturday, November 19, 2022 at 5:20:21 PM UTC+1 hassanr...@gmail.com
>>> wrote:
>>>
>>>> Hi all,
>>>> I came across from laravel <https://laravel.com> framework, where
>>>> there are a lot of useful functions, I miss those functions in Elixir, One
>>>> of the functions is called limit
>>>> <https://laravel.com/docs/9.x/helpers#method-str-limit> function, I
>>>> would like to have that in elixir.
>>>> ```
>>>> iex> String.limit("elixir", 3)
>>>> "eli..."
>>>>
>>>> iex> String.limit("elixir", 7)
>>>> "elixir"
>>>>
>>>> iex> String.limit("elixir", 3, "***")
>>>> "eli***"
>>>> ```
>>>> This function would be really helpful with longer string, we can limit
>>>> long string with some trailing string like (...).
>>>>
>>>> What do you think? If yes what should be the name you suggest?
>>>>
>>>> Thanks,
>>>> Hassan
>>>>
>>>>
>>>>
>>>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elixir-lang-core+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/35628c34-c8c4-4558-a985-de87ec7111d3n%40googlegroups.com
>> <https://groups.google.com/d/msgid/elixir-lang-core/35628c34-c8c4-4558-a985-de87ec7111d3n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/laoukpzy.f4712342-a7c6-40db-bf00-87e6b393bcd1%40we.are.superhuman.com
> <https://groups.google.com/d/msgid/elixir-lang-core/laoukpzy.f4712342-a7c6-40db-bf00-87e6b393bcd1%40we.are.superhuman.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JdT9gQpyjKVXQKg1Rv63BPht1UT59a3QTF4K4Uz8RNOA%40mail.gmail.com.

Reply via email to