|
Boost : |
Subject: Re: [boost] Is there interest in a reusable stream-based console?
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2012-03-09 16:17:15
On Fri, Mar 9, 2012 at 21:08, Michael Hava <mfh_at_[hidden]> wrote:
>
> (example: http://www.youtube.com/watch?**v=VHFu6q1twtE
>>
> Looks nice, but it seems you focused far more on the "programming language
> aspect" than my original design was. You see I developed my first design
> based on experience in a product I'm working on in my job, where we offer a
> console in addition to the GUI for faster input. That console is deeply
> integrated into the program and was never really designed from the ground
> up to be reusableâ¦
>
>
In the video you see a lot of scripting in the console but if you look at
the beginning, it's only command line but not in a unix way (I used command
calls that looks more like multiplayer game console systems).
Anyway, the point was just that if you provide a console system, it
shouldn't allow custom inputs and output, otherwise it would be useful only
in the context of command line tools.
Maybe it's your interest, but then it's far less interesting for myself, so
it's juste my specific point of view.
>
> About the interface, I'm not sure if a command should be defined only by
>> a simple std::function. I've tried it before but I
>> wasn't able to make it work as more information were required.
>>
> Maybe I should have explained that a bit more: the command-class uses a
> std::function internally to store the callback that's to be executed, it's
> not a std::function.
>
Thanks but that was already my understanding. What I'm saying is that when
I did my own implementation I did allow only a callback first but in the
end I used a base class interface instead because I needed more infos (and
state) for those commands, so the base class provided other (changing)
informations than just the callback.
I'm just saying that I'm not sure if just a callback is enough, but I guess
experience will tell.
Joël Lamotte.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk