in reply to Re: chopping a string into slices - is there a more elegant way to do it?
in thread chopping a string into slices - is there a more elegant way to do it?

I wouldn't use unpack unless you mean to work with bytes (encoded characters?) instead of characters. 

use utf8;
use open ':std', :locale';
my $s = "fête";
print("$_\n") for unpack '(a3)*', $s;

[download]

prints 5 characters from the 4 given.

Replies are listed 'Best First'.
Re^3: chopping a string into slices - is there a more elegant way to do it?
by BrowserUk (Patriarch) on Nov 05, 2008 at 02:19 UTC
    unless you mean to work with bytes (encoded characters?)

    I don't "mean to work with" anything--ask the OP. I simply sought to enhance ccn's suggestion by pointing out the (..)* template syntax.

    And wtf do you think you mean by (encoded characters?). All characters are encoded. It's just a case of how they are encoded. Luckily for me, at least 80% (probably closer to 98%) of the data I deal with, characters == bytes. So, following the 80/20 rule, I only expend effort to deal with the 2% when it is required.

    And, as your snippet demonstrates, in order to get strings into perl that are anything other that byte-encoded, the programmer has to take (one or more) extraordinary steps. And if the OP is aware enough of his data to know that s/he needs to take those extraordinary steps, then they are

    • probably aware enough to recognise immediately that the (ccn's) suggestion, to use unpack is not going to work for their situation;
    • Or: not aware enough to recognise the limitation, but will quickly discover it when they test the suggestion out in their environment;
    • Or: will quickly discover the problem, when they start getting garbage output from their program.

    If the unpack solution does not work for them in their environment, whichever way they become aware of it, it will either be a split second of thought for them to dismiss it as a possibility; or a really, really, good lesson for them to learn.

    You seem to believe that you can either:

    • predict from the OPs question, every intimate detail of their operating environment and so can tailor your responses to their questions such that no matter how naive they are, your solutions will always work, in their environment.
    • Or; always produce responses (code) that will always function perfectly regardless of the OPs operating environment.

    And that attitude is either:

    • Arrogance beyond countenance.
    • Stupidity beyond belief.

    To summarise: It is impossible to predict the full details of the OPs operating environment, and it will (has!) taken (far more than) 20 questions to interrogate it. So, in a forum such as this, where 20 questions could take anything from 2 days, to 2 weeks, to two times the twelfth of never to ask/be answered; I prefer to grant the OP the assumption of intelligence; rather than assume their stupidity.

    Any presumption on your behalf to assume that you can produce code, in response to OPs questions, that will operate perfectly in their environment without their having exercised any modicum of locality awareness or data knowledge, is totally unfounded. And if there is even a 1% percent chance that the code you produce will not operate in their environment without their testing it, then all your efforts and pedantry are wasted; and no better than my "assume the OP knows what they are doing" responses.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

      I don't "mean to work with" anything--ask the OP.

      I was. I was giving information to the OP about your post. It's ironic that you accuse me of arrogance.

      probably aware enough to recognise immediately that the suggestion, to use unpack is not going to work for their situation

      I expect him to not know the assumptions made by a solution he didn't know before you gave it to him. I simply inform him of those assumptions. I leave it up to him to decide whether the limitations imposed by those assumptions affect him or not. That's not treating the OP as stupid.

[reply]

In Section Seekers of Perl Wisdom