From: Nikolai Weibull Date: 2005-03-20T09:28:17+09:00 Subject: Re: strip and its evil brother strip! * ES (Mar 20, 2005 00:40): > WTF is with the attitude? Right back at you? Sorry for being a dick. I guess I should have calmed down and thought my response through more thouroughly before sending. > > That's a rather weak statement. > I think it's a pretty strong statement. 'Conceptually better' code > tends to be easier to write and understand. Yes, but just saying that it's conceptually better without giving a good reason for it doesn't really mean anything. Your solution for working around the problem that the solution that you argue is conceptually better just leads to another problem, a problem that so far doesn't have an obvious solution (i.e., what is discussed below--how to check for success). So it doesn't seem to be conceptually better, at least to me. > > > It could be given via the return value wrapped inside a > > > MethodCallResult [sic] structure. > > You're not using "sic" correctly. You use "sic" when you quote > > somebody elses writing that contains an error to make a not that the > > error occurs in the original and that you know about it. It is > > often considered redundant, as you assume that your reader isn't > > clever enough to understand that you probably quoted it correctly. > > The "sic" is usually added to in some way discredit the source you > > are quoting (and proving that you have nothing better to counter the > > argument being quoted with than the person being quoted's ability to > > write correctly). > 'Sic', latin. Literally, 'thus'. It here indicates a sentiment similar > to 'as it were'. You may be thinking of 'stat', which means 'so it was > originally'. No, that's not what I'm thinking of. It is used precisely as I described. It is not, in English, used as you suggest. I was not trying to be rude by pointing this out. I apologize if you thought it to be so. > puts "failed: #{$err}" failing line.strip!.downcase!.split // > The separation is such a high-level concept that it's probably not > possible to extend any existing language to take full advantage of it > though a workable solution is quite viable. Yes, but introducing additional language constructs to solve a problem introduced by the solution of a, to me, non-problem seems very costly. The best solution, it seems to me, would be to remove the destructive versions of these methods. I guess we're returning to the whole immutable versus mutable strings discussion again. Anyway, I'm not advocating the removal of all destructive methods. They're viable for hashes and arrays, which can be very costly to create anew, but strings are meant to be short by their very nature, as they are stored continuously in memory, and can then be copied rather efficiently. I have suggested earlier that what we perhaps need is a second string-like, or sequence, class that is better suited for doing a lot of transformations. I will try to put my money where my mouth is, but I'm strained for time as it is. I guess I shouldn't be spending so much time trolling on this mailing-list..., nikolai -- ::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka ::: ::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden ::: ::: page: minimalistic.org :: fun atm: gf,lps,ruby,lisp,war3 ::: main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}