Array option in widget isn't cloned

This is intentional. It's impossible to keep a reference if we do a copy, but it's easy for you to copy if that's what you want. The old behavior was very problematic.

OK, but in JavaScript an array is essentially just an object where you use indices to reference elements instead of names. Why wouldn't you want the behavior to be the same for arrays and objects? You copy objects, but not arrays.

Perhaps there is some place in the framework where this causes trouble that I don't know about but I definitely don't see why when you instantiate widgets of the same type with an option that is an array that you would want all those widgets to reference the same array. Sure, I can create a routine that does a copy, but that means two steps for instantiation, and means all existing code has to be changed to the two step instantiation process.

There are a lot of cases where arrays are data sources and being able to modify the original and have it change the widget is important.

It's not exactly a two step process, it's just the addition of a .each()

elements.each(function() {
    $( this ).widget({ option: array.slice() });
});

Alternatively, you can change your widgets to do clones internally on create.

Personally, I agree with the original poster. It seems somewhat odd that the behavior would be different between the two. Although, I slightly disagree with the poster in that I think this behavior doesn't make sense at all and it should always be pass by reference for all options. It was painful for me to learn that it wasn't this way, since it makes the most sense to me.

Can someone comment on why cloning happens in the first place and also on why it makes more sense to have different behavior based on argument type than being consistent?

I think it makes the most sense to always pass by reference regardless of the argument type, because, as Scott points out, it is easy to copy if that's what you want, but much more painful to keep references if it is copied by default.

Richard: It's because pass by reference is a huge surprise to almost everyone. People do multipleElements.widget( options ) all the time.

Replying to [comment:5 scott.gonzalez]:

Richard: It's because pass by reference is a huge surprise to almost everyone. People do multipleElements.widget( options ) all the time.

Yeah, I guess so.

However, it is still not really clear to me why this would be less surprising in the array case than in the object case, especially enough to justify an inconsistency in the API.

Seems like it would be better for you to provide some sort of mechanism for us to say explicitly what we want to have happen, rather than having you guys guess what we want.

Thanks for the response.

http://jsfiddle.net/T4NvA/5/

Here's a example.

I instantiate 4 distinct Widgets, the ones that I don't pass the array parameters share the same reference.

You shouldn't define an array as the default value. You should be setting an empty array if no rows are passed on create.

OK, so basically you are saying that default values should be set in create, rather than in the options declaration? That should work, but certainly makes it less clean unless you set all the options in create.

My biggest problem is that there was a rather fundamental change made to a rather established and stable API that addresses limited use cases and that breaks existing software in a rather significant way that is not always readily apparent (i.e. it doesn't just create a javascript error). Browser based developers have enough troubles keeping up with subtle browser changes. Hell, much of the reason for using an API like jQuery is that it hides these browser differences and changes and let's us program against a consistent API. But this change shows that maybe the goal of jQuery isn't to be consistent; that I have to worry about some subtle break every time I upgrade jQuery.