I have looked a little more, and found some behavior that puzzles me.
Desespite the claim that jquery doesn't support namespaces,
$("[x:\\name]") or $('[x:\\name="value"]')
_does_ work to select nodes in the original dom.
however,
$(document).find("[x:\\name]")
does not.
I had assume that find() used the same code as the basic selector, so
what is causing this difference?
Also, if I use jquery to _construct_ a document fragment with a
namespaced attribute, then the $([attrib],fragment) selector fails to
find it.
So to summarize, namespaced attributes work if and only if they are
defined in the dom and found using $([attrib]) instead of $().find
([attrib]). Why is this?
Test code enclosed:
Test
http://jqueryjs.googlecode.com/files/
jquery-1.3.2.js">
Fragments for tests:
this was a namespaced in-DOM div
this was a safe in-DOM div
Testing $('[attrib]'):
Testing $("#id").find("[attrib]") etc:
var written=$('this
was a namespaced jquery-written fragment
this was a safe jquery-written fragment
');
var selectInSafe=$('[safe]');
var selectIn=$('[ex\\:method]');
var selectWrittenSafe=$('[safe]',writtenSafe);
var selectWritten=$('[ex\\:method]',written);
var findInSafe=$("#indom-safe").find('[safe]');
var findIn=$("#indom").find('[ex\\:method]');
var findWrittenSafe=writtenSafe.find('[safe]');
var findWritten=written.find('[ex\\:method]');
$("#select-exist")
.append(selectInSafe.clone())
.append(selectWrittenSafe.clone())
.append(selectIn.clone())
.append(selectWritten.clone());
$("#find-exist")
.append(findInSafe.clone())
.append(findWrittenSafe.clone())
.append(findIn.clone())
.append(findWritten.clone());
written.children().clone().appendTo("#fragments");
writtenSafe.children().clone().appendTo("#fragments");
On Aug 10, 11:15 am, David wrote:
> thanks; this is helpful.
>
> On Aug 10, 3:52 am, DBJDBJ wrote:
>
> > var $xml = $(" > x:name='n1'>No namespaces");
>
> > $xml.find("*[x:name=n1]").length < 1
> > /*
> > Syntax error, unrecognized expression: [x:name=n1]
> > */
> > $xml.find("*[x\\:name=n1]").length < 1
> > /*
> > true
> > */
> > $xml.find("*[name=n1]").length < 1
> > /*
> > true
> > */
> > Therefore :
> > 1. *Sizzle* does not support namespaces in selector syntax
> > 2. for node selectors namespaces will be ignored
> > 3. for attribute selectors namespaces are provoking error . silent or
> > not.
>
> > Please see this
> > too:http://groups.google.com/group/sizzlejs/browse_thread/thread/48ef4372...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
I agree. As said, it was an unfortunate blunder that will probably
remain for the forseeable future.
On the plus side, it's not terribly hard to work around, and if it's a
major problem you can overwrite the jQuery.fn.each function, or even
jQuery.each (it shouldn't be that big of a deal, though).
On Aug 11, 9:31 am, Daniel Friesen wrote:
> Event callback: function(eventObject) { this = domnode }// Because
> that's the way events have always worked
> each() callback: function(index, sameAsThis) { this = item/domnode } //
> Keeping the pattern
> map() callback: function(index, sameAsThis) { this = item/domnode } //
> Keeping the pattern
> filter() callback: function(index) { this = item/domnode } // sorta
> keeping the pattern
> vs.
> Event callback: function(eventObject) { this = domnode } // event
> callbacks MUST use this as domnode, otherwise you destroy the api it was
> based on
> each() callback: function(item, index?) { ... }
> map() callback: function(item, index?) { ... }
> filter() callback: function(item, index?) { ... }
>
> Whether you like it or not, jQuery is a library for working with the
> dom. Thus when created each/map/filter had nothing to do with the array
> methods that have only been put into browsers recently (yes, recently...
> you are comparing standards set by new features, with decisions that
> were made years ago; not the best comparison), they were created to give
> control over the jQuery object's list of dom nodes. Thus, since all the
> other apis which worked with dom nodes used `this` to refer to the dom
> node that same api was used when writing those methods.
> It's only a side effect that these methods happen to be usable on
> non-domlist arrays. Though frankly, imho that is abuse, these methods
> are not meant for that purpose, you can plainly see that in how $.fn.map
> differs from Array.prototype.map in how it folds arrays into the list
> rather than adding them as items.
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
Haha, you guys crack me up.
--John
On Tue, Aug 11, 2009 at 9:23 PM, Michael Geary wrote:
>
> Well! Maybe you *should* read a good book on JavaScript before you go
> making
> careless posts again.
>
> All we know about here is jQuery, but the guys on comp.lang.javascript said
> there's only one good JavaScript book.
>
> Definitive something or other. It shouldn't be too hard to track down.
>
> I hear it's pretty good, maybe you could learn something from it!
>
> -Mike
>
> > From: David Flanagan
> >
> > My carelessness, however, is not sufficient reason for you to
> > accuse me of posting without reading or thinking. This is a
> > -dev level mailing list. You must assume that all posters
> > here are well-read and thoughtful. Otherwise you sound paternalistic!
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
Well! Maybe you *should* read a good book on JavaScript before you go making
careless posts again.
All we know about here is jQuery, but the guys on comp.lang.javascript said
there's only one good JavaScript book.
Definitive something or other. It shouldn't be too hard to track down.
I hear it's pretty good, maybe you could learn something from it!
-Mike
> From: David Flanagan
>
> My carelessness, however, is not sufficient reason for you to
> accuse me of posting without reading or thinking. This is a
> -dev level mailing list. You must assume that all posters
> here are well-read and thoughtful. Otherwise you sound paternalistic!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
> for(var i = 0; i $C.fadeOut(
> verbTime,
> function(){$THAT.text(ARR[i]).fadeIn(verbTime);}
> );
> }
> }
That code has the same problem as the original, though. It is going to
queue up ARR.length-1 fadeOut operations that all have i==ARR.length
and fail. To get the code to work you need to create a closure
*within* the loop that captures the current loop value, which
jQuery.each does for you. Or am I missing something?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
I'm not seeing any functionality that can't already be done. It might
take off a few lines of code, but this doesn't really add anything
useful. If it allowed namespaces and the ability to use 'this' inside
the namespaces as you would in jQuery, then I, for one, would find it
very useful.
On Aug 12, 9:40 am, Andrea Giammarchi
wrote:
> that is why I already use Obejct.create in vice-versa only if not defined
> and when it will be standard the jQuery way will be simply this one:
>
> $.extends(Object.create(proto), props);
>
> the bedge callback was just an optimized suggestion over a snipped based on
> a dated proposal.
>
> Regards
>
> P.S. not sure if Object.create will support directly the extra argument, I
> have implemented it without classic toString and other failures
>
> On Wed, Aug 12, 2009 at 12:15 AM, Daniel Friesen
> wrote:
>
>
>
>
>
> > ES5 + .extend is not necessary for this simple chunk.
>
> > (function($){
> > if (!Object.create)
> > var F = function(){};
> > $.beget = function (proto, props) {
> > if(Object.create)
> > var o = Object.create(proto);
> > else {
> > F.prototype = proto;
> > var o = new F;
> > }
> > for ( var k in props )
> > o[k] = props[k];
> > return o;
> > };
> > })(jQuery);
>
> > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> > Andrea Giammarchi wrote:
> > > Dunno how many times that bedge has been optimized ;-)
>
> > > (function(){
> > > var F = function(){};
> > > jQuery.beget = function (proto, props) {
> > > F.prototype = proto;
> > > return props ? $.extend(new F, props) : new F;
> > > };
> > > })();
>
> > > Regards
>
> > > On Thu, Jul 30, 2009 at 3:48 PM, Már Örlygsson
> > > mailto:mar.orlygs...@gmail.com>> wrote:
>
> > > Hi.
> > > If it hasn't been already considered (and rejected), I'd like to
> > float
> > > the idea of adding support for prototypal inheritance into the jQuery
> > > core library.
>
> > > Something like this...
>
> > > jQuery.beget = function (proto, props) {
> > > var F = function () {};
> > > F.prototype = proto;
> > > var instance = new F();
> > > return props ? $.extend(instance, props) : instance;
> > > };
>
> > > ...becomes immensely powerful - especially during plugin development
> > > when allowing users to extend/override default options
>
> > > options = $.beget($.myplugin.defaults, options || {});
>
> > > ...and in various other common use cases - including $.fn.data()
> > > assignments, etc.
>
> > > I for one would love to see this feature added.
>
> > > --
> > > Már
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
You're right: the constructor property doesn't work property even in an
unoptimized beget() function. I retract my previous message. I sent it
without testing my assertion. That was careless, and I apologize.
My carelessness, however, is not sufficient reason for you to accuse me
of posting without reading or thinking. This is a -dev level mailing
list. You must assume that all posters here are well-read and
thoughtful. Otherwise you sound paternalistic!
David Flanagan
Andrea Giammarchi wrote:
> David, read carefully, think, and try again
>
> On Tue, Aug 11, 2009 at 11:16 PM, David Flanagan
> mailto:da...@davidflanagan.com>> wrote:
>
>
> Of course, if you optimize it in this way to share a single constructor
> function, you can't find the prototype of an object created with beget()
> with o.constructor.prototype. Not sure how important that is, but there
> is a downside to the optimization.
>
>David
>
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
that is why I already use Obejct.create in vice-versa only if not defined
and when it will be standard the jQuery way will be simply this one:
$.extends(Object.create(proto), props);
the bedge callback was just an optimized suggestion over a snipped based on
a dated proposal.
Regards
P.S. not sure if Object.create will support directly the extra argument, I
have implemented it without classic toString and other failures
On Wed, Aug 12, 2009 at 12:15 AM, Daniel Friesen
wrote:
>
> ES5 + .extend is not necessary for this simple chunk.
>
> (function($){
>if (!Object.create)
>var F = function(){};
>$.beget = function (proto, props) {
>if(Object.create)
>var o = Object.create(proto);
>else {
>F.prototype = proto;
>var o = new F;
>}
>for ( var k in props )
>o[k] = props[k];
>return o;
>};
> })(jQuery);
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> Andrea Giammarchi wrote:
> > Dunno how many times that bedge has been optimized ;-)
> >
> > (function(){
> > var F = function(){};
> > jQuery.beget = function (proto, props) {
> > F.prototype = proto;
> > return props ? $.extend(new F, props) : new F;
> > };
> > })();
> >
> > Regards
> >
> >
> > On Thu, Jul 30, 2009 at 3:48 PM, Már Örlygsson
> > mailto:mar.orlygs...@gmail.com>> wrote:
> >
> >
> > Hi.
> > If it hasn't been already considered (and rejected), I'd like to
> float
> > the idea of adding support for prototypal inheritance into the jQuery
> > core library.
> >
> > Something like this...
> >
> >jQuery.beget = function (proto, props) {
> >var F = function () {};
> >F.prototype = proto;
> >var instance = new F();
> >return props ? $.extend(instance, props) : instance;
> > };
> >
> > ...becomes immensely powerful - especially during plugin development
> > when allowing users to extend/override default options
> >
> >options = $.beget($.myplugin.defaults, options || {});
> >
> > ...and in various other common use cases - including $.fn.data()
> > assignments, etc.
> >
> >
> > I for one would love to see this feature added.
> >
> > --
> > Már
> >
> >
> >
> > >
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
ES5 + .extend is not necessary for this simple chunk.
(function($){
if (!Object.create)
var F = function(){};
$.beget = function (proto, props) {
if(Object.create)
var o = Object.create(proto);
else {
F.prototype = proto;
var o = new F;
}
for ( var k in props )
o[k] = props[k];
return o;
};
})(jQuery);
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Andrea Giammarchi wrote:
> Dunno how many times that bedge has been optimized ;-)
>
> (function(){
> var F = function(){};
> jQuery.beget = function (proto, props) {
> F.prototype = proto;
> return props ? $.extend(new F, props) : new F;
> };
> })();
>
> Regards
>
>
> On Thu, Jul 30, 2009 at 3:48 PM, Már Örlygsson
> mailto:mar.orlygs...@gmail.com>> wrote:
>
>
> Hi.
> If it hasn't been already considered (and rejected), I'd like to float
> the idea of adding support for prototypal inheritance into the jQuery
> core library.
>
> Something like this...
>
>jQuery.beget = function (proto, props) {
>var F = function () {};
>F.prototype = proto;
>var instance = new F();
>return props ? $.extend(instance, props) : instance;
> };
>
> ...becomes immensely powerful - especially during plugin development
> when allowing users to extend/override default options
>
>options = $.beget($.myplugin.defaults, options || {});
>
> ...and in various other common use cases - including $.fn.data()
> assignments, etc.
>
>
> I for one would love to see this feature added.
>
> --
> Már
>
>
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
Umm, dunno if you guys read my posts above, but you might want to.
On Aug 12, 8:51 am, Andrea Giammarchi
wrote:
> Or better, demonstrate that the constructor will not simply be the one
> associated with the proto object in my function or try to retrieve that
> function in whatever way you want.
>
> After that, have a look here:http://www.3site.eu/doc/
>
> Regards
>
> On Tue, Aug 11, 2009 at 11:50 PM, Andrea Giammarchi <
>
>
>
> andrea.giammar...@gmail.com> wrote:
> > David, read carefully, think, and try again
>
> > On Tue, Aug 11, 2009 at 11:16 PM, David Flanagan
> > wrote:
>
> >> Of course, if you optimize it in this way to share a single constructor
> >> function, you can't find the prototype of an object created with beget()
> >> with o.constructor.prototype. Not sure how important that is, but there
> >> is a downside to the optimization.
>
> >> David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
Or better, demonstrate that the constructor will not simply be the one
associated with the proto object in my function or try to retrieve that
function in whatever way you want.
After that, have a look here:
http://www.3site.eu/doc/
Regards
On Tue, Aug 11, 2009 at 11:50 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> David, read carefully, think, and try again
>
>
> On Tue, Aug 11, 2009 at 11:16 PM, David Flanagan
> wrote:
>
>>
>> Of course, if you optimize it in this way to share a single constructor
>> function, you can't find the prototype of an object created with beget()
>> with o.constructor.prototype. Not sure how important that is, but there
>> is a downside to the optimization.
>>
>>David
>>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
David, read carefully, think, and try again
On Tue, Aug 11, 2009 at 11:16 PM, David Flanagan wrote:
>
> Of course, if you optimize it in this way to share a single constructor
> function, you can't find the prototype of an object created with beget()
> with o.constructor.prototype. Not sure how important that is, but there
> is a downside to the optimization.
>
>David
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
Of course, if you optimize it in this way to share a single constructor
function, you can't find the prototype of an object created with beget()
with o.constructor.prototype. Not sure how important that is, but there
is a downside to the optimization.
David
Andrea Giammarchi wrote:
> Dunno how many times that bedge has been optimized ;-)
>
> (function(){
> var F = function(){};
> jQuery.beget = function (proto, props) {
> F.prototype = proto;
> return props ? $.extend(new F, props) : new F;
> };
> })();
>
> Regards
>
>
> On Thu, Jul 30, 2009 at 3:48 PM, Már Örlygsson > wrote:
>
>
> Hi.
> If it hasn't been already considered (and rejected), I'd like to float
> the idea of adding support for prototypal inheritance into the jQuery
> core library.
>
> Something like this...
>
>jQuery.beget = function (proto, props) {
>var F = function () {};
>F.prototype = proto;
>var instance = new F();
>return props ? $.extend(instance, props) : instance;
> };
>
> ...becomes immensely powerful - especially during plugin development
> when allowing users to extend/override default options
>
>options = $.beget($.myplugin.defaults, options || {});
>
> ...and in various other common use cases - including $.fn.data()
> assignments, etc.
>
>
> I for one would love to see this feature added.
>
> --
> Már
>
>
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
> - after all, it is only a condition to add
> if( typeof mapping[ copy ] != 'undefined' ) {
> target[ name ] = mapping[ copy ];
> }
> where copy would be the object inside a cycle. In fact, it is a bit
> more complex, but not more costly
>
Well, except you have to hash the object to get an accurate key for the
object property.
I don't particularly think that this is something worth pursuing.
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
> If jQuery were to try and track circular references it would:
> A) Make .extends extremely inefficient because it would have to store
> just about everything it touches and make sure it doesn't recurse
> B) No longer create duplicate objects as it was told to
For B), it would create duplicates objects as it wouldn't be the same
objects as source, but it would conserve cycles inside an object
graph.
It don't think it causes a semantical problem, as when you copy a
graph, it would be normal to copy relations between nodes too.
For A), this is another problem. Yes, it could reduce performances as
we would have to create a mapping object and we would have to test and
add every object on it.
But,
- after all, it is only a condition to add
if( typeof mapping[ copy ] != 'undefined' ) {
target[ name ] = mapping[ copy ];
}
where copy would be the object inside a cycle. In fact, it is a bit
more complex, but not more costly
- When I see the complexity of some functions to have exactly the
exact rendering we want, I don't understand why it causes a problem to
add one or two conditions and store temporarily data.
Ludovic
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
jQuery does reproduce loops:
var father = {
child : {}
}
father.child.father = father;
$.extends( {}, father )
The problem here is you are telling jQuery to recurse into things it
shouldn't be recursing into.
$.extends( true, .. ); is for when you want to duplicate nested objects,
rather than reference the same objects.
By definition, you are asking jQuery to:
Take {}
Take the keys in father:
for the child key:
create an object to make a duplicate using and place that onto {}.child
recurse into child:
for the father key:
create an object to make a duplicate using and place that onto
child.father
recurse into father:
for the child key:
create an object to make a duplicate using and place
that onto father.child
recurse into child:
...
There is no problem here, jQuery is following your orders just as you
give them.
If jQuery were to try and track circular references it would:
A) Make .extends extremely inefficient because it would have to store
just about everything it touches and make sure it doesn't recurse
B) No longer create duplicate objects as it was told to
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
ludovic wrote:
> Hi,
> I've got loops in my objects relations. Example :
>
> var father = {
> child : {}
> }
>
> father.child.father = father;
>
> $.extends( true, {}, father ) causes a infinite loop.
>
> Jquery should reproduce loops.
>
> Regards,
> Ludovic
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
Hi,
I've got loops in my objects relations. Example :
var father = {
child : {}
}
father.child.father = father;
$.extends( true, {}, father ) causes a infinite loop.
Jquery should reproduce loops.
Regards,
Ludovic
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
Unfortunately I haven't had a chance to look in to this yet, but thanks for
your reduction - it'll certainly help!
--John
On Tue, Aug 11, 2009 at 1:55 PM, glyphobet wrote:
>
> I have confirmed that this is happening for other people in the IRC
> channel, and added some more information to the bug report. Most
> importantly, this bug is not present in Internet Explorer 8 running in
> Internet Explorer 7 developer mode, only in the real Internet Explorer
> 7.
>
> http://dev.jquery.com/ticket/4999#comment:1
>
> -matt
>
> On Aug 7, 11:57 am, Matt Chisholm wrote:
> > I recently posted this bug regarding selectors with commas in IE 7. It
> > includes a minimal test case.
> >
> > http://dev.jquery.com/ticket/4999
> >
> > I was just wondering if anybody had had the time to look into it. :)
> >
> > -matt
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
I have confirmed that this is happening for other people in the IRC
channel, and added some more information to the bug report. Most
importantly, this bug is not present in Internet Explorer 8 running in
Internet Explorer 7 developer mode, only in the real Internet Explorer
7.
http://dev.jquery.com/ticket/4999#comment:1
-matt
On Aug 7, 11:57 am, Matt Chisholm wrote:
> I recently posted this bug regarding selectors with commas in IE 7. It
> includes a minimal test case.
>
> http://dev.jquery.com/ticket/4999
>
> I was just wondering if anybody had had the time to look into it. :)
>
> -matt
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
Event callback: function(eventObject) { this = domnode }// Because
that's the way events have always worked
each() callback: function(index, sameAsThis) { this = item/domnode } //
Keeping the pattern
map() callback: function(index, sameAsThis) { this = item/domnode } //
Keeping the pattern
filter() callback: function(index) { this = item/domnode } // sorta
keeping the pattern
vs.
Event callback: function(eventObject) { this = domnode } // event
callbacks MUST use this as domnode, otherwise you destroy the api it was
based on
each() callback: function(item, index?) { ... }
map() callback: function(item, index?) { ... }
filter() callback: function(item, index?) { ... }
Whether you like it or not, jQuery is a library for working with the
dom. Thus when created each/map/filter had nothing to do with the array
methods that have only been put into browsers recently (yes, recently...
you are comparing standards set by new features, with decisions that
were made years ago; not the best comparison), they were created to give
control over the jQuery object's list of dom nodes. Thus, since all the
other apis which worked with dom nodes used `this` to refer to the dom
node that same api was used when writing those methods.
It's only a side effect that these methods happen to be usable on
non-domlist arrays. Though frankly, imho that is abuse, these methods
are not meant for that purpose, you can plainly see that in how $.fn.map
differs from Array.prototype.map in how it folds arrays into the list
rather than adding them as items.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Pauan wrote:
> And how is it inferior to set the current item as an argument to the
> callback? This is how Array.prototype.forEach works. It causes less
> problems while providing the exact same functionality. Also, event
> handlers are not the same as functions used to iterate over an object,
> nor do they serve the same purpose, so one model doesn't necessarily
> apply to the other.
>
> On Aug 11, 6:10 am, Scott González wrote:
>
>> There definitely is a reason for it. jQuery is a library for working
>> with the DOM, it is not a library meant to fix every problem with
>> JavaScript or to try to extend JavaScript in every possible way. When
>> using jQuery specifically to work with the DOM (probably >90% of what
>> you're using it for, and 100% of what the average user uses it for),
>> it makes perfect sense to set the context to the current item. Also,
>> native event handlers set the context to the event target, so jQuery
>> had an existing model to follow.
>>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
And I am the one who writes obfuscated code ...
*var verbTime = ~~(Math.random()*TC);*
two operations just to obtain a floor?
try again:
*var verbTime = (Math.random()*TC) << 0;*
Regards
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
Sorry, I could not resist ;o)
// enclosure
(function () {
// key elements selected only once
var $THAT = $(that) , // must be valid dom node
$verb_content = $("#verb-content") ,
$adj_content = $("#adj-content") ,
$subj_content = $("#subj-content") ;
// core logic
function loop ( ARR, $C, TC )
{
var verbTime = ~~(Math.random()*TC);
for(var i = 0; ihttp://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
And how is it inferior to set the current item as an argument to the
callback? This is how Array.prototype.forEach works. It causes less
problems while providing the exact same functionality. Also, event
handlers are not the same as functions used to iterate over an object,
nor do they serve the same purpose, so one model doesn't necessarily
apply to the other.
On Aug 11, 6:10 am, Scott González wrote:
> There definitely is a reason for it. jQuery is a library for working
> with the DOM, it is not a library meant to fix every problem with
> JavaScript or to try to extend JavaScript in every possible way. When
> using jQuery specifically to work with the DOM (probably >90% of what
> you're using it for, and 100% of what the average user uses it for),
> it makes perfect sense to set the context to the current item. Also,
> native event handlers set the context to the event target, so jQuery
> had an existing model to follow.
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
.hide(0) should have exactly the same behavior as .hide(1000) with
$.fx.off = true;
On Aug 10, 9:43 pm, Dave Methvin wrote:
> There's already an open ticket on this, it does seem like the callback
> should be called.
>
> http://dev.jquery.com/ticket/2542
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
There definitely is a reason for it. jQuery is a library for working
with the DOM, it is not a library meant to fix every problem with
JavaScript or to try to extend JavaScript in every possible way. When
using jQuery specifically to work with the DOM (probably >90% of what
you're using it for, and 100% of what the average user uses it for),
it makes perfect sense to set the context to the current item. Also,
native event handlers set the context to the event target, so jQuery
had an existing model to follow.
On Aug 11, 6:09 am, Pauan wrote:
> I think you guys are missing the point. This isn't a question about
> object-oriented programming (in JavaScript or otherwise). It's about
> jQuery's handling of "this" within the context of "each".
>
> To answer the original question, I don't think there's any real reason
> for it. It was an unfortunate blunder (probably intended for
> convenience) that will probably remain (for backwards compatibility).
> As said, you can store the reference to "this" in a variable, so you
> can work around it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
I think you guys are missing the point. This isn't a question about
object-oriented programming (in JavaScript or otherwise). It's about
jQuery's handling of "this" within the context of "each".
To answer the original question, I don't think there's any real reason
for it. It was an unfortunate blunder (probably intended for
convenience) that will probably remain (for backwards compatibility).
As said, you can store the reference to "this" in a variable, so you
can work around it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
I make always an a reference to my instance with var self = this; and
using always 'self' namespace after that, at this way you can be
always sure accessing the right object.
I think jQuery is alwas referencing 'this' to current elements set, so
jquery can't and won't to do any exception in case of each method.
Its the style of jquery, because almost all methods you are using by
jquery are bounded to elements.
On Aug 11, 12:37 am, Tarini wrote:
> thanks guys for you answer but I know how to use $.each in OO context...
> I would like to understand why jQuery works in this way..
>
> What are the advantage using this inside closure instead of using a temp
> arguments like the index? I see only disadvantage...
>
> I also created a plugin (http://code.google.com/p/jquerycallback/) to
> manage callback using OO but this remain one of the (few) aspects of
> jQuery I don't like and I would like to get a reason :)
>
> Also...
> Thinking about OOP... are you really sure that jQuery isn't a OO library
> (or framework as you prefer)?
> Two considerations about this relationship between jQuery and OOP:
> - jQuery selectors are a "strange" way to construct an object, an
> alternative constructor starting from a dollar sign and not with "new"
> keyword ( var divs = $("div") should be written as var divs = new
> jQuery("div") )
> - jQuery function (events, attributes, traversing, ecc...) are a lot of
> methods of jQuery object... they aren't simple namespaced function in a
> functional paradigm.
>
> (alternative) constructor + a lot of methods = object oriented
> programming
>
> why not?
>
> I hope to get some reply ;)
>
> On Fri, 2009-08-07 at 07:37 -0700, aHeckman wrote:
> > @ludovic, javascript IS an object oriented language. There is no need
> > for simulation. It's just a different type of oop than classical.
>
> > function Person (name) {
> > this.name = name || 'Nobody';
> > }
> > Person.prototype = {
> > sayName: function () {
> > alert('Hi my name is ' + this.name);
> > }
> > };
> > var ludovic = new Person('ludovic')
>
> > On Aug 7, 8:13 am, ludovic wrote:
> > > If you want to keep you function's context, you can still do
>
> > > $('div').each( function() {
> > > Context.myFunction( this );
>
> > > } );
>
> > > Anyway, I'm not sure it's a good idea to try to simulate object
> > > oriented syntax with javascript.
> > > It isn't an object oriented language and trying to make a language in
> > > a foreign paradigm is always heavy.
> > > But it is a personal opinion...
>
> > > ---
> > > Ludovic
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
30 matches
Mail list logo
