Re: [Clops-users] usage after parsing

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

I'd agree with Mikolas, but for slightly different reasons.

Extending the option types, by providing your own custom option class is
possible but will take a reasonable amount of work, largely in sufficiently
understanding the mechanisms involved in order to do so. I wouldn't advise
it in this case.

Even if you were to create a custom class, it will not be more succinct and
barely more efficient than creating a simple method that takes the created
option enum type as an argument, and returns an instance of the type that
you want (the body of the method just being a switch statement with each
case creating and returning the appropriate subclass type).

Hope this helps,

Fintan

On Fri, May 1, 2009 at 1:25 PM, Mikoláš Janota <mik...@gm...>wrote:

> Hi David,
>
>  technically this is possible as you can extend the option types
> yourself and the rules can contain any java code.
>
> However, it's something that I'd discourage you from doing as the
> CLOPS file was meant to be as Java-independent as possible and should
> express only the logic of options, not the program. There's always a
> blurry line between the program and option processing, so this is a
> matter of personal opinion.
>
> mikolas
>
> On Fri, May 1, 2009 at 12:22 AM, David W <di...@ho...> wrote:
> > Fintan, thanks. I hadn't even looked at the fly rules and didn't realize
> how
> > powerful they could be. I tried out what you described and that worked.
> >
> > I don't suppose there would be a way to use fly rules and virtual options
> to
> > create a new instance of a user defined object? With the method mentioned
> > previously, I would just need to pass an enum value to a factory if I
> needed
> > to create objects of a specific type. I was wondering if I could even
> bypass
> > the creation of this factory and have CLOPS return back a new object of
> the
> > type that I need (they would all be subclasses of a single base class).
> So
> > basically, it would be nice if I could define an arg with type "Command"
> and
> > then be able to return back "CMD1Command" and "CMD2Command" depending on
> > which command was set.
>