I was about to write a separate mail to the dev list about this but saw this discussion so I'll just join it. It seems like the discussion wasn't really conclusive?
I also in favor the single object argument approach. The main reason for this is probably too much Ext Js coding, but at the moment I'm finding the multiple argument construction of Layer-subclasses really annoying since I need to serialize/deserialize metadata describing what to create. Here is my few other points: 1. "options" isn't always optional (at least in the logical sense) it seems - for instance when creating OpenLayers.Filter.Spatial instances. 2. Classes in openlayers that have an obvious primitive representation does not allow that representation to be used implicitly. One obvious example is OpenLayers.Bounds which I think would be great if the array (and/or string, personally I prefer the array) representation was accepted as input when constructing. I guess this is kind of similar to the idea of lazy initialization in Ext Js. My points aside, I would assume that for 3.0 this discussion needs conslusion and perhaps I can still dream about a total refactor to consistent single object arguments approach for 3.0? :) /Björn 2010/6/18 Peter Robins <openlay...@peterrobins.co.uk>: > On 18 June 2010 16:53, <christopher.schm...@nokia.com> wrote: >> I regularly use a WMS server with no 'layers' param. I know that this >> is a special case, but the layer does not technically require this >> parameter to work. (Your server might; the spec might even, but >> the parameters that are required depend on your server.) > > a situation I've often found with WMS servers is that the (WMS) params > depend on the state of the map; having the layers param dependent on > zoomlevel is a common issue. In some cases, I'm even using different > servers depending on the zoomlevel. In this case, you can't specify > the WMS params in the constructor, but only in a custom moveTo or > whatever. > > So to me the key point is not whether a particular property is > necessary for a particular method in the object to function, but > whether it has to be present in the constructor. I would guess that > the number of truly required params (i.e. the object can't be > constructed without it) is very small. > > To me, the big advantage of OL (and JS) is it's very flexible, and > allows me to change more or less any property or method whenever > necessary. Requiring me to enter something in the constructor param > (WMS params in the case above) even if I don't know at that point what > it should be seems like unnecessary bureaucracy to me, and IMO it > would be better simply to document what happens if certain params are > or are not present. > > Anyway, that fits in better with the name 'options' - by definition, > all options are optional :-) > > FWIW, I favour the single object argument, though it's not something I > would man the barricades about. > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
