Re: Gogo commands: return result or print?

[Todor Boev]

But then I lose the advantage of using a generic type other commands/people
can understand.

E.g. I am now at the stage where I want a nice format for a Map>.
First of all it is generic so I have to make up a type.
Once I do that it is less usable...
Maybe make a "ConfigurationMap extends Map>"
just to workaround erasure.
But then I better export my type too ..or not?


On Fri, Jan 18, 2019 at 5:53 PM Raymond Auge 
wrote:

> On Fri, Jan 18, 2019 at 10:39 AM Todor Boev  wrote:
>
> > Ok, but the formatter doesn't always do what I want.
> >
> > Right now I return an array of objects and I want the Converter.INSPECT
> > level of detail when printing each item in the array.
> > The formatter uses Converter.INSPECT level for the array, but
> > Converter.PART or Converter.LINE for each item.
> > So what should I do:
> > - Add another command to inspect one item?
> > - Define my own format for that exact array?
> > - ..?
> >
>
> Deploy a converter for your type along with your command ;)
>
> - Ray
>
>
> >
> > On Fri, Jan 18, 2019 at 5:23 PM Raymond Auge 
> > wrote:
> >
> > > return!
> > >
> > > When you print you go around the formatters engine and you cannot pipe
> as
> > > nicely.
> > >
> > > The shell API is designed for returning results from command methods.
> > These
> > > can be complex objects which are much better for piping between
> commands
> > > than strings on sysout. The formatter engine only kicks in when
> actually
> > > printing out the result and so you can get nice output while having
> > really
> > > great piping.
> > >
> > > Furthermore, when you force the use of ThreadIO to manage the
> sys.out/err
> > > you introduce complex threading issues that make things like calling
> the
> > > command engine from other places (believe me when I say it can be
> useful)
> > > very, very painful.
> > >
> > > My suggestion is to avoid using sys.out/err whenever possible.
> > >
> > > - Ray
> > >
> > > On Fri, Jan 18, 2019 at 9:53 AM Todor Boev  wrote:
> > >
> > > > Hi,
> > > >
> > > > When implementing a Gogo shell command are there any rules of thumb
> on
> > > > whether I should return a result from the command method or print it
> on
> > > > System.out? Possibly using the CommandSession to format it first.
> > > >
> > > > What bothers me is that AFAIK the automatic printing of return values
> > > from
> > > > command methods may be turned off.
> > > >
> > > > Regards
> > > > Todor
> > > >
> > >
> > >
> > > --
> > > *Raymond Augé* 
> > >  (@rotty3000)
> > > Senior Software Architect *Liferay, Inc.* 
> > >  (@Liferay)
> > > Board Member & EEG Co-Chair, OSGi Alliance 
> > > (@OSGiAlliance)
> > >
> >
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>

Re: Gogo commands: return result or print?

[Raymond Auge]

On Fri, Jan 18, 2019 at 10:39 AM Todor Boev  wrote:

> Ok, but the formatter doesn't always do what I want.
>
> Right now I return an array of objects and I want the Converter.INSPECT
> level of detail when printing each item in the array.
> The formatter uses Converter.INSPECT level for the array, but
> Converter.PART or Converter.LINE for each item.
> So what should I do:
> - Add another command to inspect one item?
> - Define my own format for that exact array?
> - ..?
>

Deploy a converter for your type along with your command ;)

- Ray


>
> On Fri, Jan 18, 2019 at 5:23 PM Raymond Auge 
> wrote:
>
> > return!
> >
> > When you print you go around the formatters engine and you cannot pipe as
> > nicely.
> >
> > The shell API is designed for returning results from command methods.
> These
> > can be complex objects which are much better for piping between commands
> > than strings on sysout. The formatter engine only kicks in when actually
> > printing out the result and so you can get nice output while having
> really
> > great piping.
> >
> > Furthermore, when you force the use of ThreadIO to manage the sys.out/err
> > you introduce complex threading issues that make things like calling the
> > command engine from other places (believe me when I say it can be useful)
> > very, very painful.
> >
> > My suggestion is to avoid using sys.out/err whenever possible.
> >
> > - Ray
> >
> > On Fri, Jan 18, 2019 at 9:53 AM Todor Boev  wrote:
> >
> > > Hi,
> > >
> > > When implementing a Gogo shell command are there any rules of thumb on
> > > whether I should return a result from the command method or print it on
> > > System.out? Possibly using the CommandSession to format it first.
> > >
> > > What bothers me is that AFAIK the automatic printing of return values
> > from
> > > command methods may be turned off.
> > >
> > > Regards
> > > Todor
> > >
> >
> >
> > --
> > *Raymond Augé* 
> >  (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* 
> >  (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance 
> > (@OSGiAlliance)
> >
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: Gogo commands: return result or print?

[Todor Boev]

Ok, but the formatter doesn't always do what I want.

Right now I return an array of objects and I want the Converter.INSPECT
level of detail when printing each item in the array.
The formatter uses Converter.INSPECT level for the array, but
Converter.PART or Converter.LINE for each item.
So what should I do:
- Add another command to inspect one item?
- Define my own format for that exact array?
- ..?

On Fri, Jan 18, 2019 at 5:23 PM Raymond Auge 
wrote:

> return!
>
> When you print you go around the formatters engine and you cannot pipe as
> nicely.
>
> The shell API is designed for returning results from command methods. These
> can be complex objects which are much better for piping between commands
> than strings on sysout. The formatter engine only kicks in when actually
> printing out the result and so you can get nice output while having really
> great piping.
>
> Furthermore, when you force the use of ThreadIO to manage the sys.out/err
> you introduce complex threading issues that make things like calling the
> command engine from other places (believe me when I say it can be useful)
> very, very painful.
>
> My suggestion is to avoid using sys.out/err whenever possible.
>
> - Ray
>
> On Fri, Jan 18, 2019 at 9:53 AM Todor Boev  wrote:
>
> > Hi,
> >
> > When implementing a Gogo shell command are there any rules of thumb on
> > whether I should return a result from the command method or print it on
> > System.out? Possibly using the CommandSession to format it first.
> >
> > What bothers me is that AFAIK the automatic printing of return values
> from
> > command methods may be turned off.
> >
> > Regards
> > Todor
> >
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>

Re: Gogo commands: return result or print?

[Raymond Auge]

return!

When you print you go around the formatters engine and you cannot pipe as
nicely.

The shell API is designed for returning results from command methods. These
can be complex objects which are much better for piping between commands
than strings on sysout. The formatter engine only kicks in when actually
printing out the result and so you can get nice output while having really
great piping.

Furthermore, when you force the use of ThreadIO to manage the sys.out/err
you introduce complex threading issues that make things like calling the
command engine from other places (believe me when I say it can be useful)
very, very painful.

My suggestion is to avoid using sys.out/err whenever possible.

- Ray

On Fri, Jan 18, 2019 at 9:53 AM Todor Boev  wrote:

> Hi,
>
> When implementing a Gogo shell command are there any rules of thumb on
> whether I should return a result from the command method or print it on
> System.out? Possibly using the CommandSession to format it first.
>
> What bothers me is that AFAIK the automatic printing of return values from
> command methods may be turned off.
>
> Regards
> Todor
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)