clops-users

[Clops-users] AllOptions and other ways of defining option groups

[Fintan F. <fi...@gm...>]

I modified the option store generation template so we now have an
OptionGroup named "AllOptions". This was easy to do, but when I went to see
in which .clo files I could use it I realised that it wasn't sufficient. For
most interfaces there is often the need to have a group that includes most,
but not all, of the options.

I'd like to propose that we create a way of easily defining such groups. My
initial design would be allow subtracting options (or option groups) from
the set, something like:

OptionalOptions:   AllOptions -CompulsoryOptions;

Or for svn,

Options:   AllOptions -Commands;

Where option or option group names prefixed with a '-' means that they
should be removed from the set.

This obviously creates some complication in terms of how we expand an option
group to determine exactly what options are in it, but I think the effort
would be worth it. I think allowing definitions like the above will help to
keep the groupings succinct.

Comments/suggestions?

-F

Re: [Clops-users] AllOptions and other ways of defining option groups

[Julien C. <jul...@gm...>]

On Wed, Apr 8, 2009 at 11:27 AM, Fintan Fairmichael <fi...@gm...>wrote:

> I modified the option store generation template so we now have an
> OptionGroup named "AllOptions". This was easy to do, but when I went to see
> in which .clo files I could use it I realised that it wasn't sufficient. For
> most interfaces there is often the need to have a group that includes most,
> but not all, of the options.
>
> I'd like to propose that we create a way of easily defining such groups. My
> initial design would be allow subtracting options (or option groups) from
> the set, something like:
>
> OptionalOptions:   AllOptions -CompulsoryOptions;

Could it be a more documentation friendly name instead? Like just 'All', I
mean I don't want to have to make a special case in the doc generation to
make up a more user friendly name.


>
>
> Or for svn,
>
> Options:   AllOptions -Commands;
>
> Where option or option group names prefixed with a '-' means that they
> should be removed from the set.
>
> This obviously creates some complication in terms of how we expand an
> option group to determine exactly what options are in it, but I think the
> effort would be worth it. I think allowing definitions like the above will
> help to keep the groupings succinct.
>
> Comments/suggestions?
>
> -F
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Clops-users mailing list
> Clo...@li...
> https://lists.sourceforge.net/lists/listinfo/clops-users
>
>

Re: [Clops-users] AllOptions and other ways of defining option groups

[Julien C. <jul...@gm...>]

oops not in the mailing list. fixing it

On Wed, Apr 8, 2009 at 2:02 PM, Julien Charles <jul...@gm...>wrote:

> Ok so I will be more precise.
> The main problem is name collision, coupled with template translation, and
> custom user template things.
> Here what we do is to reserve a word for group naming. If we choose
> AllOptions, it will be typically translated by a section called 'AllOptions
> options' which I don't want. It will change most likely to a section with a
> name like 'All options'. Then in the average case the user will have an
> option which will be named All, and it will eventually collide with my
> translation and the user will be unhappy because we didn't tell him that All
> was already a reserved word somehow because the template use this
> convention. So I agree to do a special case, but tell me which user friendly
> header I could put up in the html.
>
> On Wed, Apr 8, 2009 at 1:53 PM, Fintan Fairmichael <fi...@gm...>wrote:
>
>>
>> Could it be a more documentation friendly name instead? Like just 'All', I
>>> mean I don't want to have to make a special case in the doc generation to
>>> make up a more user friendly name.
>>>
>>
>> While I do no agree that AllOptions is somehow not user-friendly it can be
>> easily changed. Just edit the template.
>>
>
>

Re: [Clops-users] AllOptions and other ways of defining option groups

[Viliam H. <vil...@uc...>]

On 08. Apr (Wednesday) v 11:27:47 +0100 2009, Fintan Fairmichael wrote:
> OptionalOptions:   AllOptions -CompulsoryOptions;
> 
> Or for svn,
> 
> Options:   AllOptions -Commands;
> 
> Where option or option group names prefixed with a '-' means that they
> should be removed from the set.

