[OpenLayers-Dev] constructor signatures
Richard Duivenvoorde
rdmailings at duif.net
Fri Jun 18 04:49:01 EDT 2010
Don't have so much credit to interfere, but
as a user I have seen users (mw) who made the mistake with eg the
WMS-layer by putting param-arguments into the options-object and vice versa
what about always 2 object arguments:
- the required
- the optional (optional :-) )
making it possible to check for the required (off course also possible
with one object!)
but for users googling for examples and copying code, it makes sense to
know that the first object will always be the required ones (so in all
googled code snippets the same).
Seeing code with 8 parameters (even in one object), not knowing which
ones are really required is not that easy.
(though you can always read the api docs offcourse...)
speaking of api-docs, it would be really nice to have the inherited
required args, functions, props into a class definition also
Regards,
Richard Duivenvoorde
On 06/18/2010 01:22 AM, Schuyler Erle wrote:
>
> On Jun 17, 2010, at 3:33 PM, Tim Schaub wrote:
>
>> 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.
>
> I think that we can address this by placing a practical guideline on the number of arguments to any function in OL. For example, we could express a style guideline that any method that might take more than 3 arguments should use a dict instead of OR in addition to one or two fixed arguments. We can then require that any violation of this guideline be accompanied by a strong justification in the code comments.
>
> SDE
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
More information about the Dev
mailing list