Front page | perl.perl5.porters |
Postings from February 2022
Re: trim vs trimmed revisited
February 24, 2022 04:40
Re: trim vs trimmed revisited
Message ID: CANgJU+VkPi=6QU2xuoFAidjSTgOtBuCA_-Bf-Vcgc=4WKKq4aw@mail.gmail.com
On Thu, 24 Feb 2022 at 04:44, Karl Williamson <email@example.com>
> I believe using 'trimmed' is a mistake, and this email is a last ditch
> effort to make that case.
+1 (id plus +10 but that isn't allowed in normal voting :-)
> There is zero precedent in the core for using a past participle to name
> a function that takes an argument and returns some perturbation of it.
> We do not have 'reversed' nor 'sorted', nor 'crypted' nor 'hexed' nor
> 'packed' nor 'absd' 'orded' 'lcfirsted' ...
> We do, however, have in fact some functions in the core whose names are
> a past participle: 'defined', 'tied', and just outside of core:
> Scalar::Util::blessed. All these functions return a boolean, not at all
> like 'trimmed' would do.
> So 'trimmed' would actually be the sole member of a new class of names.
> I hear that there is some wish that 'sort' had originally been named
> 'sorted'. But it wasn't, and making a new name that corresponds to that
> forlorn hope but violates all existing precedents will only sow confusion.
Strongly strongly agree.
> When I was 13-ish, I learned in Math class that f(x) is pronounced 'f of
> x'. That didn't change in my education all the way through getting a
> Bachelor's degree in Math. Following along with that, I pronounce
> @x = sort(@y)
> as "Set x to the sort of y". I suppose one could pronounce it as "x
> becomes the sorted version of y", but that's really not following
> standard English usage.
> My assertion is that 'trimmed' violates precedents in core Perl and in
> standard usage.
> I wish that the few functions that change their operand in place, like
> chomp, instead left the argument unchanged, and returned the
> transmogrified result.
This is one of two minor points in your post I disagree with. I have no
problem with inplace modifications, and personally feel the 'oh my god that
is so bad" response to it in the builtin namespaces to be simply
hysterical. It is not something I am going to argue with folks about as
they seem far more enthusiastic about rejecting inplace modifications than
I am in favour of them, but I just wanted to put it on record that the
rejection of inplace behavior is not universally shared, nor universally
considered to be obvious. From a performance point of view, in place
modification is *much* prefered IMO.
IMO forcing all builtin functions to not do inplace modification is
basically trying to pretend Perl has immutable strings when it does not.
To paraphrase what you said above: I hear that there is some wish that Perl
had immutable strings. But it doesn't, and making new functions that
correspond to that forlorn hope violates all existing precedents and will
only sow confusion.
If we are using the fact that things aren't doing in place modifications to
justify breaking from what is essentially industry wide naming conventions
AND we are breaking our own precedents maybe we should just rethink the
policy that builtin:: does not do in place modification, and add inplace
modification support instead. For something like "trim" I cannot see why it
would be an issue *at all*. At my former workplace we had XS code to do
this and they all supported in place modification and the sky most
definitely did not fall on anyones head.
> But it's too late to change them; and they are
> outliers. Hence, using them as a justification for 'trimmed' is wrong.
And there maybe a better word than trim or its derivatives. 'trim' can
> mean both take away' and 'add' I sew on trim as a border, or to trim
> the Christmas tree
This is the other thing I disagree with, please don't open that can of
worms. Virtually every other programming language uses "trim"; that should
be a good enough reason for us to use it too.
perl -Mre=debug -e "/just|another|perl|hacker/"