Hi Robert,
That's a very interesting use case, thanks for that. I can certainly
see the utility of that, and in fact as I was writing all of this up
for my (pathetic little) blog I was getting increasingly uncomfortable
with the mixin issue.
If it's important for mixins to participate in hierar
On Sep 9, 7:29 am, "T.J. Crowder" wrote:
> Hi all,
>
> I thought of a wrinkle today: Mixins. This new mechanism modifies
> function instances if they override base class functions (it leaves
> them alone if they don't). So if you mix in something that has a
> function with the same name as a
Hi Allen,
Thanks. I agree, it's a very edgy edge case. :-)
> (wouldn't the current let you do this as well?)
Actually, it works in the current implementation, because if a mixin
function uses $super (which again is a bit odd), addMethods wraps it
up in a closure and never modifies the actual f
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 col
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
Hi all,
I thought of a wrinkle today: Mixins. This new mechanism modifies
function instances if they override base class functions (it leaves
them alone if they don't). So if you mix in something that has a
function with the same name as a parent class's function, we will set
a $super property
On Wednesday 09 September 2009 09:02:28 Jim Higson wrote:
> > I see where you're coming from, but FWIW I'm with Allen on this one.
> > Also, there's no standard way to get the name of a function until
> > ECMAScript5 (which standardizes the truly outrageous idea that
> > function instances should
On Tuesday 08 September 2009 16:18:20 T.J. Crowder wrote:
> @Jim,
>
> > Ie, Class.create takes any number of objects of functions or functions.
> > If functions, the function name is used.
>
> I see where you're coming from, but FWIW I'm with Allen on this one.
> Also, there's no standard way to g
@kangax, @tobie:
*sigh* The "name" property _was_ in the November '08 draft (sect.
15.3.5.4), I didn't realize they'd taken it out again, but apparently
they have, it's not in the April candidate spec (which has now
replaced the November draft in my reference folder).
@kangax:
> Last time I ch
On Tue, Sep 8, 2009 at 1:21 PM, T.J. Crowder 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, ar
> 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
On Sep 8, 11:11 am, Robert Kieffer wrote:
> 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 w
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
On Sep 8, 12:25 pm, "T.J. Crowder" wrote:
> Hi Allen,
>
> > After the construction of klass, you
> > could set a property so that it is identifiable.
>
> Doh! Of course, since we only allow deriving from classes created via
> Class.create. I wouldn't go with "name", though, since the
> ECMAScri
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)"
Robert,
I use super heavily in many of my applications and it isn't something
trivial to just add it on to prototype's class. I would be very
against it. As long as it is clearly documented then I don't see a
problem. I spend a good deal of time in #prototype and a majority of
the questions are a
On Sep 8, 8:44 am, "T.J. Crowder" 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 go
Hi Allen,
> After the construction of klass, you
> could set a property so that it is identifiable.
Doh! Of course, since we only allow deriving from classes created via
Class.create. I wouldn't go with "name", though, since the
ECMAScript5 spec actually defines "name" for functions. But
_cre
@TJ
I don't think it would be hard to tell the difference between a base
class construct and a function. You would just need some extra work in
construction of the base class. After the construction of klass, you
could set a property so that it is identifiable. For example:
function klass() {
Hi Robert,
Thanks for your thoughts on this.
> The requirement for named function expressions (NFEs) puts a serious
> crimp in developers coding style.
This mechanism does _not_ require NFEs. You can use anonymous
functions and call the super via arguments.callee if you like, and
still get big
@Allen,
> For your two suggested additions. I don't think I have ever had a use for
> either.
Thanks.
> One thing I would like to suggest though is that Class.create
> take an object or a function as an argument.
I _really_ like that idea, not least because it seems to me that by
reducing the
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 performanc
On Tuesday 08 September 2009 15:27:49 Allen Madsen wrote:
> Jim,
>
> I like your suggestion, except that there would be no way to create private
> variables and functions that could be used in more than one function. For
> example, with my suggested method I could do:
I suppose if you wanted both
Jim,
I like your suggestion, except that there would be no way to create private
variables and functions that could be used in more than one function. For
example, with my suggested method I could do:
Var A = Class.create(function(){
var privateVar = 0;
function privateFunction(){}
functio
On Tuesday 08 September 2009 14:56:06 Allen Madsen wrote:
> Hey TJ,
> For your two suggested additions. I don't think I have ever had a use for
> either. One thing I would like to suggest though is that Class.create take
> an object or a function as an argument. Since it is essentially a
> require
Oh, also, you may want to throw something into update helper about your new
method of getting super.
Allen Madsen
http://www.allenmadsen.com
On Tue, Sep 8, 2009 at 9:56 AM, Allen Madsen wrote:
> Hey TJ,
> For your two suggested additions. I don't think I have ever had a use for
> either. One th
Hey TJ,
For your two suggested additions. I don't think I have ever had a use for
either. One thing I would like to suggest though is that Class.create take
an object or a function as an argument. Since it is essentially a
requirement now to use a function to create named functions that can call
su
Hi all,
Just validated Radoslav's steps, and they work (provided you add the
submodules stuff), although it takes a while because you have to
retrieve everything (including submodules). Instead, it's really easy
and very fast to just add my repo as a remote within your existing
local prototype r
Hi Radoslav,
> There must be a smarter way with this, but I'm still a git newbie.
Hey, you're better at it than I am. :-)
> Bw, this worked fine, since $super is attached to function
It only worked because you only had a Parent < Child hierarchy. As
soon as you throw a third level into it (the
"git pull origin supercalls" is needed for getting not only the master
branch. So we have:
git clone git://github.com/tjcrowder/prototype.git
cd prototype
git branch supercalls
git checkout supercalls
git pull origin supercalls
rake dist
There must be a smarter way with this, but I'm still a git
Hi Richard,
You want to use the "supercalls" branch; I suspect you used master.
This should do it:
git clone git://github.com/tjcrowder/prototype.git
git checkout supercalls
rake dist
In any case, I see you got there in the end.
> A bit short Half a million loops and it's a bit short
2009/9/8 T.J. Crowder :
>
> Hi,
>
>> It really looks nicer :)
>
> Thanks!
>
>> I haven't run it but I guest it is possible to do
>>
>> this.method.$super.call(this, ...)
>
> No, you need to drop the "this." from the beginning of that. See my
> reply to Allen a couple up (or the PDoc comments here
Hi,
> It really looks nicer :)
Thanks!
> I haven't run it but I guest it is possible to do
>
> this.method.$super.call(this, ...)
No, you need to drop the "this." from the beginning of that. See my
reply to Allen a couple up (or the PDoc comments here[1]) for why.
> arguments.callee.$supper.
2009/9/8 T.J. Crowder :
>
> Hi all,
>
> I've taken a break from porting documentation from Mephisto into the
> source (zz) to do a first take on implementing the new
> supercalls! Here's the commit in a branch in my repo:[1]
>
> That commit includes the code, documentation, and unit tests. Th
It really looks nicer :)
I was generally using this.constructor ... and so on. But this is
better. I haven't run it but I guest it is possible to do
this.method.$super.call(this, ...)
arguments.callee.$supper.call(this, ...)
Witch is nice.
--~--~-~--~~~---~--~~
Y
Hi all,
I've taken a break from porting documentation from Mephisto into the
source (zz) to do a first take on implementing the new
supercalls! Here's the commit in a branch in my repo:[1]
That commit includes the code, documentation, and unit tests. The old
class unit tests are still there
Hi Jim,
> Perhaps I would do:
>
> var B = Class.create(A, {
> nifty: function(){
>
> var $super = this.nifty.$super.bind( this );
> // $super refers to A.nifty() bound to this
> $super();
> }
>
> });
>
> [1] Please correct if this is wrong!
You need to leave out the "this." a
On Tuesday 08 September 2009 03:57:13 Allen Madsen wrote:
> 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(){
Hi Allen,
> I guess I don't understand why it wouldn't work.
Yeah, it's...subtle. :-) It runs into what I call the "grandchild"
problem. Consider Parent < Child < GrandChild, all with #nifty
functions:
var Parent = Class.create((function() {
function nifty(spiffy)
{
return "P
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
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 :)
R
> > 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),
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
>
> >
> > 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.$supe
On Sep 4, 2:54 pm, "T.J. Crowder" wrote:
> Hi Juriy,
>
> Thanks for that. Yes, it was the function decompilation (and the on-
> the-fly bind) that made me look for another solution.
>
> I was unaware of the performance implication of arguments.callee, and
> *WOW* does it make a speed differenc
Hi Juriy,
Thanks for that. Yes, it was the function decompilation (and the on-
the-fly bind) that made me look for another solution.
I was unaware of the performance implication of arguments.callee, and
*WOW* does it make a speed difference (see below). The good thing is
that this solution doe
On Sep 4, 8:15 am, "T.J. Crowder" wrote:
> Hi all,
>
> I've come up with a new way of handling $super (which I can't imagine
> is unique, it's just new to me) which is markedly more efficient than
> our current $super on all of the browsers I've tried it on. I'm
> wondering whether we should con
Hi again folks,
This thread[1] about using Array.prototype.slice to copy arguments
made me wonder whether the speed improvements I found had more to do
with the fact my implementation of the new mechanism had its own copy-
the-args function (which is faster than using `slice` on most
browsers; se
@Allen & @Jim,
Gets my vote.
-- T.J. :-)
On Sep 4, 3:05 pm, Jim Higson wrote:
> On Friday 04 September 2009 14:09:32 T.J. Crowder wrote:
>
> > [...] I do _not_ mean that I
> > think "callSuper" is a great name; I don't and I expect suggestions
> > like yours to result in a better name. But so
On Friday 04 September 2009 14:09:32 T.J. Crowder wrote:
> [...] I do _not_ mean that I
> think "callSuper" is a great name; I don't and I expect suggestions
> like yours to result in a better name. But something unlikely to
> clash makes it simpler for people to do a global search-and-replace t
Hi,
I think the speed improvement definitely merits going into. I would suggest
the helper be called $super so when converting, the relationship is evident.
I have to admit that passing arguments in feels odd to me though.
Allen Madsen
http://www.allenmadsen.com
On Fri, Sep 4, 2009 at 9:09 AM, T
Hi Richard,
Thanks for that.
I like the terseness and clarity of this.base() although I'd have
concerns about that making it difficult for people to retrofit their
classes ("base" being a fairly common word). I do _not_ mean that I
think "callSuper" is a great name; I don't and I expect suggest
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 hav
53 matches
Mail list logo
