Patch welcomed.
On Oct 14, 10:45 pm, Andy E wrote:
> I recently discovered that several compatibility implementations of
> Object.keys() on the web will throw an error for DOM objects in
> Internet Explorer 8 and lower. This differs from the current browsers
> having a native implementation and
> I think it's not a option for Prototype. At this case, bound function
> could be evaluated with errors.
Hadn't thought about that. Thanks for pointing it out!
--
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send emai
> headerJSON for the status (data retrieved, errors, etc.) and
> responseJSON the the content (data, error messages, etc.) from the
> server side app.
Yes, headerJSON is particularly useful combined to HTML in the
response body.
--
You received this message because you are subscribed to the Goog
> It may be just a case of the code and the documentation not agreeing
> and no comments saying that the second parameter is deprecated.
Right on. I also wasn't aware it was documented for Responders. We
never marked it deprecated for ajax callbacks, as it never actually
was documented.
Best,
To
It's been deprecated in favor of Ajax.Response#headerJSON.
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
proto
Great idea.
Would you mind submitting a patch with tests?
Thanks,
Tobie
On May 25, 12:01 pm, Johan Arensman wrote:
> Hello everyone,
>
> I was just checking out some of my code to see if I could optimize it and I
> noticed that in event handlers the event.stop() method has to be
> called separ
Thanks for your suggestion.
This would be quite an undertaking… and falls completely out of the
scope of Prototype, so it's certainly something that won't make it's
way into Prototype Core.
Sorry for the bad news!
Best,
Tobie
--
You received this message because you are subscribed to the Goo
Hi, Rüdiger.
This is definitely planned for 2.0.
toxcct, you might want of have a look at a number of really exciting
server side JS frameworks (node.js, narwhal, ringo, etc.).
Best,
Tobie
--
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
Done.
On Apr 9, 6:33 am, gf3 wrote:
> BAM.
> Done:http://github.com/gf3/pdoc/commit/55f6628be7fc5f91b7602ced0fddd5617db...
>
> On Apr 8, 10:23 am, Tobie Langel wrote:
>
>
>
> > May I suggest someone fix this and send me a pull request?
>
> > Best,
>
&
> Oh for cryin' out loud, Tobie. There are roughly 50 wiki engines out
> there that make contributing a darn sight easier than using flippin'
> git. But:
Hosted, fully style-able wikis with an integrated blog engine, which
allow inclusion of static HTML pages (the generated API doc), and can
live
> > I think I can live with that.
>
> We'll have to disagree on that, then, and it's your project. For a
> project I was running, I would consider it a completely unacceptable
> barrier to non-code contribution.
I'd like the perfect solution as much as anybody, I just haven't
bumped into it yet.
> Thanks. Purely git? Not ruby (unless you also want to install Jekyll)?
Yup.
> Mind you, it seems to me even git is a barrier to casual helpers, if
> they don't already use it.
I think I can live with that.
--
You received this message because you are subscribed to the Google Groups
"Prototy
May I suggest someone fix this and send me a pull request?
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
proto
> I see. In that case, you have to ensure that old URLs are preserved. Once
> you're on GitHub, there will never be a chance to do 301 redirects.
Are you suggesting we move the new documentation elsewhere
(prototypejs.org/doc) for example and keep the old, 1.5 doc structure
on prototypejs.org/api
Git.
Jekyll is totally optional for regular content contribution.
Installing Jekyll is rather straightforward, though.
http://wiki.github.com/mojombo/jekyll/install
Best,
Tobie
On Apr 8, 3:12 pm, "T.J. Crowder" wrote:
> Hi folks,
>
> I think most on the list know that Tobie's trying to mov
> Enh, it's not going to take long, I'll go do that now.
Awesome.
I don't know if you're familiar with jekyll[1], but his sports built-
in templating and markdown/textile parsers.
Best,
Tobie
[1] http://jekyllrb.com/
--
You received this message because you are subscribed to the Google Grou
> How about we create a prototypejs GitHub user and have the site at:
> prototypejs.github.com?
We'll be using prototypejs.org directly. It's supported by Github.
--
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send em
Oh, the repo is here: http://github.com/sstephenson/prototype/tree/gh-pages
--
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
pr
You're help would be really welcomed, TJ.
We're moving to github pages as it makes contributing to the website
the same process as contributing code or documentation.
I've started the project already: porting the whole blog archives to
jekyllrb and disqus comments (preserving all past comments in
> Can we use JavaScript on Mephisto pages?
>
> -- T.J.
Yes, but we're moving away from 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,
> Urm... really? You can do 404's but not 301's?
I was suggesting crating a good 404 page. Not modifying the http
response code.
> 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
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,
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" wrote:
> > My coworkers still find old docs (http://prototypejs.org/ap
> Anyway, if it's just me, it doesn't matter (I mean, I know they're
> clickable now). If others have had the same reaction, it may be worth
> looking at the styling of those.
Agreed.
--
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post
The reason for this design choice was to avoid the following
altogether:
if (event.memo) {
foo = event.memo.foo;
}
and allow this instead:
foo = event.memo.foo;
There are memory costs involved with this design choice, but these can
easily be mitigated by passing in a value to
Here's a (not so brief) explanation on the recent changes and the
upcoming plans for our JSON API.
Our previous JSON implementation was based on Douglas Crockford's
original proposal in which primitives, Array and Object prototypes
each had their own toJSONString method. We mimicked that behaviour
Hi, James.
Thanks for popping in.
I'm working on a Sprockets-inspired CommonJS module implementation
targeted at browsers[1].
It's more of a POC right now than anything else, but with a bit of
polish, I can very well imagine it fitting the bill for most use-
cases.
In a nutshell all it does is
;d be interested in helping out with writing
the DocBook generator.
Best,
Tobie
On Jan 6, 3:13 pm, Richard Quadling wrote:
> 2010/1/6 Tobie Langel :
>
>
>
>
>
> > Erh... but the documentation IS the website.
>
> > And DocBook support is planned. Maybe
Erh... but the documentation IS the website.
And DocBook support is planned. Maybe you'd like to help with it?
Best,
Tobie
On Jan 6, 11:43 am, Richard Quadling wrote:
> 2010/1/5 Tobie Langel :
>
>
>
>
>
> > Yes.
>
> > Or you can use coderay instea
ichard Quadling wrote:
> 2010/1/5 Tobie Langel :
>
>
>
>
>
> > Hi Richard.
>
> > You'll have to use another syntax highlighter ATM or build the
> > documentation without syntax highlighting.
>
> > To do so, just modify the rake task like so:
Hi Richard.
You'll have to use another syntax highlighter ATM or build the
documentation without syntax highlighting.
To do so, just modify the rake task like so:
http://gist.github.com/266858
Hope this helps.
Best,
Tobie
(Also, a patch to make pygments work on windows would be absolutely
aw
OP should try:
new Ajax.Request('http://www.test.com/search.php', {
method: 'get',
onSuccess: function(){...},
parameters: {
search: 'bogotá'
},
onFailure: function(){...}
});
Best,
Tobie
--
You received this message because you are subscribed to t
Sorry you're having trouble.
This mailing list is reserved for development purposes. Please direct
assistance requests to http://groups.google.com/group/prototype-scriptaculous
Thank you.
Tobie
On Dec 16, 4:11 am, Wen wrote:
> Hi
> I was trying to use protoaculous1.8.3.min.js
> like I did befo
Doc related tickets have been moved to their own Lighthouse project:
https://prototype.lighthouseapp.com/projects/42103-prototype-documentation/overview
Best,
Tobie
On Dec 4, 8:49 pm, Mike Rumble wrote:
> These tickets seem to have been deleted from Lighthouse.
>
> Any reason for this? Was th
Hi, Bob.
Thanks for your post.
We'll be including fixes for native JSON in Prototype 1.7, a
prerelease of which is just around the corner.
I understand your frustration with this issue. It's on our top
priority list.
Best,
Tobie
--
You received this message because you are subscribed to the
We previously used different variants of that and moved away from it.
It's slow and full of inconsistencies across browsers.
On Nov 24, 1:37 am, disccomp wrote:
> How about this sweet little scripty I found[1], call it a textarea
> hack:
>
> function html_entity_decode(str) {
> var ta=document
Good point (and sorry if the tone of my earlier post came out wrong,
that wasn't my intention).
There's indeed a number of entities which are part of the HTL 4.01 spec
[1].
It's legitimate to want to be able to convert those, notably when
dealing with legacy or external content.
However, given t
Thanks for your input.
A correct character encoding should be all you really need to handle
such entities.
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
Hi, Andrew.
As previously mentioned, K is ambiguous, as it can mean both:
function K(arg) { return arg; }
or:
function K(arg) { return function() { return arg; }; }
depending on your reference (Tcl for the former, combinatory logic for
the latter).
My vote therefore goes for using Fu
For the record, the unit of time measurement in Ruby is seconds, which
explains the reason behind that choice for Prototype.
Given the backwards compatibility issues, and the benefits of using
seconds rather than milliseconds in most but edge cases, there's litte
chance of seeing that change.
Be
> 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
[OT] Robert, had you tried the update helper to help out with this
migration?
On Oct 12, 2:34 am, Robert Kieffer wrote:
> 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? Certainly not in the old API
> > docs:http://prototypejs.org/api/event/element.
>
> I thought I was going crazy.
Looks like we haven't communicated this too well so far.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to th
Event#element has been deprecated for the longest time. It's by no
means a new decision.
Best,
Tobie
On Oct 7, 8:05 pm, kangax wrote:
> On Oct 7, 12:34 pm, Tobie Langel wrote:
>
> > > Sorry, but I don't follow the logic. What stops us from using
>
> > >
> Sorry, but I don't follow the logic. What stops us from using
> `getElement` with optional selector?
That meant adding another method. We had chosen to avoid that.
(Remember Event#findElement already existed).
> Maybe it's just the way my brains
> are wired, but `findElement` for me is associ
Hi.
I really don't understand how polluting the document object with
otherwise useless elements is a better solution than using namespaces.
Here's a revamped version which implements basic namespacing:
http://gist.github.com/204012
As your namespacing needs are probably specific, I encourage yo
Hi again,
For the record, custom events need to be namespaced ('foo:changed',
not 'changed').
The way you handle namespacing is entirely up to you. It can be
instance based, class based or arbitrary.
It just needs to be provided by the class / instance itself, and the
Observable mixin has to ta
Jim, Ngan.
This is already possible with our current event system using the
`document` object as broker.
Please see a basic, untested implementation here:
http://gist.github.com/203193
If you ant to discuss this in more details, please do kindly start
another thread.
Thank you.
Tobie
--~--~-
Hi.
Please allow me to clarify the issue here.
Event#element was deprecated because of it's inconsistency with the
rest of our API (which systematically uses verbs for method names).
There were two options for renaming this method: 1) add an
Event#getElement method or 2) reuse the existing Elem
Hi all.
Can we please try to stay on topic.
This thread's topic is about renaming methods whose ruby counterparts
were suffixed with a question mark.
It would be very helpful to list all of the methods which fall in that
category so we have a better idea of the implications of such a
change.
F
Hi everyone.
There are various reasons to keep those methods around, some of which
are:
1) Follow the Principle Of Least Surprise (POLS) by exposing a similar
API across the whole platform,
2) simplify duck-typing, and
3) abstract implementation details (for example, Hash#isEmpty isn't as
trivia
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 ambiguo
> Sorry, I'm not following. How does prefixing a key avoid object
> creation? We can't inject stuff directly onto a hash instance. We
> still need an object for that.
Not necessarily. Though that might make some requests more expensive.
--~--~-~--~~~---~--~~
You
> Why not to patch Hash to use some prefix for keys?
That was my plan for 1.7, actually.
It fixes that issue and also avoids creating an extra, internal
object.
Good to see that we're on the same page, here.
Tobie
--~--~-~--~~~---~--~~
You received this message
Hi, Ngan.
Sorry you're having trouble.
This mailing list is reserved for development purposes. Please direct
assistance requests to http://groups.google.com/group/prototype-scriptaculous
Thank you.
Tobie
--~--~-~--~~~---~--~~
You received this message because yo
> T.J., could you point me to the exact section specifying `name` on
> Function objects? I don't remember seeing it in ES5.
That's because it's not part of that spec. If I remember correctly it
was discussed for Harmony.
Best,
Tobie
--~--~-~--~~~---~--~~
You rec
Allen, You can do this already pretty easily.
Just do:
Var A = Class.create(function(){
var privateVar = 0;
function privateFunction(){}
function nifty(){
privateFunction();
privateVar = 3;
}
return {nifty: nifty};
}());
Just note that in both cases, those private variables ar
Hi, Julian.
Thanks for your suggestions.
There's indeed an issue when using some of Enumerable's methods with
hashes.
This should be addressed in n upcoming version of Prototype.
the way to address this is simply to define those methods on Hash
itself and make sure they return a hash instance
> Tobie,
> Do you have any input on this?
Yes, I'm in favor of strict equality.
--~--~-~--~~~---~--~~
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@googlegroup
Hi, Joran.
Thank you for your suggestions.
Unfortunately, there's a number of reasons why they're not practical
and why they will not be implemented in the framework..
1. We have a strict policy of not shadowing standardized properties/
methods of native objects. We're busy right now cleaning u
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 w
Robert,
Could you kindly point me towards that patch.
I don't think it's the one kangax mentioned.
Thanks,
Tobie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send
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
We have a rewrite of function.js waiting to be included. It does
something even smarter thanks to a great idea by Broofa.
We'll add it in as soon as we've handled our pdoc and website issues.
Best,
Tobie
On Sep 4, 5:03 pm, "T.J. Crowder" wrote:
> Hi all,
>
> In the 1.6.1 source, we're grabbin
Yes, these are part of the plans.
On Aug 31, 11:58 am, Radoslav Stankov wrote:
> I really liked the Mootools solution, they have Element.get as an
> alias of $.
> I'm wondering if, it will be good idea for Prototype 2.0, Element to
> become something like Prototype.Element and only if user wants
A more elegant solution to this problem is to use a closure around the
library, avoid using free variables internally and define an numbers
of exports for external consumption.
Such changes are planned for Prototype 2.0.
Hopes this helps.
Best,
Tobie
--~--~-~--~~~--
> Unless $break is removed from Prototype altogether, I don't see how
> this is an issue.
That was the idea. I don't know how feasible it is for Hash, but it
certainly is for Array.
Best,
Tobie
--~--~-~--~~~---~--~~
You received this message because you are subsc
Please open a ticket with your issue.
Thank you.
Tobie
On Aug 27, 11:37 pm, Ngan wrote:
> Hi I came an issue with Firefox (works for Safari and IE8 correctly)
> RE: Event.observe(...) vs ___.observe(...). You'll need both of the
> files below.
>
> Notice that firefox only receives the fire wh
> *blech* to ES5's enumerable stuff not having $break or similar
> functionality. I've just read the forEach section of the draft spec
> from a while back, and I'm not seeing a discussion of exception
> handling. I haven't delved deep, though -- do you know offhand how
> exceptions in the callba
For the record, here's my initial email which I mistakenly sent
(twice!) to
T.J. instead of to the whole list:
---
Hi, TJ.
I thought about your suggestion some more (regarding escaping
asterisk-
prefixed property names).
It's feels very much too application specific to me.
Also, it couples th
Food for thought:
1. We would like to completely decouple native and host objects in the
LANG section for version 1.7.
`setTimeout` and `setInterval` are host objects...
2. We're planning strict ES 5 compliance of enumerables for 1.7. that
implies removing $break.
Best,
Tobie
On Aug 27, 5:29
Patch welcomed! ;-)
On Aug 25, 11:18 pm, Yaffle wrote:
> ???
--~--~-~--~~~---~--~~
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 unsubscri
Thanks!
Please kindly open a ticket for this issue here:https://
prototype.lighthouseapp.com/projects/8886-prototype/tickets/new
Best,
Tobie
On Jul 23, 1:47 am, Ilya Furman wrote:
> There is a bug with Element.readAttribute for IE. While trying to read
> dynamically set attribute method fails
Hi Bryant,
Thanks for your post.
I suspect you are mainly worried about license issues and possible
copyright infringements.
Since it's inception, five developers in total have had commit rights
to the Prototype repository, all of which are still actively
contributing to the project.
All patch
Nope. Using it in production in various apps without issues.
You might want to make a reduced failing testcase and submit it to the
Prototype mailing list[1].
Best,
Tobie
[1] http://groups.google.com/group/prototype-scriptaculous
On Jul 20, 8:25 pm, Luisgo wrote:
> Has anyone experienced Sta
That's a blocker and will be fixed before 1.6. final.
Best,
Tobie
On Jun 30, 5:52 pm, "Ryan Holliday (wrh2)"
wrote:
> I filed a bug on this issue with a suggested fix (https://
> prototype.lighthouseapp.com/projects/8886/tickets/648-ssl-error-on-ie6-
> with-161_rc2). I'm not sure what the sta
> How to stop it? arguments?
Stopping it is as easy as:
pe = foo.repeat();
pe.stop();
Passing arguments would require some simple currying:
Function.prototype.repeat = function(interval) {
var fn = this;
if (arguments.length > 1) {
// not testsed but you get the idea
fn = fn.curry.appl
ve said sounds like I'm in a bad mood, sorry about
> that! :D
>
> Rick
>
> On Wed, Jun 24, 2009 at 12:53 PM, Tobie Langel wrote:
>
>
>
>
>
> > Just to clarify the above: Prototype Core already contains a similar
> > functionality: PeriodicalExecuter.
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
You might also want to look at the already existing
PeriodicalExecuter.
Any implementation of a Function#repeat API should take this in
account.
On Jun 24, 2:55 pm, "joe t." wrote:
> Only suggestion i can think of is that your method strongly implies a
> requirement that "repetitionsPollFn.repe
The former, I believe. I would tend to think that these changes would
actually cause higher memory consumptions on one-paged applications
(handlers of removed DOM nodes cannot be garbage collected).
On Jun 23, 11:53 pm, Mike Rumble wrote:
> I was having a poke around under the hood of the latest
Hi Anthony,
This mailing list is reserved for development purposes.
Instead, please use: http://groups.google.com/group/prototype-scriptaculous
Thanks!
Tobie
On Jun 1, 11:33 pm, anthony wrote:
> I have got a working example, but now I need to add something, and I
> am not sure how to do it
ou
> mean by adequate API?
>
> I'll work on it, just need a little guidance.
>
> Thanks!
>
> On May 28, 12:10 am, Tobie Langel wrote:
>
> > Hi,
>
> > You'll need to store the handler so you can remove it too, and provide
> > an adequate API for th
Hi,
You'll need to store the handler so you can remove it too, and provide
an adequate API for this.
Best,
Tobie
On May 28, 7:49 am, Luisgo wrote:
> So... here's a first pass. I forked the project committed the changes
> to my fork and sent a pull request to sstephenson for review. In the
> m
For ref.: https://prototype.lighthouseapp.com/projects/8886/tickets/684
--~--~-~--~~~---~--~~
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
Hi David,
You'll need to open a ticket in LH and add your patch to it. Please
mark it as an enhancement.
Thank you!
Tobie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this gro
> I will do the unit test but I think I need RoR to do that, so it could
> take a couple of days because I did not know Rails.
You just need Ruby, which comes bundled with OS 10.5 or is available
as a one-click install for Windows.
The tests are then just run from the command line.
Regarding y
Have you tried running the unit tests in all browsers with your
changes?
On May 13, 12:32 pm, david wrote:
> The original setOpacity function just reset the opacity value in case
> the value is one. Which means that you use the class value (if
> exist) :
>
> setOpacity: function(element, value
The former is much faster. Hence it's use!
Best,
Tobie
On Apr 24, 11:39 pm, Yaffle wrote:
> function update(array, args) {
> var arrayLength = array.length, length = args.length;
> while (length--) array[arrayLength + length] = args[length];
> return array;
> }
>
> Array.protot
Oh! You're talking about JavaScript Lint, not JSLint... maybe we could
agree on a set of warnings and publish that on the website.
Best,
Tobie
On Mar 27, 1:06 pm, Robert Kieffer wrote:
> Please note that I didn't mean to imply that Prototype should adhere
> to every warning and suggestiong tha
Please feel free to submit a patch.
Just make sure that you understand what you are doing when you make
changes and do not blindly follow the suggestions made by the Lint
parser.
As they are usually incorrect and applying them directly completely
breaks the program.
Depending on how this patch
On Mar 25, 1:32 pm, Robert Kieffer 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
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
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Gr
I wouldn't do a per platform distinction. The list would just be awful
to maintain with all the mobile platforms coming up.
The reasons you're seeing issues with running the tests:
1) UNITTEST_JS doesn't currently support running tests in WebKit on
windows. That should be corrected in UNITTEST_J
Sure.
And that would warrant some documentation too.
The tests are generated from the js test files.
You'll need to run rake test for that.
Which in turn will prompt you to require unittest_js submodules.
Let me know how things go.
Best,
Tobie
On Mar 20, 10:39 am, "T.J. Crowder" wrote:
>
> Is there any evidence that NOT being strict is slower for a non-strict
> environment?
huh?
> Does missing a few {} or the odd ; in allowable places make the parser
> have more work to do?
That's implementation specific.
Best,
Tobie
--~--~-~--~~~---~--~~
You
> I wonder why Caja is taken in so much more consideration than a
> practice that always existed in the programming world.
There's two reasons to that:
1. I've been consulting for Google Caja team to make Prototype Caja-
compliant,
2. Valija[1], the language which was created by the Google Caja
Some of those have been fixed in my branch for Caja compliance.
On Mar 12, 11:10 pm, Robert Kieffer wrote:
> 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.javascr
> If I were in an environment where the JSON object and its methods were
> not available, would doing something like this:
>
> if (typeof JSON === "undefined") {
> JSON = {
> stringify : function (o) { return Object.toJSON(o); },
> parse : function (s) { return String(s).evalJ
A couple of thoughts about Function#bind:
- it's part of the ES 3.1 draft, so will be found in browsers natively
pretty soon, and
- it's been been completely rewritten for our next release, so the
overhead should be much lighter.
Regarding extensions of native prototypes in general, a lot of met
1 - 100 of 364 matches
Mail list logo
