[Prototype-core] Why have the examples been stripped out of the documentation?
Hi all, As some of you know, I'm running through all of our old docs and merging them into the PDoc comments in the source, and I've run into a really common theme: Where methods are already documented in the source, it's usually a copy of the original documentation with any examples left out. Why? (Brief) examples are a good thing in documentation! I'm restoring most of them, adjusting some to be a little more clear, but somebody tell me if there's some strong reason for stripping them out. -- 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: Array#intersect and Array#without inconsistency
Re: Array.uniq and Array.include and '==': There's a bug in the existing Array.uniq where [false, 0].uniq() returns [false]. I would prefer '===' for Array.include. See: http://prototype.lighthouseapp.com/projects/8886/tickets/786-optimize-arrayuniq-to-return-in-on-time --~--~-~--~~~---~--~~ 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] String.toObject and Object.toString
String.evalJSON is tightly coupled to the implementation of the method
itself, and where the implementation itself is soon likely to change
to be a wrapper for JSON.parse. We don't have methods such as
Number.toJavaScriptStringNotation etc. we have Number.toString.
String.evalJSON seems a bit too self-aware. Perhaps we could improve
the method name?
What about extracting the 'O' of JSON and just using that: i.e.
String.toObject?
The same applies to Object.toJSON. What is JSON? A string
representation of an object. What about Object.toString? But
Object.toString exists already of course. I propose we override it.
This may sound horrendous (given Kangax's use of
Object.prototype.toString in Object.isArray) but perhaps it makes more
sense for Object.toString to return a JSON representation of an Object
than the current opaque string. Same for Array.toString etc.
Object.isArray can get access to Object.prototype.toString in its
closure before Object.toString is overrided. It would be great to be
able to do: ({name: Prototype}).toString() and '{name:
Prototype}'.toObject().
--~--~-~--~~~---~--~~
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
TJ...
I once woke up from a nap in the middle of a saturday and solved a silly
issue i was having with event bubbling/propagation... I had seen the
solution in code as the last thing before I woke up. I tried it... and it
worked. The point: never feel bad about waking up to code on the brain :)
Rick
On Sun, Sep 6, 2009 at 5:38 AM, T.J. Crowder t...@crowdersoftware.com wrote:
I think you need this.nifty.$super.call(this, foo);
You don't, although that also works.
Ack! Sorry, too early in the morning, hadn't had enough coffee.
That does *not* work, because you always refer to the bottommost
subclass's nifty (this.nifty is always the bottommost function), so
you end up endlessly recursing. Wow that's an easy trap to fall into.
No, it's either use the function's name unadorned, or use
arguments.callee and pay the performance penalty. Personally, I
prefer using the function's name. :-)
-- T.J. :-)
On Sep 6, 8:48 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Allen,
I think you need this.nifty.$super.call(this, foo);
You don't, although that also works. A named function's name is in
scope within the function:
function foo(bar) {
alert(typeof foo); // Alerts function
}
However, I was thinking about anonymous functions this morning while
waking up (pathetic, isn't it?) and realized that even if you don't
use a named function, you can avoid arguments.callee with exactly the
form you describe: this.nifty.$super.call(this, foo); I don't like
the repetition of this, but if you don't have time to switch
everything over to named functions (I'm thinking of retrofitting
efforts), it's a reasonable first step, and I assume (haven't tested
it yet) still gets speed gains over arguments.callee.
Will be posting a sample implementation (it's wonderfully simple, but
there are a couple of edge cases around dynamic updates of classes)
and tests ASAP, but I want to get some of the Prototype documentation
issues sorted out first (transferring the old doc to the new format
and updating), since that's more urgent.
-- T.J. :-)
On Sep 5, 2:46 pm, Allen Madsen bla...@gmail.com wrote:
var Thingy = Class.create({
nifty: function nifty(foo, bar) {
nifty.$super.call(this, foo);
}
});
It just ignores the function name and complains that 'nifty' is not
defined. This works:
I think you need this.nifty.$super.call(this, foo);
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: A more efficient $super for Prototype 2
TJ,
I guess I don't understand why it wouldn't work. I'll illustrate how I
understand it and you correct me where I'm wrong.
var A = Class.create({
nifty: function(){}
});
var B = Class.create(A, {
nifty: function(){
this.nifty.$super(); // refers to A.nifty()
//this.nifty(); //would cause recursion
}
});
Also, if what I'm thinking is correct, there are some interesting side
effects that weren't possible before. Such as:
var C = Class.create(B, {
nifty: function(){
this.nifty.$super.$super(); //refers to A.nifty() instead of B.nifty()
},
crappy: function(){
this.nifty.$super(); //calls super of another function
}
});
Allen Madsen
http://www.allenmadsen.com
On Sun, Sep 6, 2009 at 5:38 AM, T.J. Crowder t...@crowdersoftware.com wrote:
I think you need this.nifty.$super.call(this, foo);
You don't, although that also works.
Ack! Sorry, too early in the morning, hadn't had enough coffee.
That does *not* work, because you always refer to the bottommost
subclass's nifty (this.nifty is always the bottommost function), so
you end up endlessly recursing. Wow that's an easy trap to fall into.
No, it's either use the function's name unadorned, or use
arguments.callee and pay the performance penalty. Personally, I
prefer using the function's name. :-)
-- T.J. :-)
On Sep 6, 8:48 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Allen,
I think you need this.nifty.$super.call(this, foo);
You don't, although that also works. A named function's name is in
scope within the function:
function foo(bar) {
alert(typeof foo); // Alerts function
}
However, I was thinking about anonymous functions this morning while
waking up (pathetic, isn't it?) and realized that even if you don't
use a named function, you can avoid arguments.callee with exactly the
form you describe: this.nifty.$super.call(this, foo); I don't like
the repetition of this, but if you don't have time to switch
everything over to named functions (I'm thinking of retrofitting
efforts), it's a reasonable first step, and I assume (haven't tested
it yet) still gets speed gains over arguments.callee.
Will be posting a sample implementation (it's wonderfully simple, but
there are a couple of edge cases around dynamic updates of classes)
and tests ASAP, but I want to get some of the Prototype documentation
issues sorted out first (transferring the old doc to the new format
and updating), since that's more urgent.
-- T.J. :-)
On Sep 5, 2:46 pm, Allen Madsen bla...@gmail.com wrote:
var Thingy = Class.create({
nifty: function nifty(foo, bar) {
nifty.$super.call(this, foo);
}
});
It just ignores the function name and complains that 'nifty' is not
defined. This works:
I think you need this.nifty.$super.call(this, foo);
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
-~--~~~~--~~--~--~---