Sounds good for me. One question - do we want to distinguish between
arithmetic and set operators? In set we usually type \ or something
similar...

V.

Re: [Clops-users] AllOptions and other ways of defining option groups

[Radu G. <rad...@gm...>]

On Thu, Apr 9, 2009 at 2:34 AM, Viliam Holub <vil...@uc...> wrote:
> Sounds good for me. One question - do we want to distinguish between
> arithmetic and set operators? In set we usually type \ or something
> similar...

I prefer minus, as in Python. (I used to prefer it even before Python.)

Re: [Clops-users] AllOptions and other ways of defining option groups

[Mikoláš J. <mik...@gm...>]

I don't like the special keyword AllOptions and that we are diverging
from the idea that option groups are named rexpses.

In regexp notation instead of
> OptionalOptions:   AllOptions -CompulsoryOptions;
I'd write [^CompulsoryOptions], and AllOptions correspond to ".".

m.


On Wed, Apr 8, 2009 at 11:27 AM, Fintan Fairmichael <fi...@gm...> wrote:
> I modified the option store generation template so we now have an
> OptionGroup named "AllOptions". This was easy to do, but when I went to see
> in which .clo files I could use it I realised that it wasn't sufficient. For
> most interfaces there is often the need to have a group that includes most,
> but not all, of the options.
>
> I'd like to propose that we create a way of easily defining such groups. My
> initial design would be allow subtracting options (or option groups) from
> the set, something like:
>
> OptionalOptions:   AllOptions -CompulsoryOptions;
>
> Or for svn,
>
> Options:   AllOptions -Commands;
>
> Where option or option group names prefixed with a '-' means that they
> should be removed from the set.
>
> This obviously creates some complication in terms of how we expand an option
> group to determine exactly what options are in it, but I think the effort
> would be worth it. I think allowing definitions like the above will help to
> keep the groupings succinct.
>
> Comments/suggestions?
>
> -F
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Clops-users mailing list
> Clo...@li...
> https://lists.sourceforge.net/lists/listinfo/clops-users
>
>



-- 
Mikoláš Janota M. Sc.
School of Computer Science and Informatics,
University College Dublin,
Belfield,
Dublin 4,
Ireland

Re: [Clops-users] AllOptions and other ways of defining option groups

[Julien C. <jul...@gm...>]

I wholeheartedly agree with you on this point. I've added a feature request
going in that direction for v0.3.
Cheers,
Julien

On Tue, Apr 14, 2009 at 3:29 PM, Mikoláš Janota <mik...@gm...>wrote:

> I don't like the special keyword AllOptions and that we are diverging
> from the idea that option groups are named rexpses.
>
> In regexp notation instead of
> > OptionalOptions:   AllOptions -CompulsoryOptions;
> I'd write [^CompulsoryOptions], and AllOptions correspond to ".".
>
> m.
>
>
> On Wed, Apr 8, 2009 at 11:27 AM, Fintan Fairmichael <fi...@gm...>
> wrote:
> > I modified the option store generation template so we now have an
> > OptionGroup named "AllOptions". This was easy to do, but when I went to
> see
> > in which .clo files I could use it I realised that it wasn't sufficient.
> For
> > most interfaces there is often the need to have a group that includes
> most,
> > but not all, of the options.
> >
> > I'd like to propose that we create a way of easily defining such groups.
> My
> > initial design would be allow subtracting options (or option groups) from
> > the set, something like:
> >
> > OptionalOptions:   AllOptions -CompulsoryOptions;
> >
> > Or for svn,
> >
> > Options:   AllOptions -Commands;
> >
> > Where option or option group names prefixed with a '-' means that they
> > should be removed from the set.
> >
> > This obviously creates some complication in terms of how we expand an
> option
> > group to determine exactly what options are in it, but I think the effort
> > would be worth it. I think allowing definitions like the above will help
> to
> > keep the groupings succinct.
> >
> > Comments/suggestions?
> >
> > -F
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by:
> > High Quality Requirements in a Collaborative Environment.
> > Download a free trial of Rational Requirements Composer Now!
> > http://p.sf.net/sfu/www-ibm-com
> > _______________________________________________
> > Clops-users mailing list
> > Clo...@li...
> > https://lists.sourceforge.net/lists/listinfo/clops-users
> >
> >
>
>
>
> --
> Mikoláš Janota M. Sc.
> School of Computer Science and Informatics,
> University College Dublin,
> Belfield,
> Dublin 4,
> Ireland
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Clops-users mailing list
> Clo...@li...
> https://lists.sourceforge.net/lists/listinfo/clops-users
>

