Mailinglist Archive: yast-devel (51 mails)

< Previous Next >
Re: [yast-devel] "can't modify frozen String" and ruby-bindings
Dne 25. 02. 19 v 13:39 José Iván López González napsal(a):
I agree with your solution and explanations. I had would go with the option
duplicates and freezes the given string (just as I18n does), because having
behaviors when calling to _() looks a little bit surprising to me. But of
course, if
that supposes to kill our memory, it clearly doesn't pay off.
I do not think it would kill the memory, we use the translations for quite short
texts (labels, messages). Where it would hurt more are some long help texts.
But even
the longest text would have few kilobytes, so still nothing critical I'd say.

But what I really do not like is to do useless expensive calls just because in
someone could do obscure crazy things. I do not see any real meaningful example
the freezing would make troubles.

As I already mentioned, we use basically two options:

1) String literal: _("foo")
Here the freezing is harmless as the String cannot be referenced from the
following code.

2) String constants: FOO = N_("foo"); _(FOO)
The constants should be frozen anyway (the future Ruby versions will do
that automatically) so no side effect at all.

And now a case where it could harm:

foo = N_("foo: ")
puts _(foo)
foo << "bar" # this will crash after freezing foo

the question is what would you do with foo now?

puts _(foo)

would print an untranslated text because "foo: bar" text cannot be included in
POT file, there is no way how to extract it from the sources. Sure, you could
add it
manually, but why if a simple _("foo: bar") would work better?

So unless someone comes up with a meaningful example I'm quite reluctant to add
automatic string duplication just because of some theoretical useless case.

Ladislav Slezák
YaST Developer

SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >