[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
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 the enumerable -- e.g., add. -- T.J. :-) On Oct 3, 3:24 pm, Robert Kieffer bro...@gmail.com 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 constructs for this. It's great that Prototype is inspired by Ruby, but much of it's charm is due to the fact it's done a good job of avoiding the pitfall of providing lots of syntactic sugar for people that don't know JS. (Nevermind that Array#empty() would seem to be synonomous with ! Array#any(), btw) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
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 trivial to write as Array#isEmpty). Some of these methods clearly deserve to have better names. We're going to introduce naming changes in the upcoming versions of Prototype. Here's a tentative schedule using Array#(empty|isEmpty) as an example: In version 1.7: - Array#empty is renamed Array#isEmpty. - Array#empty, an alias of Array#isEmpty is added to source. - Array#empty is tagged as deprecated and alias of in the documentation. - Array#empty is marked as deprecated in the upgrade helper. In version 2.0: - Array#empty is removed from source code. - Array#empty is marked as removed in the upgrade helper. - Array#empty is completely removed from the documentation. It's obviously applicable to other method names. I don't see any incentives to remove those methods altogether. If you don't want to use them, just don't. Thanks all for our input. Best, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
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 t...@crowdersoftware.com wrote: 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 the enumerable -- e.g., add. -- T.J. :-) On Oct 3, 3:24 pm, Robert Kieffer bro...@gmail.com 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 constructs for this. It's great that Prototype is inspired by Ruby, but much of it's charm is due to the fact it's done a good job of avoiding the pitfall of providing lots of syntactic sugar for people that don't know JS. (Nevermind that Array#empty() would seem to be synonomous with ! Array#any(), btw) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
On Oct 3, 5:24 pm, Robert Kieffer bro...@gmail.com 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 constructs for this. It's worth noting that (!aString) is more or less equal to (String.isUndefinedOrNullOrEmpty) than it is equal to (String.isEmpty). Also, since we have no type hinting, (!aString) will work easily with objects, strings, numbers, booleans and basically everything, where as (String.isEmpty), or any string method for that matter, should throw an argument exception when receiving different type of arguments. At the same time (!aString/anArray.length) are perfect examples of JS magic in use. But then, the logical question is why use (Object.isFunction) over (typeof object === function)? It seems that the more questions are asked about the core semantics of Prototype, more questions arise. On Oct 4, 10:30 am, T.J. Crowder t...@crowdersoftware.com wrote: I'm with Robert, is there a good use case for these or should we just deprecate them? Now that is and interesting question. To me, to using (aString == String.empty) over (aString == ) is all about the sugar. Never the less I agree that any JS library should be bloated with useless code. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
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 tobie.lan...@gmail.com wrote: 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, Even when this conflicts with the principle of KISS? (I.e. Does POLS make it okay to over-complicate an API by having multiple ways of doing the same thing?) And isn't this pretty much the same thing as your next argument? ... 2) simplify duck-typing ... which is confusing, because where empty() is concerned, I don't know which objects it is you want to have quacking the same way. If you want String and Element - the only objects that currently implement empty() - to quack the same than they should test for the same thing, which they don't. (String tests for zero-length strings, Element tests for strings that only contain whitespace.) If you want Array to quack like other collection objects, well, it already does, by virtue of being an Enumerable. The duck typing argument doesn't apply. And if you want String and Array/Enumerable to quack like eachother, than I think you're headed down a slippery, problematic slope. If String is going to quack like a collection, than it shouldn't it be an Enumerable? I'm sure there are good reasons it's not... and whatever those reasons are would seem to be compelling arguments for why developers probably ought to know what type of object their dealing with, rather than trying to do the duck-type thing with them. Bottom line: where Array/Enumerable/String/Element are concerned the duck typing aspect of Prototype is a mess right now. The only place I think you can make this argument would be for some sort of String-like interface that Element and String would share. Which might actually be interesting and useful(???), but until it's actually in Prototype, I don't think there's any merit in this argument as a reason for keeping String#empty around. 3) abstract implementation details (for example, Hash#isEmpty isn't as trivial to write as Array#isEmpty). Implementation details don't have to be exposed as part of the public API however. And if such a detail is useful enough to be public, than isn't this the same thing as argument #2 (or #1)? - rwk --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
On Sun, Oct 4, 2009 at 4:53 AM, joneff jon...@gmail.com 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 changes the reality- check questions. Also, since we have no type hinting, (!aString) will work easily with objects, strings, numbers, booleans and basically everything, where as (String.isEmpty), or any string method for that matter, should throw an argument exception when receiving different type of arguments. Good point... although that laxness is part of the charm of javascript and (for me) is more of an advantage than a hindrance. Note, too, that by that same logic there should be functions for all sorts of native JS operators. Boolean#isFalse/isTrue, Number#add/ multiply...etc. It's a slippery slope. At the same time (!aString/anArray.length) are perfect examples of JS magic in use. But then, the logical question is why use (Object.isFunction) over (typeof object === function)? You're right, this sort of thing is always a judgement call. But to address your specific question, I see isFunction as offering several concrete advantages that isEmpty() lacks: - isFunction() is noticeably more compact than it's native counterpart - isFunction() avoids the all-too-frequent and insidious bug that happens when you misspell function (e.g. typeof object == 'fuction' is always false). - it centralizes a non-trivial test that may be improved in the future. (Specifically, some platforms will return a typeof 'object' for functions defined in other windows, which breaks the current isFunction() implementation). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
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. For discussing deprecation of particular methods, please create another thread. Please keep in mind that deprecation makes upgrading harder and is generally best avoided. Best, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
Prototype.js is an attempt to make Javascript more Ruby-like, so one of the reasons that these methods exists and are named that way, is that they are in Ruby (of cause Javascript lacks the ‘?’ in the method name). http://ruby-doc.org/core/classes/String.html#M000776 http://ruby-doc.org/core/classes/Array.html#M002177 I don't think we should change the name or remove the methods. # Tobias On Sat, Oct 3, 2009 at 5:49 AM, Yaffle vic99...@yandex.ru wrote: +1 for REMOVE this methods --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
It's specifically because JavaScript disallows certain characters in identifiers (such as '?', for example), that we have decided to prefix certain methods with 'is', 'has', etc. for version 1.7 / 2.0. Without neither those characters nor adequate prefixes, the name of certains methods are ambiguous and misleading. Best, Tobie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
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 constructs for this. It's great that Prototype is inspired by Ruby, but much of it's charm is due to the fact it's done a good job of avoiding the pitfall of providing lots of syntactic sugar for people that don't know JS. (Nevermind that Array#empty() would seem to be synonomous with ! Array#any(), btw) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
I'd prefer isEmpty as well. Allen Madsen http://www.allenmadsen.com On Fri, Oct 2, 2009 at 3:34 PM, joneff jon...@gmail.com wrote: I've been pondering on this one for quite a long time -- why is it String#empty instead of String#isEmpty? To me String.empty should be a field equal / referencing the empty string and not a method. I was gonna hold this to my self, but the last few days there's been some discussion about semantics (Element#destroy and Function.empty per say) and I though may be it about time to ask this question. So is there any particular reason, besides #empty being shorter than #isEmpty and does my suggestion make sense to you? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
I totally agree. `Array#isEmpty` would be useful too. Maybe we should rename those methods and deprecate the original names in 1.7. Best, Samuel. 2009/10/2 Allen Madsen bla...@gmail.com I'd prefer isEmpty as well. Allen Madsen http://www.allenmadsen.com On Fri, Oct 2, 2009 at 3:34 PM, joneff jon...@gmail.com wrote: I've been pondering on this one for quite a long time -- why is it String#empty instead of String#isEmpty? To me String.empty should be a field equal / referencing the empty string and not a method. I was gonna hold this to my self, but the last few days there's been some discussion about semantics (Element#destroy and Function.empty per say) and I though may be it about time to ask this question. So is there any particular reason, besides #empty being shorter than #isEmpty and does my suggestion make sense to you? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
+1 for renaming both. 2009/10/2 Samuel Lebeau samuel.leb...@gmail.com I totally agree. `Array#isEmpty` would be useful too. Maybe we should rename those methods and deprecate the original names in 1.7. Best, Samuel. 2009/10/2 Allen Madsen bla...@gmail.com I'd prefer isEmpty as well. Allen Madsen http://www.allenmadsen.com On Fri, Oct 2, 2009 at 3:34 PM, joneff jon...@gmail.com wrote: I've been pondering on this one for quite a long time -- why is it String#empty instead of String#isEmpty? To me String.empty should be a field equal / referencing the empty string and not a method. I was gonna hold this to my self, but the last few days there's been some discussion about semantics (Element#destroy and Function.empty per say) and I though may be it about time to ask this question. So is there any particular reason, besides #empty being shorter than #isEmpty and does my suggestion make sense to you? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
+1 for REMOVE this methods --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
