Hi guys,I recently had the wish for extended functions on arrays, hashs and objects like Prototype provides with extending the Array() object. I often used features like without() and truncate(). I am really thinking of rewriting/porting a lot of stuff for jQuery and call it "jQuery Methods", but I
* Jörn Zaefferer <[EMAIL PROTECTED]> [2006-11-22 03:17]:
> Alan Gutierrez schrieb:
> > Extending prototype creates a lot of surprises. You're going to find
> > yourself saying, yeah, that library isn't compatable with jQuery.
> >
> I don't quite get your point. Do you use for-in loops on Strings
I hope future versions of Javascript give us better ways to iterate.
for-in is what's really broken.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
This is pretty cool stuff. Not widely available yet, but it's in FF2.0.
http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7#Iterators
On 12/17/06, John Beppu <[EMAIL PROTECTED]> wrote:
> I hope future versions of Javascript give us better ways to iterate.
>
> for-in is what's really broken
That Mozilla design is terrible: people should *NOT* use exceptions for
flow control! Exceptions are designed to be exceptional and
expensive..
--Jacob
> This is pretty cool stuff. Not widely available yet, but it's in FF2.0.
>
> http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7#Iter
That was my gut reaction, but, I think that it's an example of
explicit use of a new Iterator interface, a way to make any object
work with for in .
But, I didn't read it that closely. It took 6-8 years to get to get
JavaScript and DOM stable enough for our current applications. I'm
not holding my
I think this is where namespacing comes into play. We don't really
want to conflict with other libraries again. I think the internal
stucture should be:
jQuery.array[method]
jQuery.string[method]
jQuery.number[method]
jQuery.date[method]
Then we can provide shortcuts (making sure we don't overwri
> I recently had the wish for extended functions on arrays, hashs and
> objects
> like Prototype provides with extending the Array() object. I often used
> features like without() and truncate(). I am really thinking of
> rewriting/porting a lot of stuff for jQuery and call it "jQuery Methods",
> b
Jörn,you're true about that, but there are many who actually do it this way, and I don't want to write a plugin for us geeks only :-)As I am trying out now, $A([1,2,3,4,5]).without(1) seems to work quite well. Even chaining does work then.
2006/11/15, "Jörn Zaefferer" <[EMAIL PROTECTED]>:
> I recen
On 11/15/06, Paul Bakaus <[EMAIL PROTECTED]> wrote:
> Even chaining does work then.
chaining... :)
--
Brandon Aaron
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
:Pby the way, there's a first version in the SVN, in plugins/methods ! Feel free to add something.2006/11/15, Brandon Aaron <[EMAIL PROTECTED]
>:On 11/15/06, Paul Bakaus <[EMAIL PROTECTED]
> wrote:> Even chaining does work then. chaining... :)--Brandon Aaron_
> by the way, there's a first version in the SVN, in plugins/methods ! Feel
> free to add something.
I took a look at your implementation: It looks like you are extending a String
or Array object instead of it's prototype.
Won't that cause the same problems when used with for-in loops?
--
Jörn
On 11/15/06, "Jörn Zaefferer" <[EMAIL PROTECTED]> wrote:
> Won't that cause the same problems when used with for-in loops?
Yes, but only on the object itself and for/in shouldn't be used for
arrays. I don't believe there should be a conflict.
___
jQuery
I propose we break these out into their own plugins. Have a
plugins/methods/strings, plugins/methods/arrays, etc.
--
Brandon Aaron
On 11/15/06, Paul Bakaus <[EMAIL PROTECTED]> wrote:
> :P
>
> by the way, there's a first version in the SVN, in plugins/methods ! Feel
> free to add something.
>
> 20
On 11/15/06, Brandon Aaron <[EMAIL PROTECTED]> wrote:
> I propose we break these out into their own plugins. Have a
> plugins/methods/strings, plugins/methods/arrays, etc.
I also propose that we check to make sure the $A, $S, etc are not
currently being used and if they are, archive it in _$A, _$S
> > Won't that cause the same problems when used with for-in loops?
>
> Yes, but only on the object itself and for/in shouldn't be used for
> arrays. I don't believe there should be a conflict.
My words for not using for-in. But if the problem can occur on the object
again, I don't really see th
> > I propose we break these out into their own plugins. Have a
> > plugins/methods/strings, plugins/methods/arrays, etc.
>
> I also propose that we check to make sure the $A, $S, etc are not
> currently being used and if they are, archive it in _$A, _$S, etc.
>
> if ( typeof $A != "undefined" )
This is an interesting topic and you make a good point. I suppose the
question is, are we going to use prototype or not? When I originally
suggested using namespaces I didn't mean to extend the object as well
as use a namespace. I personally don't think it is a good idea for a
library to 'pollute'
> 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 i
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
Hi all!
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 b
> 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 hav
> I recently had the wish for extended functions on arrays, hashs and
> objects
> like Prototype provides with extending the Array() object. I often used
> features like without() and truncate(). I am really thinking of
> rewriting/porting a lot of stuff for jQuery and call it "jQuery Methods",
> b
On 11/16/06, "Jörn Zaefferer" <[EMAIL PROTECTED]> wrote:
> > I recently had the wish for extended functions on arrays, hashs and
> > objects
> > like Prototype provides with extending the Array() object. I often used
> > features like without() and truncate(). I am really thinking of
> > rewriting/
> > Just commited string.js and array.js to the plugin repository. They are
> extending Array and String prototypes with functions, when they do not
> exist yet. Documentation and testsuite is in there, too.
> >
> > Source:
> > http://jquery.com/dev/svn/trunk/plugins/methods/array.js?format=txt
> >
> Just commited string.js and array.js to the plugin repository. They are
> extending Array and String prototypes with functions, when they do not exist
> yet. Documentation and testsuite is in there, too.
I'm more-than-fine with extending the Array and String prototypes from
a plugin. jQuery do
Good job!
Let's see what I can contribute in the future.
-Paul
2006/11/16, John Resig <[EMAIL PROTECTED]>:
> Just commited string.js and array.js to the plugin repository. They are
extending Array and String prototypes with functions, when they do not exist
yet. Documentation and testsuite is
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 iteratin
Alan Gutierrez schrieb:
> Extending prototype creates a lot of surprises. You're going to find
> yourself saying, yeah, that library isn't compatable with jQuery.
>
I don't quite get your point. Do you use for-in loops on Strings or
Arrays? If yes, the new methods plugins are not good for you,
Maybe the argument doesn't matter anymore with Dean's new revelation.
--
Brandon Aaron
On 11/22/06, Jörn Zaefferer <[EMAIL PROTECTED]> wrote:
> Alan Gutierrez schrieb:
> > Extending prototype creates a lot of surprises. You're going to find
> > yourself saying, yeah, that library isn't compatable
> Maybe the argument doesn't matter anymore with Dean's new revelation.
I don't think so. Subclassing Array still isn't the same as extending the Array
prototype. It allows to work with extended Arrays, but the creation is
different. You cant create an array via bracket-syntax ([1,2,3].)
--
Jör
>> Maybe the argument doesn't matter anymore with
>> Dean's new revelation.
>
> I don't think so. Subclassing Array still isn't the same as
> extending the Array prototype. It allows to work with
> extended Arrays, but the creation is different. You cant
> create an array via bracket-syntax ([1,2,3
32 matches
Mail list logo
