The Number.prototype.$family is an excellent reason, indeed. Didn't
catch my attention, oops! (I'll try to be more careful in the
future...)
No transition, here's the next question:
Why Object.extend('forEach', [...]) instead of
Object.implement('forEach', [...]). Or: why defining forEach as a
property of Object rather than in it's prototype? Is it because
everything is an object and we don't want other types to be "forEach-
able"?
On 8 fév, 01:02, Aaron Newton <[email protected]> wrote:
> One way to figure this out is to look for $family anywhere else in the
> source. As arian points out, Number is the only place where this value is
> anything other than a lambda for a string.
>
>
>
> On Mon, Feb 7, 2011 at 3:41 PM, Arian Stolwijk <[email protected]> wrote:
> > Good question!
>
> > I guess because Number.prototype.$family returns a value which depends if
> > it's NaN or Infinite or something. Not sure if there are other places off
> > the top of my head, but I guess that could be another reason.
>
> > On Tue, Feb 8, 2011 at 12:33 AM, Savageman <[email protected]> wrote:
>
> >> You bet I will! Thanks for the motivation. :-)
>
> >> Let my teaching continue (remember, one at a time!) with what may
> >> looks obvious but which isn't for me:
>
> >> Why is $family a Function rather than a String?
> >> I understand the function get this .protect() thing which prevents it
> >> to be overridden by implement() or extend() and the String doesn't
> >> benefits from the protection. But it's still possible to override the
> >> $family thing with something like Object.prototype.$family = whatever.
> >> Is it because it's much less probable (then much more "secure") to
> >> override the prototype rather than setting a property? I'm having
> >> difficulty to believe your work is based on probability, should I be
> >> worried? ^^
>
> >> On 7 fév, 20:07, Aaron Newton <[email protected]> wrote:
> >> > Arian beat me to these questions (and probably gave better answers than
> >> I
> >> > would have), but I wanted to reply to this:
>
> >> > Cool, thanks. It's very possible that the questions are more related
>
> >> > > to JavaScript itself rather than MooTools...
>
> >> > That's the point! If you read through the MooTools Core code, you will
> >> learn
> >> > MooTools, yes - inside and out! But more importantly you'll learn *
> >> > JavaScript*. You'll learn it at its most abstract and realize the power
> >> the
> >> > language offers. MooTools is awesome because *JavaScript* is awesome.
