Patch welcomed.
On Oct 14, 10:45 pm, Andy E andyearns...@gmail.com 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
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 email
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 Google
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
Great idea.
Would you mind submitting a patch with tests?
Thanks,
Tobie
On May 25, 12:01 pm, Johan Arensman johanm...@gmail.com 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
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.
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 on
Done.
On Apr 9, 6:33 am, gf3 giannichiappe...@gmail.com wrote:
BAM.
Done:http://github.com/gf3/pdoc/commit/55f6628be7fc5f91b7602ced0fddd5617db...
On Apr 8, 10:23 am, Tobie Langel tobie.lan...@gmail.com wrote:
May I suggest someone fix this and send me a pull request?
Best,
Tobie
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
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
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 email
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
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 t...@crowdersoftware.com wrote:
Hi folks,
I think most on the list know that
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
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
Prototype:
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, send
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
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,
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
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
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
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 rquadl...@googlemail.com wrote:
2010/1/5 Tobie Langel tobie.lan...@gmail.com:
Yes.
Or you can use coderay instead, but I
be interested in helping out with writing
the DocBook generator.
Best,
Tobie
On Jan 6, 3:13 pm, Richard Quadling rquadl...@googlemail.com wrote:
2010/1/6 Tobie Langel tobie.lan...@gmail.com:
Erh... but the documentation IS the website.
And DocBook support is planned. Maybe you'd like
rquadl...@googlemail.com wrote:
2010/1/5 Tobie Langel tobie.lan...@gmail.com:
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
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
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
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 wenchen@gmail.com wrote:
Hi
I was trying to use
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 discc...@gmail.com wrote:
How about this sweet little scripty I found[1], call it a textarea
hack:
function html_entity_decode(str) {
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
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
[OT] Robert, had you tried the update helper to help out with this
migration?
On Oct 12, 2:34 am, Robert Kieffer bro...@gmail.com 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
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
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.
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 the
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
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
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
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 kan...@gmail.com wrote:
On Oct 7, 12:34 pm, Tobie Langel tobie.lan...@gmail.com wrote:
Sorry, but I don't follow the logic. What stops us from using
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
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 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
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.
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
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
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
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
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
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
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 t...@crowdersoftware.com wrote:
Hi all,
In the 1.6.1
Yes, these are part of the plans.
On Aug 31, 11:58 am, Radoslav Stankov rstan...@gmail.com 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
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
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,
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
*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 callback
Patch welcomed! ;-)
On Aug 25, 11:18 pm, Yaffle vic99...@yandex.ru wrote:
???
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to
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
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 lgo...@gmail.com wrote:
Has anyone
That's a blocker and will be fixed before 1.6. final.
Best,
Tobie
On Jun 30, 5:52 pm, Ryan Holliday (wrh2) ryan.holli...@gmail.com
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
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 =
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. thooke...@gmail.com wrote:
Only suggestion i can think of is that your method strongly implies a
requirement that
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
On Wed, Jun 24, 2009 at 12:53 PM, Tobie Langel tobie.lan...@gmail.comwrote:
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
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 mike.rum...@gmail.com wrote:
I was having a poke around under
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 mrsmi...@gmail.com wrote:
I have got a working example, but now I need to add something, and I
am not
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 lgo...@gmail.com 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
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
Have you tried running the unit tests in all browsers with your
changes?
On May 13, 12:32 pm, david david.brill...@gmail.com 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:
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 bro...@gmail.com wrote:
Please note that I didn't mean to imply that Prototype should adhere
to every warning and
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
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
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
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
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 bro...@gmail.com 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
Hi Rob,
We're planning to shift to native JSON support in our 1.7 release.
Unfortunately, our implementation of JSON was based on Doug's initial
one[1], which used different semantics altogether.
It turns out that the steps we took back then to avoid naming
collisions (using the toJSON method
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
Well, I'm definitely all for avoiding overwriting native JavaScript 1.6+
Array stuff.
I know we lose $break functionality, but this is a price we have to pay for
vioaliting our core principle of never shadowing native methods.
+1
--~--~-~--~~~---~--~~
You
`hasValue` as a replacement to `present` or as a wrapper around
`getValue().empty()`?
The former. Element#present just sounds weird for SELECT elements,
imho. And hasValue seems consistent with the rest of the API (get|set|
has)Value.
In general, I'm not excited about adding another
method
HI Richard,
That's a documentation issue.
Expected output is a vanilla JS object, not a hash.
Mind filing a ticket in LH ?
Best,
Tobie
On Feb 17, 4:35 pm, Richard Quadling rquadl...@googlemail.com wrote:
Hello.
I'm having problems using the Hash.merge() method on a Form.serialize(true).
Turn's out TJ already filled one:
http://prototype.lighthouseapp.com:80/projects/8886/tickets/556
On Feb 17, 5:28 pm, Tobie Langel tobie.lan...@gmail.com wrote:
HI Richard,
That's a documentation issue.
Expected output is a vanilla JS object, not a hash.
Mind filing a ticket in LH
no problem.
Best,
Tobie
On Feb 17, 6:39 pm, Richard Quadling rquadl...@googlemail.com wrote:
2009/2/17 Tobie Langel tobie.lan...@gmail.com:
Oh... and please avoid cross-posting next time ;)
Best,
Tobie
Sorry about the cross posting. It started as an issue with serialize
Can you open a ticket for this?
Thanks,
Tobie
On Feb 16, 5:16 pm, kangax kan...@gmail.com wrote:
On Feb 16, 7:29 am, Yaffle vic99...@yandex.ru wrote:
Hello,
Why with JavaScript = 1.5, Array.prototype._each method doesn't use
a context object
like
i know that #writeAttribute
isn't 100% reliable, which was part of the reason why i was looking
for an alternative to it.
How so?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post
Hi Chad,
Tahnks for your message.
I just sent you an email.
Best,
Tobie
On Feb 4, 3:09 am, Chad Russell chad.russ...@gmail.com wrote:
Hey all, we're having some issues with the prototype library over here
at MySpace. We have OpenSocial apps that live on our profile/home
pages in an
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
Thanks for your understanding.
Tobie
On Jan 17, 5:12 pm, Colorblind dust_...@yahoo.com wrote:
Hy everyone,
I have
The proper syntax is Class.create. Not Class.extend nor new Class.
For more info, see:
http://prototypejs.org/api/class/create
and
http://prototypejs.org/learn/class-inheritance
Best,
Tobie
On Jan 11, 5:52 pm, Yanick yanick.roc...@gmail.com wrote:
The old Class.extend was replaced by :
Daniel, you can find more information on how to contribute here:
http://prototypejs.org/contribute
Diego, the this binding is fixed for IE, however, the currentTarget
property isn't.
I think both would be useful.
Best,
Tobie
On Jan 11, 5:01 pm, Diego Perini diego.per...@gmail.com wrote:
Hi Daniel,
Thanks for the suggestion.
It might be worthwhile to rethink the implementation.
Would you mind opening a ticket for this in LH and mark it as an
enhancement.
You can assign the ticket to me.
Best,
Tobie
On Jan 10, 5:12 pm, Varga-Háli Dániel vargada...@gmail.com wrote:
Hello
That's obviously not possible, for obvious backwards compatibility
issues.
Best,
Tobie
On Jan 9, 2:05 pm, evolutional t.ziegelbec...@gmail.com wrote:
another thing...
I recently used the Object.extend for the default options of a
class.
So I just thought would it not be simpler to use an
http://gist.github.com/44308
I'd probably suggest another method, though, rather than adding a flag
to Object.extend.
Best,
Tobie
On Jan 7, 3:45 pm, joe t. thooke...@gmail.com wrote:
How would the core feel about a safe version of Object.extend?
Object.extend = function(destination,
One of the downsides of the current $super-based implementations is
that it's ridiculously complicated to pass the whole set of arguments
to the parent's method (the equivalent of calling super without
passing any arguments in ruby):
var Child = Class.create(Parent, {
doStuff: function($super)
FWIW $super is *not* gone.
_I_ happen not to like it.
On Jan 5, 2:44 am, kangax kan...@gmail.com wrote:
On Jan 4, 7:12 pm, Tobie Langel tobie.lan...@gmail.com wrote:
[...]
On the other hand, you'd have to handle this like so with your
proposed implementation:
var Child = Class.create
, Tobie Langel a écrit :
Thanks Samuel for your work!
Paramount for integration in Prototype Master branch is adding comment
stripping to the protodoc.
Could someone look into that ?
Best,
Tobie
samuel.leb...@gmail.com wrote:
Hello everyone,
I've been working on porting
Why not use JSLoad directly ?
Best,
Tobie
On Nov 19, 12:41 pm, Yaffle [EMAIL PROTECTED] wrote:
hello
I can't find in prototype.js function, that can load javascript such
as jsload
http://code.google.com/p/jsload/downloads/list
It may be very useful.
How about add to prototype lite
Very old as in may 2008 ? http://json.org/json.js
;)
On Nov 19, 10:10 pm, Malte Ubl [EMAIL PROTECTED] wrote:
OK, I turned to reading the docs :)http://www.prototypejs.org/learn/json
Although, they refer to a very old version of Crockford's json lib
which no longer extends Object.prototype
1 - 100 of 229 matches
Mail list logo
