[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty

2009-10-04 Thread Tobie Langel
Hi all. Can we please try to stay on topic. This thread's topic is about renaming methods whose ruby counterparts were suffixed with a question mark. It would be very helpful to list all of the methods which fall in that category so we have a better idea of the implications of such a change. F

[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty

2009-10-04 Thread Robert Kieffer
On Sun, Oct 4, 2009 at 4:53 AM, joneff wrote: > It's worth noting that (!aString) is more or less equal to > (String.isUndefinedOrNullOrEmpty) than it is equal to (String.isEmpty). It just means developers have to know the difference between "! aString" and "aString == ''". 'Don't think that c

[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty

2009-10-04 Thread Robert Kieffer
Tobie, I find myself wondering what other reasons you might have for keeping these methods, because the arguments you give don't seem to convincing (to me). In fact, it seems like you may have just phrased the same argument three different ways ... On Sun, Oct 4, 2009 at 4:25 AM, Tobie Langel wr

[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty

2009-10-04 Thread joneff
On Oct 3, 5:24 pm, Robert Kieffer wrote: > Quick reality check: Where is the value in String/Array functions that > test for emptiness? 'These methods are nothing more than wrappers > around code like, "if (!aString) ...", or "if (!anArray.length) ..." > - i.e. JS already has perfectly good con

[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty

2009-10-04 Thread artemy tregubenko
String#isEmpty checks not the length of a string, but absence of non-space characters, which is quite useful i.e. in form validation. On Sun, 04 Oct 2009 11:30:00 +0400, T.J. Crowder wrote: > > I'm with Robert, is there a good use case for these or should we just > deprecate them? > > But i

[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty

2009-10-04 Thread Tobie Langel
Hi everyone. There are various reasons to keep those methods around, some of which are: 1) Follow the Principle Of Least Surprise (POLS) by exposing a similar API across the whole platform, 2) simplify duck-typing, and 3) abstract implementation details (for example, Hash#isEmpty isn't as trivia

[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty

2009-10-04 Thread T.J. Crowder
I'm with Robert, is there a good use case for these or should we just deprecate them? But if we're going to get into renaming things, Enumerable#include is crying out for an "s" on the end ("if this thing include*s* this other thing then..."); without one it seems to say "include this argument in