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 -~----------~----~----~----~------~----~------~--~---
