The general rubric is outlined here:
https://elixir-lang.org/development.html
However we can give more leeway to functions compared to features.
On Sun, Nov 20, 2022 at 16:25 Zach Daniel <zachary.s.dan...@gmail.com>
wrote:
> This is the kind of thing I mean when I say having a rubric for std
> library candidacy would be useful. I think how many lines of code shouldn't
> really be the metric, but more some kind of subjective measure of how
> difficult it would be for someone else to provide the right implementation
> on the fly. Regardless of what the rubric looks like, I feel like it could
> guide lots of discussions on this mailing list.
>
>
> On Sun, Nov 20 2022 at 3:33 AM, José Valim <jose.va...@dashbit.co> wrote:
>
>> 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
>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JdT9gQpyjKVXQKg1Rv63BPht1UT59a3QTF4K4Uz8RNOA%40mail.gmail.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/lapicugp.dc81ce3d-24c7-4d9c-b67c-c56491a0be01%40we.are.superhuman.com
> <https://groups.google.com/d/msgid/elixir-lang-core/lapicugp.dc81ce3d-24c7-4d9c-b67c-c56491a0be01%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/CAGnRm4Kkxf3hS-uCWk6BKsrBcRkNvSd9U1Oq8uOnrbnt7nuFpQ%40mail.gmail.com.
