I'm jumping in to say that I'm adopting jQuery precisely because it
does not much around with the prototype definition of native
objects, otherwise, I would have stuck with Prototype.
Working with Prototype, I was running into incompatabilities with
the Google Maps API. Apparently, it was iterating through an
extended object, and encountering members that it didn't expect to
find.
It seems invasive to extend base objects in this way, and I'd think
that it would be simple enough to say that you want your object so
extended by requiring a copy or update.
var copy = $C(" hello-world ")
var enhanced = $E(" hello-world ")
alert(copy.truncate().camelCase())
Where $C is short for Copy and $E is short for Extend/Enhance.
$C for when you've been passed an object and don't want to change
it's behavior for the caller, it can be defined in terms of $E.
$E can be tricked out however you like for your application, or you
could assign it to something else.
Extending prototype creates a lot of surprises. You're going to find
yourself saying, yeah, that library isn't compatable with jQuery.
* Paul Bakaus <[EMAIL PROTECTED]> [2006-11-16 04:29]:
> Good opinions there in your emails, I have thought about adding prototypes
> to Strings and Arrays alot, and I also think it's more natural than using a
> namespace.
> And Jörn, you are true that bad practise should not be promoted/supported.
>
> If it can be achieved, it may be nice to have the best of both worlds. Use
> prototypes as default, and for users who'd really like the namespace
> solution, add a mapping option.
>
> Sadly I have very little time at the moment to redefine the code, it would
> be great to see implementations of you guys. If not, I will come back at it
> in a couple of days.
>
> 2006/11/16, Klaus Hartl <[EMAIL PROTECTED]>:
> >
> >Jörn Zaefferer schrieb:
> >>> I still think that using a namespace and providing a short cut like $A
> >>> is the best way to handle this, instead of extending the element or
> >>> prototype. I think we could even get chaining to work properly if we
> >>> really wanted too. We could also probably provide a way to extend the
> >>> prototype if users really wanted it.
> >>
> >> I'd really like to hear other's opinions about this topic. John? Mike?
> >Klaus? If you read this: Say something!
> >>
> >> I think jQuery is a lot about promoting best practice. Find the best
> >approach for a certain aspect and promote that approach, instead of
> >providing every way and as much flexibility as you can think of. The latter
> >used to happen a lot in the java enterprise enviroment and is pretty ugly.
> >>
> >> It's great to have to opportunity to discuss it here at expense :-)
> >
> >I've read once somewhere (was it Crockford?) that you "should not extend
> >a language with its own features". I'm not that strict and think as long
> >as we don't touch the object we're fine. Using for/in on an array is bad
> >style and yes, I don't think jQuery should take into acount other's bad
> >coding style. Making jQuery dummy safe would be an endless process, so -
> >agreed - better promote best practice and be helpful on the list if
> >questions appear.
> >
> >It seems to be a trend to use and if required port the new Array
> >functions of JavaScript 1.6. I like that if it's done wisely:
> >
> >if ( !Array.prototype.forEach ) {
> > // add sugar
> >}
> >
> >That won't overwrite existing implementations. That could also be done
> >for other additional functions. Although I already foresee the question:
> >"Why, your Array.whatever function does not work as described in the
> >documentation" on the list, if some other library uses the same name.
> >But at least for the 1.6 methods there should be no clash.
> >
> >Dustin Diaz did that already here:
> >http://www.dustindiaz.com/sugar-arrays/
> >
> >I like the prototype approach more than using a helper method like $A
> >etc. and/or the namespace approach, because to me it kind of feels more
> >natural using a method on the array object immediatly.
> >
> >If we don't go that route I'm for the namespace implementation, that
> >looks as the cleanest solution to me.
> >
> >$.array.whatever() is better readable to me than $A...
> >
> >
> >Hey, very clever to extend the objects itself! Does it make sense to
> >have chainability for these methods? I can't see how to use that at the
> >moment.
--
Alan Gutierrez - 504 717 1428 - [EMAIL PROTECTED] - http://blogometer.com/
Think New Orleans - http://thinknola.com/
_______________________________________________
jQuery mailing list
[email protected]
http://jquery.com/discuss/
