rest2web-develop

RE: [Rest2web-develop] Misc fixes, and a last request

[Michael F. <mi...@pc...>]

Hello Nicola,

My friend has said he will setup the unixshell account for us - but no details yet.

-----Original Message-----
   >From: "Nicola Larosa"<ni...@te...>
   >Sent: 14/08/05 19:42:22
[snip..]

All your work/fixes sound very good.

   >The last request
   >----------------
   >
   >Really the last, I promise. O:-)
   >
   >It's about required values, and required sections.
   >
   >Currently, if a scalar has no default in the configspec, it must be
   >specified in the config, therefore in the end every scalar has a value. But
   >I need optional values, with no default, and possibly not specified in the
   >config, so that they may effectively be missing from the config obj.
   >
   >We could decide that when a scalar is defined with "default = None", then
   >it means that it's required, otherwise it may be altogether absent from the
   >config. In that case, the default would be for all values not to be
   >required: the opposite would have to be explicitly specified.
   >

This is exactly the *opposite* of the way configspecs currently work. If no default is specified the value must be specified.

My normal use case is that defaults are not specified and values are not optional.

*Also* - None is a possible value to pass to default. 

Possible alternatives :

1) How about a new ``optional`` keyword ? I would have it default to False - but you could override this with a new option ?

2) We could create a new value for ``default`` - say ``Force`` - meaning the value is optional ?

3) You could always do it yourself programatically of course - use  '__OPTIONAL__'  as your default value and then delete all members that have this value..... It may need a slight alteration to 'walk' (you couldn't delete members of a section whilst iterating over it - have to iterate over a copy of the keys).

4) Hmmm... What about an ``__optional_scalars__`` list of keys for a section ?


I don't like the 'default is keys are optional' solution - it seems to me to reverse the primary rationale of configspecs. Also - it makes writing quick and simple configspecs more painful.

Adding an extra keyword is clumsy - but making it impossible to have None as a default value doesn't seem good either. I favour options 3 or 4.
  
   >A similar issue is the requiredness of sections: I need to be able to omit
   >entire sections from the config, and this is currently not possible.

An __optional__ scalar value in the configspec ? (true or false)

You could even combine with __optional_scalars__ - and just make __optional__ a list thatan include sections and scalars. Then only one more magic value is needed.  

   >A related issue would be specifying the min and max number of subsections in
   >__many__ sections.
   >

__min__ and __max__ magic scalars in __many__ sections ?

   >All the rest works, the requiredness issue should be all that's missing for
   >my use case. What about it? :-)
   >

LOL
Hmmm.... Who's gonna implement all this ? You're pretty familiar with the code now Nicola ;-p

Best Regards, 

Fuzzyman 
http://www.voidspace.org.uk/python 

   >-- 
   >Nicola Larosa - ni...@te...
   >
   >Does it seem like I'm looking for an answer
   >To a question I can't ask
   > -- Norah Jones, Nightingale, Come Away with Me, 2001
   >
   >
   >
   >
   >-------------------------------------------------------
   >SF.Net email is Sponsored by the Better Software Conference & EXPO
   >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
   >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
   >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
   >_______________________________________________
   >Rest2web-develop mailing list
   >Res...@li...
   >https://lists.sourceforge.net/lists/listinfo/rest2web-develop
   >
   >
   >

Re: [Rest2web-develop] Misc fixes, and a last request

[Nicola L. <ni...@te...>]

> My friend has said he will setup the unixshell account for us - but no
> details yet.

Great.


> This is exactly the *opposite* of the way configspecs currently work. If
> no default is specified the value must be specified.
>
> My normal use case is that defaults are not specified and values are not
> optional.
>
> I don't like the 'default is keys are optional' solution - it seems to me
> to reverse the primary rationale of configspecs. Also - it makes writing
> quick and simple configspecs more painful.

I agree. I was just trying to avoid adding another keyword, but didn't like
the inversion of policy either, so keys stay mandatory.

Thinking about it, the specification "default = None" should mean exactly
what it says, that is, if no value is specified in the config, the key gets
the value "None".


> *Also* - None is a possible value to pass to default.

This is the key of the solution to the problem.

Currently, "None" is only usable if a key is of type "none". But such a
type is useless: what can you do with an option that can only assume the
"None" (non-)value? :-) The only use case I currently see is as a value in
"multiple" types.

Thinking more about it, I'd say instead that the "None" type should be a
legal value for all types, with the same meaning as NULL in SQL, that is,
no real value specified. Same meaning as in Python, incidentally. ;-)

Then you can add "default = None" to *any* type, meaning that if no value
is  present in the config, that key gets the "None" (non-)value, that is,
no real value.

This also solves a remaining problem: specifying a default value for list
types, currently not possible.

Obviously, now that "None" is always a legal (non-)value, the "none" type
is not needed anymore, and goes away. :-)


> Possible alternatives :

[mumbo-jumbo deleted ;-) ]

We can forget about all that. :-)


>> A similar issue is the requiredness of sections: I need to be able to
>> omit entire sections from the config, and this is currently not
>> possible.

> An __optional__ scalar value in the configspec ? (true or false)
>
> You could even combine with __optional_scalars__ - and just make
> __optional__ a list that can include sections and scalars. Then only one
> more magic value is needed.

I decided to do away with that, and require that all sections must always
be present, even if empty. It's not worth the added complication.


>> A related issue would be specifying the min and max number of
>> subsections in __many__ sections.

> __min__ and __max__ magic scalars in __many__ sections ?

Archived under YAGNI.


I'm working on this now, today's holiday in Italy, but not in England
apparently, so if you are at work let me know about it as soon as you can.


-- 
Nicola Larosa - ni...@te...

Does it seem like I'm looking for an answer
To a question I can't ask
 -- Norah Jones, Nightingale, Come Away with Me, 2001