Hey-
The API for the 2.x series represents a bit of an evolution in thinking.
As the developer pool has collectively gained experience, some of our
preferences have changed with this experience.
In general, I think it is fair to say that classes introduced early
typically had longer signatures than classes introduced later.
Some assorted examples:
OpenLayers.Popup - 6 args
OpenLayers.Layer.WMS - 4 args
OpenLayers.Style - 2 args
OpenLayers.Rule - 1 arg
OpenLayers.Protocol - 1 arg
One problem (in my opinion) with long signatures, is that what may have
once been thought to be required arguments often become (or are later
understood to be) optional, and things start getting awkward.
Consider this. I've got a pixel location and some text, and I want to
create a popup with a close box.
var popup = new OpenLayers.Popup.FramedCloud(
null,
xy,
null,
text,
null,
true,
null // optional
);
An alternative is to use a single configuration object and get closer to
what other languages have with named arguments:
var popup = new OpenLayers.Popup.FramedCloud({
location: xy,
text: text,
closeBox: true
});
I think the second form is more readable and less prone to errors.
The one argument constructor is nothing new. We're doing it already in
some places in the library. People coming from popular JavaScript
frameworks are comfortable with this.
In adding the WMTS layer, I created a constructor that takes a single
argument. If others agree that this is the way forward, I think there
is sense in getting used to it before 3.0.
I am bringing this up here because Chris objected to my commit of the
WMTS layer and reopened the ticket.
If anybody else has an opinion about the many versus one argument
constructor, please weigh in.
Thanks,
Tim
--
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.