my bad, just noticed you do offer your own wrapper in the blog post cited.
There ya go.
.bind(this) is still not ugly
-1 if you were in any suggesting this get rolled into core.
+1 for you continuing to write wrappers when you want to extend/morph the
API.
On 2/7/08, Ryan Gahl <[EMAIL PROTECTE
Completely disagree. First of all, you don't need the parentheses in your
first example. You can simply do stuff like "function() {...}.bind(this)".
Secondly, in your conclusion you are assuming that you will always _need_ to
correct scope, when in fact you only need to do this if you want to use t
On Feb 8, 3:34 pm, "Ryan Gahl" <[EMAIL PROTECTED]> wrote:
> Completely disagree. First of all, you don't need the parentheses in your
> first example. You can simply do stuff like "function() {...}.bind(this)".
Actually if you run
window.hello = "ninja";
var MyClass = Class.create ({
te
> On this point I have to say, It is really hard to extend prototype,
> there should be a central registry Object.Extend writes to and I
> should not have to write 20 lines of code to change the behavior of
> each in all enumerables, it should be possible to do this in one line
> of code .
I gues
>
> Actually if you run
> window.hello = "ninja";
> var MyClass = Class.create ({
>test: function()
>{
> this.items = $A([1]);
> this.hello = "hello";
> this.items.each(function(i)
>{
>alert(this.hello);
>}).bind(this);
>}
> });
>
> you get
Keep in mind also... I'm just one vote. I can't tell you how many times I've
been outvoted here :)
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-9
>
> Last I checked, Object.extend doesn't check if a child is defined
> before redefining.
> So, that shouldn't be too difficult.
>
Sure, but unless I am missing something .. I have to call
Object.extend on Array.prototype, Hash.prototype, ObjectRange,
Ajax.Responders, Element.ClassNames.prototyp
Thanks for writing about this. I think it's an interesting idea, but
is almost certainly infeasible because we need to abide by an existing
API.
JavaScript 1.6 (Firefox >= 1.x) introduced some functional array
methods, including one called "map" which does the exact same thing as
our Enumerable#m
> So, Object.Extend as a side effect would would track the list of
> classes that were extended in a hash or something like it. And then
> we could revisit that later.
Interesting idea.
But, afaik, currently impossible within Javascript -- let alone
Prototype.
Within Object.extend's scope -- fu
For me, IMHO, of all these 3 I think the first is the nicest looking
this.items.each(this, function(i)
{
alert(this.hello);
});
this.items.each(function(i)
{
alert(this.hello);
}, this);
this.items.each(function(i)
{
alert(this.hello);
}.bind(this));
I just wrote this up in notepa
The more I think about this, the harder I find it to justify a change
in prototype core. No other functions in prototype allow for random
ordering of params, and it may cause confusion. On top of that
javascript 1.6 stuff Andrew pointed out makes things a bit more
complicated. So, even though I st
+1 kill thread, leave as .bind(this)
On Feb 9, 2008 10:07 PM, sambo99 <[EMAIL PROTECTED]> wrote:
>
> The more I think about this, the harder I find it to justify a change
> in prototype core. No other functions in prototype allow for random
> ordering of params, and it may cause confusion. On top
+1 for "dynamic" Mixins (or hierarchy aware Object.extend as you call
it )
Dean Edwards' Base2 already implements something similar afaik.
P.S. and let's leave the scope argument where it is right now - on the
right side : )
On Feb 9, 4:07 am, sambo99 <[EMAIL PROTECTED]> wrote:
> The more I t
On Feb 9, 2008 7:07 AM, sambo99 <[EMAIL PROTECTED]> wrote:
> On the other hand, I do think I am on to something with exploring
> implementation of a hierarchy aware Object.extend. At the bare minimum
> I think it may be worth exploring adding a function to Enumerable that
> allows you to extend it
> > Enumerable.addMethod(myFunction) that takes care of all the classes
> > that implement or extend it.
Hmmm. We have Class#addMethods() already which makes exactly what
you're talking about. Everything would be as simple as calling:
Enumerable.addMethods(my_hash_of_methods);
if Enumerable w
On Feb 11, 2008 3:16 AM, DK <[EMAIL PROTECTED]> wrote:
>
> if Enumerable was a class. But it isn't!
It's never going to be a class; it was supposed to be a module like in Ruby
language, which is then mixed in certain classes that define _each to get
enumerable goodness.
But with prototypal inhe
> > if Enumerable was a class. But it isn't!
>
> It's never going to be a class; it was supposed to be a module like in Ruby
> language, which is then mixed in certain classes that define _each to get
> enumerable goodness.
The Ruby analogy is not going very far anyway: If you change an
Enumerabl
On Feb 11, 2008 2:35 PM, aljoscha <[EMAIL PROTECTED]> wrote:
>
> Not so in the newer Hash implementation of prototype (starting with
> 1.5 something) - by manually copying all methods to the "inheriting"
> classes this runtime flexibility was lost, probably as a trade off
> for gaining an improved
18 matches
Mail list logo
