3 ms·

Yeah, that's a decent point. To answer your question, it's as if it's the string "secure string" for the purposes of other string methods. I think this is a

Yeah, that's a decent point. To answer your question, it's as if it's the string "*secure string*" for the purposes of other string methods. I think this is a good point, and perhaps worth considering, but in most of my thought exercises, it's worth it, owing to the fact that when I use SecureString in other languages, I find myself having to decrypt the string more often than I would like. I guess one could argue that this is a deficiency of the libraries and such that are used, rather than a deficiency of the fact that SecureString doesn't extend String. I'm having trouble recalling a specific example right now, but I know I've run into it before, because that's what prompted me to implement this many years ago.

pjerem 5y ago
> Yeah, that's a decent point. To answer your question, it's as if it's the string "secure string" for the purposes of other string methods. That’s a problem because you are enforcing all your functions accepting normal strings to either have to check if it’s NOT a SecretString or to return some nonsense. For exemple a function that returns the 2 firsts characters without caring about secret string could be passed one as argument and return « *s ». The Liskov Substitution Principle states that a function accepting an Animal (a String) should never care about wether it’s a Cat (a Secret) and don’t fear Animal (String) methods to return meaningful values.