Re: [Clops-users] AllOptions and other ways of defining option groups

[Fintan F. <fi...@gm...>]

We're not diverging, AllOptions is still a named regexp. It's just defined
by default. It just saves you having to write it out manually.

I agree it's not entirely like regexp syntax, but it wasn't intended to be.
I really don't want to write [^SomeOptionOrGroup] in the format string. It's
horrible.

Also, treating option groups as sets is powerful for generating a group with
exactly the options we want inside it in a short succinct manner.

On Tue, Apr 14, 2009 at 3:33 PM, Julien Charles <jul...@gm...>wrote:

> I wholeheartedly agree with you on this point. I've added a feature request
> going in that direction for v0.3.
> Cheers,
> Julien
>
>
> On Tue, Apr 14, 2009 at 3:29 PM, Mikoláš Janota <mik...@gm...>wrote:
>
>> I don't like the special keyword AllOptions and that we are diverging
>> from the idea that option groups are named rexpses.
>>
>> In regexp notation instead of
>> > OptionalOptions:   AllOptions -CompulsoryOptions;
>> I'd write [^CompulsoryOptions], and AllOptions correspond to ".".
>>
>> m.
>>
>>
>> On Wed, Apr 8, 2009 at 11:27 AM, Fintan Fairmichael <fi...@gm...>
>> wrote:
>> > I modified the option store generation template so we now have an
>> > OptionGroup named "AllOptions". This was easy to do, but when I went to
>> see
>> > in which .clo files I could use it I realised that it wasn't sufficient.
>> For
>> > most interfaces there is often the need to have a group that includes
>> most,
>> > but not all, of the options.
>> >
>> > I'd like to propose that we create a way of easily defining such groups.
>> My
>> > initial design would be allow subtracting options (or option groups)
>> from
>> > the set, something like:
>> >
>> > OptionalOptions:   AllOptions -CompulsoryOptions;
>> >
>> > Or for svn,
>> >
>> > Options:   AllOptions -Commands;
>> >
>> > Where option or option group names prefixed with a '-' means that they
>> > should be removed from the set.
>> >
>> > This obviously creates some complication in terms of how we expand an
>> option
>> > group to determine exactly what options are in it, but I think the
>> effort
>> > would be worth it. I think allowing definitions like the above will help
>> to
>> > keep the groupings succinct.
>> >
>> > Comments/suggestions?
>> >
>> > -F
>> >
>> >
>> ------------------------------------------------------------------------------
>> > This SF.net email is sponsored by:
>> > High Quality Requirements in a Collaborative Environment.
>> > Download a free trial of Rational Requirements Composer Now!
>> > http://p.sf.net/sfu/www-ibm-com
>> > _______________________________________________
>> > Clops-users mailing list
>> > Clo...@li...
>> > https://lists.sourceforge.net/lists/listinfo/clops-users
>> >
>> >
>>
>>
>>
>> --
>> Mikoláš Janota M. Sc.
>> School of Computer Science and Informatics,
>> University College Dublin,
>> Belfield,
>> Dublin 4,
>> Ireland
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> High Quality Requirements in a Collaborative Environment.
>> Download a free trial of Rational Requirements Composer Now!
>> http://p.sf.net/sfu/www-ibm-com
>> _______________________________________________
>> Clops-users mailing list
>> Clo...@li...
>> https://lists.sourceforge.net/lists/listinfo/clops-users
>>
>
>