in reply to Re^2: [RAKU] How to install zef on Ubuntu 22.04
in thread [RAKU] How to install zef on Ubuntu 22.04

Actually, UTF8 is not the major issue...it's just one of the tipping points. I have no issues with my UTF8 code, other than tedium in keeping track of it and making sure any new code updates are UTF8 compliant. That tedium would be erased by an all-UTF8 solution, such as Raku offers.

But the bigger issue for me is actually that my code has run into browser-related issues (browsers no longer work as they used to years ago when I started, and now force me to make changes). For example, I have never before used cookies; never needed them, nor wanted them (no need to post those massively annoying and now legally required cookie notices if not using them). Now I am experiencing anomalies because of my hidden-field data, and the updates are a massive headache when subroutines cannot accept named variables. Raku's subroutines do support named variables, which would solve this problem and make my code more maintainable and future-proof.

Blessings,

~Polyglot~

  • Comment on Re^3: [RAKU] How to install zef on Ubuntu 22.04

Replies are listed 'Best First'.
Re^4: [RAKU] How to install zef on Ubuntu 22.04
by marto (Cardinal) on Jan 10, 2024 at 12:58 UTC

    "I have never needed them, nor wanted them (no need to post those massively annoying and now legally required cookie notices if not using them)."

    Then don't use them?

    "Now I am experiencing anomalies because of my hidden-field data"

    Sounds like an issue with your code... which can happen regardless of the language used ;). Modern frameworks make life easier, and more fun, e.g. Mojolicious.

    "updates are a massive headache when subroutines cannot accept named variables"

    Perlcook book (2003?) - 10.7. Passing by Named Parameter.

    "Raku's subroutines do support named variables, which would solve this problem and make my code more maintainable and future-proof."

    Debatable.

      Then don't use them?

      I need to maintain a login session. Cookies appear to be the only viable solution when browsers now remember (cache) all the values of the form's hidden fields. I've been experiencing startling issues as a result, such as trying to login and the browser restoring the state of a different, previously logged-in, user, resulting in the wrong user logging in! In order to bypass this sort of behavior, I see no other way than to kow-tow to the cookie system that I have so long eschewed. Cookies aren't cached (as far as I know), and would be more secure, and more consistent, given that is what browsers have come to expect for session maintenance.

      Blessings,

      ~Polyglot~

         I've been experiencing startling issues as a result, such as trying to login and the browser restoring the state of a different, previously logged-in, user, resulting in the wrong user logging in!

        you are obviously doing something seriously wrong. Even if 2 different users used the same computer, same browser to access your system one after the other, provided they pressed the logout button (and provided your logout procedure worked) there should be no trace of the previous user's data visible to the next. And if the previous user did not logout, then the next one should never arrive to the login screen anyway. Cookies can live on, they can be made to expire at some time, they can be made to expire immediately and erased from the browser, they can be kept alive on the browser but the session you keep can indicate "logout" state etc.