[Prototype-core] Anyone with PDoc working who can test a trivial patch for me?
Hi folks, Just trying to do a bit of tidying on the source[1], and unfortunately I can't get PDoc working on my system and am a bit pressed for time right now. If you have PDoc working on your system, could you try running it against the patched files on the linked ticket and seeing if it works okay? Tobie's concerned about the parser's handling of blank lines. Shoot me a private email if you want me to just email you an archive of the files rather than mucking about with applying the patch to your local repo. [1] http://prototype.lighthouseapp.com/projects/8886-prototype/tickets/610 Thanks in advance, -- T.J. Crowder tj / crowder software / 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: 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] Mapping a function to multiple arrays
With JavaScript 1.6 we have the Array.map method to map a function to
each element in an array, and Prototype itself has invoke and pluck.
But what if you want to map a function to a set of parallel arrays,
where the elements in each array correspond to the arguments of the
function? It's a common higher-order function, though not implemented
in a lot of languages. I think it naturally fits in the Function
prototype. Here's a suggested implementation:
Object.extend(Function.prototype, {
map: function() {
if (!arguments.length) return null; // Nothin' in, nothin' out
var args = $A(arguments);
var __this = args.shift();
var maxLength = 0;
args.each(function(arr) {
maxLength = (maxLength = arr.length) ? maxLength : arr.length;
});
var results = new Array();
for (var i = 0; i maxLength; ++i) {
results[i] = this.apply(__this, args.pluck(i));
}
return results;
}
});
Note, it's not great for sparse arrays, and if such are provided as
arguments, the function mapped needs to be tolerant of undefined
inputs. But it would be pretty easy to wrap a function so as to
handle such inputs. Dealing well with very sparse arrays would slow
the typical case down too much to be worthwhile.
Any comments or suggestions for improvement?
Titi
--~--~-~--~~~---~--~~
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
Hi Robert, For background, you might (if you haven't already) want to check out these two threads from this group on this topic: This short one: http://groups.google.com/group/prototype-core/browse_thread/thread/d38f2123aa64eb0e/ac612b72cc060943 And this _rather_ more comprehensive one: http://groups.google.com/group/prototype-core/browse_thread/thread/16d0517ecc605a00/c9cfe041c1da19de FWIW, -- T.J. Crowder tj / crowder software / com On Mar 25, 12:32 pm, Robert Kieffer bro...@gmail.com wrote: 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] Re: Thoughts on Namespacing Native APIs
On Mar 25, 1:32 pm, Robert Kieffer bro...@gmail.com wrote:
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.
I'm working on a couple of things remotely related to this. More on
this asap. That said, native object extensions is there to stay: it's
one of Prototype's biggest appeal (for example, that's the main reason
Prototype was included in Palm Mojo Application Framework).
Furthermore, namespacing issues, both for the global object and native
objects' prototypes, can be handled by sandboxing third party code
with Caja--which we'll fully support in the near future--with added
security as a bonus.
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().
For one, I'm a strong partisan of modifying our Class API (see a dummy
implementation proposal here: http://gist.github.com/43064) to remove
dependency on function decompiling.
Secondly, some platforms actually return sufficient information for
Function#argumentNames to work, while not truly decompiling the
function. That's the case of Caja, for example:
(function(foo, bar) { alert(foo + ' ' + bar) }).toString();
// - function(foo, bar} { [cajoled code] }
Last but not least, your solution won't be able to handle context
properly (which, btw, is one of the reasons function decompilation
isn't specified in ES).
Try this in your original pastie, for example (a bit contrived, but
you get the point):
var clear = (function() {
var ZERO = 0;
function clear(_this) {
_this.length = ZERO;
return _this;
}
return clear;
})();
// ... do the magick eval tricks
[1, 2, 3].clear();
// - ReferenceError: ZERO is not defined
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.
Platforms which do not support eval obviously support neither new
Function, nor passing a string to setTimeout or setInterval, nor
dynamic script injection.
To summarize, if implementing this was trivial, I would have been done
a long time ago. Unfortunately, it's not!
Over the next few weeks, we'll be concentrating our efforts on
completing the documentation, releasing 1.6.1 and migrating to a
library-agnostic test harness which I'm currently busy working on.
The idea is to get the source code as clean and solid as possible for
Prototype 1.7 (Caja support) and 2.0 development. We can certainly
look at options to remove dependencies between different parts of
Prototype by then. (For example, I would love to see the ajax module
standalone).
Hope this clarifies my point.
Of course, if you're available to help out on our current issues,
you're more than welcomed to do so!
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?
I'm glad Robert brought up this subject. I asked about this on IRC a while back and the answer was that prototype was hand-crafted, is beautiful the way it is, and that modifying it to pass strict syntax checking would somehow make it slower... I agree that there is some beautiful code in prototype but that's not a good enough reason for not being able to use jslint to find real bugs. And this issue is especially painful when I'm passing a large file consisting of several concatenated scripts to jslint ... since many of them rely on prototype, and it's at the beginning, I cannot see results for my own scripts because jslint will stop after too many (harmless) errors in prototype. For now, I'm running the various scripts through jslint separately. My justification for cleaning up prototype's code is that in some places the craftiness exceeds utility, and that prototype's awesomeness will only increase if the source code also passes basic software quality tests. For example, a statement like var result = value1, value2; there's really no need to use the comma operator with an assignment. Only one of the values will be assigned, and it's better to move the side-effect code into a separate statement where it will be easier to read. There are volumes written about avoiding errors by not writing code like that in the first place. You either believe it or you don't, I guess. If the core developers aren't interested in anyone contributing strict fixes, does anyone have thoughts about maintaining a separate strict version of prototype? Either way I volunteer to make a first pass at it. --~--~-~--~~~---~--~~ 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?
Just had another thought -- it's possible to satisfy proponents of both strict coding and quick downloads. Given a strictly written program, it's possible to write a transformation to apply all the syntax shortcuts to it and produce an equivalent lean version with minimum whitespace and punctuation. So if this were the process, everyone would win. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
