Re: [Prototype-core] Re: Kudos to the documentation team
I disagree. 404'ing the old docs is not the correct action. 404 means not found, but the user is requesting a page that he (and you) know exists... it's just not at that location any more. Thus, a redirect is the way to go. I'd suggest the following - Move the old docs somewhere they're still available, but under a different URL. - 301 (or 302) redirect old URLs to the new documentation as appropriate - In the new documentation, provide a old API docs link to wherever you moved the old docs to, so people can still get to them if they need to. - Set up robots.txt file to tell search engines to ignore the old docs - rwk On Tue, Apr 6, 2010 at 2:00 AM, Tobie Langel tobie.lan...@gmail.com wrote: A practical solution would be a well designed 404. We could get pdoc to generate it with a search field, etc. We could also try JS redirection. Anyone wants to give it a shot? Best, Tobie On Apr 6, 8:42 am, T.J. Crowder t...@crowdersoftware.com wrote: My coworkers still find old docs (http://prototypejs.org/api) by googling. I had to point them to new doc site. I think it's crucial to set up 301 redirects. *ONLY* if all of the old information has now been ported over. Looking at the documentation Lighthouse project[1], it looks like all of the old merge/update tickets have been closed (yay!), which may mean exactly that, someone from the docs team can presumably confirm that. Once we're ready, 301s that live in those locations for a long, long time are indeed appropriate. Or if 301s are hard in Mephisto, replacing each of the API documentation articles with a link to the new one. [1] https://prototype.lighthouseapp.com/projects/42103-prototype-document... -- T.J. On Apr 5, 3:30 pm, Mislav Marohnić mislav.maroh...@gmail.com wrote: On Mon, Apr 5, 2010 at 11:48, Johan Arensman johanm...@gmail.com wrote: Wow! I didn't even realise they were updated until I read this message. Very nice work indeed! My coworkers still find old docs (http://prototypejs.org/api) by googling. I had to point them to new doc site. I think it's crucial to set up 301 redirects. -- 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 To unsubscribe, reply using remove me as the subject. -- 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
Re: [Prototype-core] Re: Kudos to the documentation team
Urm... really? You can do 404's but not 301's? Not saying I don't believe you, I'm just surprised that a project as mature as prototype is hosted in an environment that doesn't support basic .htaccess-style configuration. On Tue, Apr 6, 2010 at 6:12 AM, Tobie Langel tobie.lan...@gmail.com wrote: Robert, that would be great. We unfortunately don't have this level of access to the server. -- 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 To unsubscribe, reply using remove me as the subject. -- 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
Re: [Prototype-core] Re: For() loops, ++i, i++, i+=1
T.J. Be sure you've unchecked the normalize results checkbox. That will get rid of the infinite ops/sec. FWIW, that checkbox is provided as a way of subtracting out the time required to do an empty loop when computing test performance. In 99% of cases, where you're interested in testing the performance of what's inside the iteration loop and not the loop code itself, you want that box checked. In this particular case, though, we're testing empty loop performance, so it needs to be unchecked. (And, of course, subtracting out that time usually yields a zero result - hence the infinite ops/second. So, yeah, as long as you can break RSA keys using empty code blocks, knock yourself out!) - rwk ;-) On Thu, Dec 17, 2009 at 12:53 AM, T.J. Crowder t...@crowdersoftware.comwrote: I'd post Chrome and Firefox results for Windows, but I kept getting infinite numbers of operations per second! ;-) Chrome (of course!) did an infinite number of ops/second on all of the tests. Firefox alternated between infinite numbers of ++i and i++ operations -- so probably a wash there too. Now, since I apparently have the power to do infinite numbers of calculations, I'm off to break some RSA keys... -- T.J. ;-) -- 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
Re: [Prototype-core] Re: For() loops, ++i, i++, i+=1
Unfortunately IE limits scripts to 5M statements, rather than limiting by
time. That limit was set back in the days of IE4, when 5M statements would
take ~10 seconds to run. But newer hardware/script engines hit that in a
fraction of a second now... which is why you're seeing it.
The workaround is to edit your registry to increase the limit to 50M
statements (or more). This MS article explains how, and provides a bit more
background on of this ( ridiculous) behavior.
http://support.microsoft.com/default.aspx?scid=kb;en-us;175500
On Wed, Dec 16, 2009 at 4:44 AM, Allen Madsen bla...@gmail.com wrote:
I tried running your test on IE8 and it just kept prompting me with script
unresponsive.
Allen Madsen
http://www.allenmadsen.com
On Wed, Dec 16, 2009 at 7:01 AM, Robert Kieffer bro...@gmail.com wrote:
I whipped up a quick JSLitmus test to try out a handful of empty loops
(using i++, ++i, i+=1, and a while loop:
http://www.broofa.com/Tools/JSLitmus/tests/loop_operators.html
View the [very short] source of the page to see the actual test code.
When running the test for yourself, be sure to uncheck the normalize box.
Also, you'll probably want to run each test a few times to make sure you're
getting consistent results (CPU load elsewhere in the OS can skew resutls).
For more on JSLitmus, read http://www.broofa.com/Tools/JSLitmus )
Here are the results I got on my MacBook (sorry, don't have IE results
handy)
FF: http://tinyurl.com/ykdutyk
Safari: http://tinyurl.com/yzusg7e
Opera: http://tinyurl.com/yjamzwc
Chrome: http://tinyurl.com/ylylyw5
Executive summary: On the above browsers, performance does vary. i++ or
++i are the best all-round performers, while the while() loop is generally
not as good. However on all of these systems ('cept Opera), looping code
runs so fast that performance is negligable compared to whatever code you
put inside the loop. I.e. it's unlikely to matter in all but the most
trivial of loops.
- rwk
On Wed, Dec 16, 2009 at 2:28 AM, Yaffle vic99...@yandex.ru wrote:
++i; is a little more efficient in C language,
in javascript difference in performance of all these operators is tiny
On Dec 16, 3:21 pm, RQuadling rquadl...@googlemail.com wrote:
Hi.
Is there any consensus on which is more efficient in a for() loop?
I was taught that for ++i being the most efficient.
I've created 2 patches (++ and a +1) in case anyone is interested.
http://pastie.org/private/3rgonpsn90yjd17q9zwa
andhttp://pastie.org/private/qufy3rwmaevxc1sysvq
From what I've read, this could be a little pointless, but I'm not the
expert in this area.
Regards,
Richard.
--
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
--
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
--
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
--
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: Function.EMPTY and Function.K
Izador, by your logic shouldn't all static methods should be up-cased - Math.random, String.fromCharCode, Date.now, etc? They are all unique and, for all intents and purposes, canonical. Or to put it another way, what is the difference between f(x) = x and f(x) = x+1... why would the former be up-cased, but not the latter? My vote goes to lower-case. It's easier to type, and I don't see enough of a distinction to warrant special casing. - rwk On Wed, Oct 21, 2009 at 7:33 AM, Izidor Jerebic ij.l...@gmail.com wrote: On 21.10.2009, at 14:38, joneff wrote: Actually, from your point of view each unique function (a function that returns different result for different argument) should be considered constant function since there is only one way to get the result. This is true. Value of a function 'f' is not its return value (there is none without parameter), but the code which defines its behaviour. You can do alert( f ) to see how javascript treats function values. To me a constant function is f(x) = x^0, since it's always equal to 1. This is a function which returns constant value (constant in space of floating point values). The return value is not the value of function in function space, the value in function space is the code which defines its behaviour. And in this space IDENTITY is constant - there is only one. alert( Funtion.IDENTITY ) shows you the value, and this value is constant in space of function values. This is one special function value - it corresponds to function which returns its parameter, and because of that this constant value deserves a name (unlike other constant function values, for which we do not have a name). --~--~-~--~~~---~--~~ 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: Prototype.Compatibility (was Units of Measurement...)
Regarding added weight of compatibility stuff I will never use, one of the main reasons I proposed this is that allows devlopers to decide on a per-case basis when and where to support backward compatibility. I.e. if the code .vs. benefit analysis doesn't make sense, don't support it. T.J, You make a good point about testing. Testing complexity to be part of the benefit analysis. I provided the delay() method above as one example of where this might make sense. But let me point to another example where I think conditional backward compatibility would have been tremendously valuable: The Hash API change that happened in v1.6. This broke a _lot_ of code, and was a significant hurdle to teams that wanted to upgrade. At Zenbe, the 1.6 release put us in a real bind - it had a lot of exciting new features, features that we desperately wanted (e.g. real subclassing support), but we simply couldn't afford the time required to identify and fix the 100's of dependencies we had on Hash in our code base. We ended up using a monkey-patched version of 1.6 on our production site for several months, while using the real version of 1.6 in development and testing. It would have been great to have a switchable compatibility option in that case. I'll risk shooting my own idea in the foot by pointing out that the biggest issue with this idea is not what effect it has on the code, but rather slippery slope it starts down. Once you start providing Compatibility support for one or two features, users are going to start clamoring for it all over the place. There should probably be some firm guidelines about what factors decide whether or not a feature supports this, and for what versions Compatibility support will be provided for. (E.g. Compatibility is only offered for the previous dot-release or something like that.) On Oct 11, 2:46 pm, Allen Madsen bla...@gmail.com wrote: I have to agree with T.J. In addition to complexity, there is also a concern for size. If I am using the newest version of the code, why would I want the added weight of compatibility stuff I will never use? Allen Madsenhttp://www.allenmadsen.com --~--~-~--~~~---~--~~ 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: Prototype.Compatibility (was Units of Measurement...)
Does that update helper identify where code accessed Hash objects? (Doesn't
look like it.) The 1.5-1.6 upgrade was mostly painless, except for the
Hash API change. And the problem there was that accessing a 1.5 Hash is
done just like a generic JS object, so there was no reliable way to parse
code to identify where you needed to change a JS style reference like
aHash.foo to aHash.get/set('foo'). I ended up reviewing and updating
all of our code manually. It worked, mostly, but the only way to test it
was to just beat on the app as much as possible... which was obviously less
than ideal. Hence the months-long delay between using it in dev/testing and
adopting the un-monkeyed version in production.
On Sun, Oct 11, 2009 at 6:06 PM, Tobie Langel tobie.lan...@gmail.comwrote:
[OT] Robert, had you tried the update helper to help out with this
migration?
--~--~-~--~~~---~--~~
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: Prototype.Compatibility (was Units of Measurement...)
Ah... didn't quite grok the __defineGetter/Setter__ calls first time through. Cool... 'wish I'd known about that at the time. Live and learn I guess. :-P On Sun, Oct 11, 2009 at 7:22 PM, Tobie Langel tobie.lan...@gmail.comwrote: Does that update helper identify where code accessed Hash objects. Yes, provided there had been set before. --~--~-~--~~~---~--~~ 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] Suggestion: Prototype.Compatibility (was Units of Measurement...)
I'd like to get everyone's opinion on an idea for simplifying the backward compatibility issues in Prototype. This comes in reaction to Joran Greef's suggestion that the Prototype API should standardize on milliseconds as the unit of time passed to methods like Function#delay () (which currently take seconds): http://groups.google.com/group/prototype-core/browse_thread/thread/545fa9feda1736a0?hl=en Joran's arguments have merit, but as T.J., says I don't see changing ... barring a wholescale Prototype API rewrite. This position is understandable, given how much upheaval API changes cause in the Prototype community nowadays. But, boy, it sure would be nice if there were a good compromise! To address this issue, I propose adding a Prototype.Compatibility property. It is similar to Prototype.Version, but has a semantic of, the desired version of compatibility. By default, this would be set to the current version: Prototype.Compatibility = Prototype.Version; Users could set this after importing Prototype to control the behavior of any API that honored this setting. E.g. To indicate you would like compatibility with version 1.6 (to the extent possible), you would do this: Prototype.Compatibility = 1.6; Internally, methods like delay() could be tweaked to honor this as follows: // Old code: // timeout = timeout * 1000 // New code: timeout *= (Prototype.Compatibility 2.0 ? 1000 : 1;) Please note that I'm being very careful not to imply that Prototype 2.0 should have a way to achieve across-the-board compatibility with 1.6. Rather, I'm saying only that there are certain cases where supporting this property is trivial, and this has the dual benefit of making it easier to clean up and evolve the Prototype API, while minimizing compatibility issues for users that upgrade. --~--~-~--~~~---~--~~ 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
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: Function.EMPTY and Function.K
Function.empty and Function.identity get my vote. However, does this mean Prototype.EMPTY and Prototype.K are being deprecated? I ask because I generally dislike aliases in APIs. Unless they are used as part of the deprecation process, they are usually more trouble than they're worth. They make code harder to read and share, developers get into silly quibbles as to which is better, etc. In short, they're annoying - it's better if the framework developers make it clear what the preferred name is, and eventually deprecate the non-preferred ones. My $.02. - rwk On Fri, Sep 25, 2009 at 6:19 AM, T.J. Crowder t...@crowdersoftware.comwrote: We could _so_ overcomplicate this... ;-) On Sep 25, 1:29 pm, Jim Higson j...@wikizzle.org wrote: On Friday 25 September 2009 13:08:57 Rick Waldron wrote: On the subject of end developer confusion, I'd like to make a suggestion regarding the naming... Function.emptyFn Function.returnFn Because they say exactly what they are. This is how I've named (almost... $.function.emptyFn() and $.function.returnFn() ) the exact same functionality in the Pollen.JS library (for use within a new Worker() ) I'd say returnFn sounds like a function which returns a function. -- Jim my wiki ajaxification thing:http://wikizzle.org my blog:http://jimhigson.blogspot.com/ --~--~-~--~~~---~--~~ 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: A more efficient $super for Prototype 2
I'm with Allen on this. I don't think it's uncommon for mixins to want to
hook into existing functionality. This is trivial if they can invoke $super
(the original object's method), and problematic otherwise.
To give a concrete example, a while ago I implemented a Selectable mixin
for some collection classes. Because this mixin maintained the selection
state in a private cache, it needed to hook into the remove() method to
allow it to properly update the cache. Thus, I could easily see doing
something like this:
var Selectable = Class.createMixin({
// Various methods we add to the collection class...
selectItem: function(item){...},
deselectItem:function(item){...},
getSelectedItems: function() {...},
// Make sure we deselect items before they're removed
remove: function($super, item) {
this.deselectItem(item);
$super(item);
}
})
On Wed, Sep 9, 2009 at 7:31 AM, Allen Madsen bla...@gmail.com wrote:
TJ,
I don't particularly think this is a problem or even a new problem
(wouldn't the current let you do this as well?). This sounds like
protecting the developer from themselves. I think as long as you
sufficiently state what will happen in a particular instance then it
is perfectly reasonable to allow each individual developer to handle
it as they see fit.
Allen Madsen
http://www.allenmadsen.com
--~--~-~--~~~---~--~~
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: A more efficient $super for Prototype 2
I still have some serious reservations about this patch. Before I dive into details, though, can someone please tell me why we're not looking at Dean Edwards old Base2 approach[1], or John Resig's variation on that[2]? That general approach would seem to offer a good trade-off between performance and usability. ... and it's that trade-off I have reservations about. If Prototype is going to replace the current $super technique, it's this tradeoff that I would like to see a nice balance on. And with all respect to you, T.J., I don't think your solution has that. There's no question it is more performant (woot!), but I have serious doubts about it's overall usability. The requirement for named function expressions (NFEs) puts a serious crimp in developers coding style. Having to declare the functions in one section and then wrap them up in a returned data structure in another... It's nice that this style works for Prototype, and I appreciate the advantages, but it's not exactly commonplace (not that anything is). It'll definitely give more than one developer pause. Can I politely suggest that maybe you guys are a bit too close to the code and are taking the learning curve here for granted? And having to explicitly type the name of each function 3-4 times to define it will very quickly get tiresome. It makes writing code harder, and it makes refactoring it harder as well. Which means more prone to error; there is still no IDE that is able to automatically and accurately change the name of functions when declared like this. With all the drum-beating around here about code maintainability, I'm a little surprised to see this issue treated so lightly. Most importantly, the syntax for invoking a supermethod, while not quite as horrid as some others we've seen and discussed, is still not that great. I mean, come on, close your eyes, take a few deep breaths, and then look at it... nifty.$super.call(this, spiffy) ... .vs. the current style: $super(spiffy) ... or what the Dean Edwards/John Resig style: this._super(spiffy) I know, I know, the current style has performance issues. But for a lot of developers a simpler, less confusing syntax will trump that. I suspect most will continue to use the old $super scheme, which will make it much harder to deprecate than you might expect. And if the old $super scheme is gonna stick around for a while because the new scheme ain't good enough, than at the end of the day this new code is just unnecessary code bloat. Certainly Prototype itself doesn't need it - the Ajax.* classes and Timed Observer aren't used in situations where $super is called so often that the incremental performance improvement will make a difference. Sorry, I probably should have posted this before you spent your time implementing your patch. Still... I hope this is a constructive gut check for folks. - rwk [1] http://dean.edwards.name/weblog/2006/03/base/ [2] http://ejohn.org/blog/simple-javascript-inheritance/ --~--~-~--~~~---~--~~ 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: A more efficient $super for Prototype 2
On Sep 8, 8:44 am, T.J. Crowder t...@crowdersoftware.com wrote: arguments.callee.$super.call(this, arg); this.callSuper(arguments, arg); six of one, half-dozen of the other... but I suppose there is no perfect solution. Still, it's hard to swallow something this convoluted when you've gotten used to $super (or this._super() ) :-P My issue with Resig's approach would be the number of introduced closures and the slippery _super method, which has too much magic in it for my taste. These things are subjective. It also won't perform as well, but we're talking a small increment, and as you say trade- offs come into play. I have to confess it's been long enough since I looked at that code that I don't have an opinion about it. I do know that it performance tested well, and I definitely prefer the invocation syntax. Honestly, at this point I'm mostly worried that that we may get enamored with a solution that is different, but not necessarily all that much better. More performant, yes, but at the cost of usability. I'm tempted, even, to argue for the removal of supermethod invocation altogether in Prototype. It's not like it actually needs it - there are a couple places where $super is used, but it would be trivial to rewrite that to where it's not necessary. Developers would benefit from a smaller Prototype codebase, and they code pick and choose the supermethod technique that best met their needs, and import the appropriate script for that. That notion is both heretical and ironic I suppose, since I guess I started the whole look how shitty Prototype supermethod performance is! thread. But history has taught me that developers who write code without having a concrete use for it very rarely make the right choices. It's much better to let requirements drive the code choices, rather than the other way around. Okay, climbing down off my soapbox now to go get lunch. :-) - 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: A more efficient $super for Prototype 2
On Tue, Sep 8, 2009 at 1:21 PM, T.J. Crowder t...@crowdersoftware.com wrote: Hi Robert, arguments.callee.$super.call(this, arg); this.callSuper(arguments, arg); six of one, half-dozen of the other... Um, this.callSuper(arguments, arg) (or this.callSuper(nifty, arg)) is precisely *one* argument more than Resig's this._super(arg), but without the cost of the closures and unnecessary, misleading (IMV) magic. It's a lot clearer than the raw syntax needed with anonymous functions. Six of one, half-dozen of the other seems a bit harsh. I apologize, I was being glib (hence the quotes.) But there is a grain of truth there. Both these incantations are unintuitive in their own way. callSuper may have only one more argument but it's a wierd one for sure. Especially for developers unfamiliar with 'arguments' and its 'callee' property. Many devs will treat this as yet another piece of JS voodoo code they have to remember - you do it just because. And what if the super method takes different arguments than the sub method, Wait a minute, why am I passing an array with 'foo' 'bar' in it, when I only want to hand 'baz' to the supermethod? Honestly, at this point I'm mostly worried that that we may get enamored with a solution that is different, but not necessarily all that much better. More performant, yes, but at the cost of usability... That's interesting. I started down this road precisely because I found the existing API flawed; Was it the API you found flawed, or the implementation of that API? I think the $super argument is a rather elegant solution. Non-standard, sure, and lacking performance, but conceptually elegant. In essence: If you need to access $super, just pass it to yourself as the first argument. It's easy to remember, and hard to screw up. I didn't realize you'd done a crappy performance in supercalls thrread (I was away from this group for a while). I'd seen the excellent work you did with curried and bound functions, though, and I'm glad to hear that will be finding its way into 1.6.1. It wasn't a thread in this group but, rather, the blog post I did a while back that got some attention on Ajaxian.com and that other folks ran with for a bit on their own blogs: http://ajaxian.com/archives/javascript-inheritance-performance --~--~-~--~~~---~--~~ 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: Copying arguments
Tobey, like TJ, I've been eagerly waiting for these changes to appear and puzzled by the delay. I was under the impression the concerns you and others had were addressed back in March, and that pushing this change into the codebase was a little more than a matter of committing the patch. To be met with abstract arguments about stylistic issues and performance .vs. LOC now is surprising and discouraging. I'm pretty sure we discussed _exactly_ those issues back in March; I believe I provided data on how this patch would affect the prototype.js file size, and we went back and forth over things as trivial as the names of local variables. I don't *need* to have this patch make it into the prototype distribution - as I said in my original post, we've patched the prototype core, so it's little more than an occasional nuisance when we upgrade to migrate those changes. But as the main proponent for this patch, which as an improvement to core performance will benefit nearly everyone who uses Prototype, I'm at a loss for how to move this along. And frustrated by that. Sorry, guess that's not very understanding. :-J On Sep 5, 5:37 am, Tobie Langel tobie.lan...@gmail.com wrote: Hi, kangax. I understand and appreciate your eagerness (I feel the same). However, for the benefit of our users and the code base, I think it's important that we: 1) handle the most pressing issues at hand first (mainly doc related), 2) agree on stylistic issues (this patch clearly doesn't look very prototypish to me), and 3) discuss performance versus LOC issues and reformat that patch accordingly. Let's focus our attention where it's most needed at the moment: completing the documentation. Thanks for your understanding. 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: Copying arguments
Whups, sorry about butchering your name. I'm seriously sleep deprived these days - a result of our new 5-month old kid. :-) Re: Documentation for how and why the patch works - Is that a new requirement for Prototype code? This is the first I've heard of something like this. My original post in the discussion (link above) goes into a fair bit of detail. Where does this documentation go? What is expected? Sorry, it's been a while since I looked at the prototype code base and, as of March, I thought my patch was pretty consistent with how things are done. I apologize for being so obtuse on this, but can you please elaborate on what you mean by a final, reviewed, and cleaned up patch?In re- reading the ticket, I simply don't see where the issues are. The only issue that I guess didn't get addressed was your request for more descriptive variable names... but that didn't seem to be a showstopper (nor consistently applied w/in the existing codebase). But if it makes a difference, I'm happy to do the renaming. Cheers, - rwk On Sep 5, 12:11 pm, Tobie Langel tobie.lan...@gmail.com wrote: Hi again, Robert. The patch linked by kangax certainly doesn't account for the various things we discussed back then. It notably doesn't document the reasons why and how your (very smart) implementation works. That patch also has various stylistic issues which I remember discussing and that we had all agreed to modify for a final patch. If I recall correctly, this patch just didn't make it in because a final, reviewed and cleaned up patch wasn't submitted. An unfortunate yet frequent issue with OSS. Given the amount of work that was put in this patch and the huge perf benefits it brings about, I think it makes sense to add it to an otherwise frozen 1.6.1 version provided a proper patch gets submitted. Best, Tobie Unrelated P.S.: Would appreciated not seeing my first name butchered. :-) --~--~-~--~~~---~--~~ 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: A more efficient $super for Prototype 2
Hey gang, I took a look at this issue a while ago, in a blog post that generated a fair bit of discussion and spin off investigations (see http://www.google.com/search?q=inheritance+performance+javascript) so I'll try to weigh in. However I'm in the middle of an extended road trip, so I don't have the time/resources necessary to give this proper attention... http://ejohn.org/blog/simple-javascript-inheritance - JQ's swipe at this problem. Definitely read through the comments. Your approach appears similar to his (which is based on Dean Edward's Base2). Dean uses this.base(), instead of this.callSuper(), fwiw. no strong opinions there, although this.base() seems a bit more prototype-like in it's terseness. The performance tests I did for Base2 (see the broofa.com article in the google search above) are probably a good first-guess at the performance your approach will have compared to other techniques. Technically this doesn't break backward compatibility - $super and this.callSuper() can coexist as dual techniques for doing inheritance, correct? We just need to decide if $super support will continue in P2. ... and, finally, I vaguely recall people raising some interesting edge cases. But I don't remember where I saw those. *sigh*. - 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: Suggested addition to Function Methods: .repeat(seconds[, arg...])
@TJ... Your goals sound about right. Implicit in there, I think, is make it easy to deprecate PE at some later date. At least, that's how I read it. :) Re: #2 - Why not just use bind() to provide context? I've never been a fan of overloading arguments with multiple interpretations. 'Gets too confusing, and makes the implementation that much uglier. Re: #4 - I feel the ability to self-stop is more important than being able to repeat() functions that aren't designed for it. I _really_ feel that making the self-stop behavior an optional add-on feature of PE is a bad idea. self-stop is an elegant pattern (IMHO) so forcing users to go through the awkward PE API to get at it doesn't make sense. Also, it makes deprecating PE harder. ***Hmm...*** How about this as a solution: Instead of having a function return false to stop, have it throw $break! I think that addresses your concern, and is consistent with how Prototype does this sort of thing elsewhere (in Enumerable). --~--~-~--~~~---~--~~ 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: Suggested addition to Function Methods: .repeat(seconds[, arg...])
I can't say I'm a big fan of this. For several reasons.
First, it's just a cosmetic replacement for setInterval(myfunction
(...).bind(), ...) which simply isn't all that bad.
Second, I'm not a fan of setInterval in general. I've seen some
rather nasty behavior with calls queuing up if the invoked function
takes longer than the delay to execute. In particular, this seems to
be an issue if you do something like put a laptop to sleep. (But
maybe others haven't seen this problem???) Thus, I prefer to use a
self-invoking timeout like so:
function myFunction() {
// do stuff ...
// call ourselves again
if (/*we want to continue?*/) setTimeout(myFunction, 1000)
}
This doesn't call the function at exactly one second intervals, but
that type of accuracy is rarely important. Instead, it guarantees you
have at least one second of delay between invocations, which for
distributing cpu load or polling (the more common cases where
setInterval might be used), is more desireable.
Finally, as Joe T. points out, there should be a way of cancelling the
interval that doesn't require the user to store the returned value
(*that* is what I find most annoying, not the syntax of
setInterval).
Thus, I'd suggest this instead:
Object.extend(Function.prototype, {
repeat: function(delay) {
// Reset state
if (this._repeater) delete this._repeater;
this._repeatTimeout = clearTimeout(this._repeatTimeout);
if (!delay) return; // (stop repeating if no args or delay==0)
// Create setTimeout-based invoker
var _method = this;
if (!this._repeater) this._repeater = function() {
// Let _method cancel repeat by doing return false;
if (_method() !== false) setTimeout(_method._repeater, delay);
}
// Start repeating
this._repeatTimeout = setTimeout(this._repeater, delay);
},
stopRepeating: function() {
this.repeat();
}
});
For example:
var count = 0;
function foo() {
console.log(count++);
return count 10; // Return false when count = 10 to cancel
the repeat
}
// Start repeating 1/sec
foo.repeat(1000);
//... some time later change interval to 2/sec
foo.repeat(500);
// ... later still stop repeating.
foo.stopRepeating();
As you can see, this implementation of repeat() does a lot more for
you than simply alias'ing setInterval:
- It guarantees your function is only invoked by one interval
- It makes changing the interval or cancelling it altogether
trivial.
- It allows you to conditionally cancel the repeat from w/in the
function itself.
The only thing missing is the bind() behavior but, well, that's what
bind is for. If you need to bind arguments, just bind() your
arguments first.
On Jun 23, 8:25 am, Rick Waldron waldron.r...@gmail.com wrote:
I detest the way setInterval() looks, so I came up with this... have been
using it my personal JS for some time.
Object.extend(Function.prototype, {
repeat: function() {
var __method = this, args = $A(arguments), interval = args.shift() *
1000;
return window.setInterval(function() {
return __method.apply(__method, args);
}, interval );
}
});
// usage:
var _pollInt = 0;
function repetiousPollFn() {
console.log(_pollInt++);
}
repetiousPollFn.repeat(.5);
Will, of course, repeat repetiousPollFn() every half second.
Almost identical to .delay(), except that it returns setInterval instead of
setTimeout. One thing I intend to add is support for clearInterval, however
I figured I'd at least bring it up here first. I've never
proposed/contributed here before (i'm a lurker of the list :D ) - any
guidance is appreciated.
Rick
--~--~-~--~~~---~--~~
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: Suggested addition to Function Methods: .repeat(seconds[, arg...])
FWIW, PeriodicalExecuter has always struck me as a bit of a wart on the Prototype API. The name and usage are awkward, and it's functionality really feels like something that should just be a Function extension, as we're seeing in this thread. I'm assuming it's presence is mostly a legacy thing. But... I'm not really arguing for it's removal. Just pissing into the wind. :-) On Jun 24, 9:53 am, Tobie Langel tobie.lan...@gmail.com wrote: Just to clarify the above: Prototype Core already contains a similar functionality: PeriodicalExecuter. The API is different but the functionality is the same. I'd strongly suggest looking into combining both approaches if you want your suggestion to be included in core and not just stay a thread in the mailing list. :) 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: Add JavaScript Lint to build process?
Please note that I didn't mean to imply that Prototype should adhere
to every warning and suggestiong that JSLint emits. IMHO, many of
them add little/no value and can safely be ignored. But missing semi-
colons, and ambiguous if-else blocks (for example) are the sorts of
things that should probably get cleaned up.
FWIW, here's what our jsl warnings configurations look like As you
can see, I've disabled a bunch of stuff that just didn't add much
value for our team:
-no_return_value # function {0} does not always return a
value
+duplicate_formal # duplicate formal argument {0}
-equal_as_assign # test for equality (==) mistyped as
assignment (=)?{0}
+var_hides_arg# variable {0} hides argument
-redeclared_var # redeclaration of {0} {1}
-anon_no_return_value # anonymous function does not always
return a value
+missing_semicolon# missing semicolon
+meaningless_block# meaningless block; curly braces have
no impact
+comma_separated_stmts# multiple statements separated by
commas (use semicolons?)
+unreachable_code # unreachable code
-missing_break# missing break statement
-missing_break_for_last_case # missing break statement for last case
in switch
-comparison_type_conv # comparisons against null, 0, true,
false, or an empty string allowing implicit type conversion (use ===
or !==)
-inc_dec_within_stmt # increment (++) and decrement (--)
operators used as part of greater statement
+useless_void # use of the void type may be
unnecessary (void is always undefined)
+multiple_plus_minus # unknown order of operations for
successive plus (e.g. x+++y) or minus (e.g. x---y) signs
+use_of_label # use of label
-block_without_braces # block statement without curly braces
-leading_decimal_point# leading decimal point may indicate a
number or an object member
+trailing_decimal_point # trailing decimal point may indicate a
number or an object member
+octal_number # leading zeros make an octal number
+nested_comment # nested comment
-misplaced_regex # regular expressions should be preceded
by a left parenthesis, assignment, colon, or comma
-ambiguous_newline# unexpected end of line; it is
ambiguous whether these lines are part of the same statement
-empty_statement # empty statement or extra semicolon
-missing_option_explicit # the option explicit control comment
is missing
+partial_option_explicit # the option explicit control comment,
if used, must be in the first script tag
+dup_option_explicit # duplicate option explicit control
comment
+useless_assign # useless assignment
-ambiguous_nested_stmt# block statements containing block
statements should use curly braces to resolve ambiguity
+ambiguous_else_stmt # the else statement could be matched
with one of multiple if statements (use curly braces to indicate
intent)
-missing_default_case # missing default case in switch
statement
+duplicate_case_in_switch # duplicate case in switch statements
+default_not_at_end # the default case is not at the end of
the switch statement
+legacy_cc_not_understood # couldn't understand control comment
using /*...@keyword@*/ syntax
+jsl_cc_not_understood# couldn't understand control comment
using /*jsl:keyword*/ syntax
+useless_comparison # useless comparison; comparing
identical expressions
+with_statement # with statement hides undeclared
variables; use temporary variable instead
+trailing_comma_in_array # extra comma is not recommended in
array initializers
+assign_to_function_call # assignment to a function call
-parseint_missing_radix # parseInt missing radix parameter
--~--~-~--~~~---~--~~
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: Thoughts on Namespacing Native APIs
On Mar 24, 3:32 pm, Tobie Langel tobie.lan...@gmail.com wrote: Unfortunately, a number of environments do not support eval and decompiling function isn't part of any specification to date (nor planned in the near future). Best, Tobie Hey Tobie, those objections are well and good, but they can be addressed (see below). I was hoping for feedback at a bit higher level, on the overall idea. For example, does spinning off the native APIs into a separate library make sense? Is there merit to the resulting APIs (e.g. Does qip.String.endsWith(aString, substring) work for you?) What happens to the code if the APIs are made optional? ... that sort of thing. As for your specific comments... By decompiling I assume you mean Function#toString()? It may not be spec'ed, but that horse has already left the barn. Prototype (both stable and trunk) breaks on any platform where it's not supported - see Function#argumentNames(). As for eval(), that was simply a convenience to keep the sample code compact, readable. Removing that dependency is trivial - we need only do a bit more parsing of the function source, and use new Function() instead. --~--~-~--~~~---~--~~ 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] Add JavaScript Lint to build process?
Would it be worth doing some sort of javascript lint'ing as part of the 'dist' or 'test' tasks? ... or as part of whatever the final release processis? When I run http://www.javascriptlint.com against 1.6.0.3 or trunk, even using a fairly conservative config, I see a healthy dose of warnings (included below). In addition to dozens of 'missing semicolon' warnings, I also see stuff like this (on latest trunk dist): prototype.js|450| lint warning: multiple statements separated by commas (use semicolons?) prototype.js|2206| lint warning: multiple statements separated by commas (use semicolons?) prototype.js|2745| lint warning: the else statement could be matched with one of multiple if statements (use curly braces to indicate intent) prototype.js|3269| lint warning: multiple statements separated by commas (use semicolons?) prototype.js|3577| warning: variable nodes hides argument prototype.js|3932| lint warning: multiple statements separated by commas (use semicolons?) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
