Re-naming proposals

Re-naming proposals

[Mike Cvet]

Today I was thinking about some class names, and a couple things stood out.

The first being that SourceWindow isn't really an appropriate name 
anymore - its a debugger window, not just a window which displays the 
source code of a process. So I propose that it is renamed to 
DebugWindow. Consequently, the gui/srcwin tree will be renamed to 
something like gui/debugwin.

The second is the debugging and stepping state machine for the 
Source/DebugWindow and FHPD - RunState. Its a pretty awful name, and 
doesn't really mean anything, so I was thinking of refactoring it to 
DebugStateMachine.

The last is the CreateFryskSessionDruid class - maybe just call it 
FryskAssistant or something?

- Mike

Re: Re-naming proposals

[Nurdin Premji]

Mike Cvet wrote:
> Today I was thinking about some class names, and a couple things stood 
> out.
>
> The first being that SourceWindow isn't really an appropriate name 
> anymore - its a debugger window, not just a window which displays the 
> source code of a process. So I propose that it is renamed to 
> DebugWindow. Consequently, the gui/srcwin tree will be renamed to 
> something like gui/debugwin.
>
> The second is the debugging and stepping state machine for the 
> Source/DebugWindow and FHPD - RunState. Its a pretty awful name, and 
> doesn't really mean anything, so I was thinking of refactoring it to 
> DebugStateMachine.
>
> The last is the CreateFryskSessionDruid class - maybe just call it 
> FryskAssistant or something?
>
> - Mike
>
>
I agree with all 3 proposals concurrently (or maybe consecutively).

Re: Re-naming proposals

[Sami Wagiaalla]

Mike Cvet wrote:
> Today I was thinking about some class names, and a couple things stood 
> out.
Happens to me all the time every day... thank god for eclipse.
>
> The first being that SourceWindow isn't really an appropriate name 
> anymore - its a debugger window, not just a window which displays the 
> source code of a process. So I propose that it is renamed to 
> DebugWindow. Consequently, the gui/srcwin tree will be renamed to 
> something like gui/debugwin.
Fine by me. Although I dont really find SourceWindow that bad.
>
> The second is the debugging and stepping state machine for the 
> Source/DebugWindow and FHPD - RunState. Its a pretty awful name, and 
> doesn't really mean anything, so I was thinking of refactoring it to 
> DebugStateMachine.
Cool.
>
> The last is the CreateFryskSessionDruid class - maybe just call it 
> FryskAssistant or something?
Frysk can have more than one assistant. How about CreatSessionAssistant
>
> - Mike
Sami

Re: Re-naming proposals

[Kris Van Hees]

On Wed, Apr 11, 2007 at 01:19:19PM -0400, Mike Cvet wrote:
> Today I was thinking about some class names, and a couple things stood out.
> 
> The first being that SourceWindow isn't really an appropriate name 
> anymore - its a debugger window, not just a window which displays the 
> source code of a process. So I propose that it is renamed to 
> DebugWindow. Consequently, the gui/srcwin tree will be renamed to 
> something like gui/debugwin.

Makes sense to me.

> The second is the debugging and stepping state machine for the 
> Source/DebugWindow and FHPD - RunState. Its a pretty awful name, and 
> doesn't really mean anything, so I was thinking of refactoring it to 
> DebugStateMachine.

Or perhaps DebugFSM (assuming that the state machine that is implemented
is indeed a finite state machine - I'd hope it is).  I like shorter
names when they are not obscure.

> The last is the CreateFryskSessionDruid class - maybe just call it 
> FryskAssistant or something?

Hm, I am not sure that FryskAssistant makes more sense to me than
CreateFryskSessionDruid.  I'd opt for CreateFryskSession or even just
CreateSession.  Possibly with GUI appended to the name if we want to
make it explicit that it is the GUI element.  FryskAssistant just seems
to not really mean much without actually looking at the code to
determine what it actually does.

Which brings up a (small) side topic... Most of the time when we're
talking about 'the UI' on the calls or even IRC, people seem to be
referring to the actual GUI rather than the user interface (in a more
abstract sense).  Could we try to adopt GUI as term for the graphical
user interface, and whatever else (like CLI) for the text-based
interface?  That avoids confusion for anyone reading through mailing
list archives, etc.

	Cheers,
	Kris

Re: Re-naming proposals

[Sami Wagiaalla]

>> The second is the debugging and stepping state machine for the 
>> Source/DebugWindow and FHPD - RunState. Its a pretty awful name, and 
>> doesn't really mean anything, so I was thinking of refactoring it to 
>> DebugStateMachine.
>>     
>
> Or perhaps DebugFSM (assuming that the state machine that is implemented
> is indeed a finite state machine - I'd hope it is).  I like shorter
> names when they are not obscure.
>   
I never hesitate to make names long if it buys clarity. I never find 
that there is anything to be gained from making names shorter.
>   
>> The last is the CreateFryskSessionDruid class - maybe just call it 
>> FryskAssistant or something?
>>     
>
> Hm, I am not sure that FryskAssistant makes more sense to me than
> CreateFryskSessionDruid.  I'd opt for CreateFryskSession or even just
> CreateSession.  Possibly with GUI appended to the name if we want to
> make it explicit that it is the GUI element.
I do something similar in the GUI code: I usually append the type of the 
gui object to the end of the name. So for example there is 
SessionManager, and there is SessionManagerDialog.
> Which brings up a (small) side topic... Most of the time when we're
> talking about 'the UI' on the calls or even IRC, people seem to be
> referring to the actual GUI rather than the user interface (in a more
> abstract sense).  Could we try to adopt GUI as term for the graphical
> user interface, and whatever else (like CLI) for the text-based
> interface?  That avoids confusion for anyone reading through mailing
> list archives, etc.
>   
Yeah! i noticed that too. At some point we stopped saying GUI and 
started saying UI.... must have been while I was in school.
> 	Cheers,
> 	Kris
>   

Re: Re-naming proposals

[Phil Muldoon]

Mike Cvet wrote:
>
> The first being that SourceWindow isn't really an appropriate name 
> anymore - its a debugger window, not just a window which displays the 
> source code of a process. So I propose that it is renamed to 
> DebugWindow. Consequently, the gui/srcwin tree will be renamed to 
> something like gui/debugwin.


Sounds good.

>
> The second is the debugging and stepping state machine for the 
> Source/DebugWindow and FHPD - RunState. Its a pretty awful name, and 
> doesn't really mean anything, so I was thinking of refactoring it to 
> DebugStateMachine.


Debug is an overloaded term, especially in the context of State Machine. 
Though better than RunState ;)


>
> The last is the CreateFryskSessionDruid class - maybe just call it 
> FryskAssistant or something?


That was my doing, and wrong headed thinking at the time. I'd call it 
FryskSessionAssistant or something along those lines.

Regards

Phil

Re: Re-naming proposals

[Andrew Cagney]

Phil Muldoon wrote:
>>
>> The second is the debugging and stepping state machine for the 
>> Source/DebugWindow and FHPD - RunState. Its a pretty awful name, and 
>> doesn't really mean anything, so I was thinking of refactoring it to 
>> DebugStateMachine.
>
>
> Debug is an overloaded term, especially in the context of State 
> Machine. Though better than RunState ;)

There are at least two^w three objects here, the first - is the 
point-of-contact for the tasks being displayed by the debug window and 
the second, used by this manager or poc , is the state.  Finally there's 
a breakpoint object.   I'd be looking to split this class into smaller 
components, like has been done for Task/TaskState, for instance.

In this context debug is a very overloaded term.  Once the class has 
been broken down - Run, RunState, ... - a more obvious name will likely 
become clear.

Andrew

Re: Re-naming proposals

[Mike Cvet]

Andrew Cagney wrote:
>
> There are at least two^w three objects here, the first - is the 
> point-of-contact for the tasks being displayed by the debug window and 
> the second, used by this manager or poc , is the state.  Finally 
> there's a breakpoint object.   I'd be looking to split this class into 
> smaller components, like has been done for Task/TaskState, for instance.
>
> In this context debug is a very overloaded term.  Once the class has 
> been broken down - Run, RunState, ... - a more obvious name will 
> likely become clear.
>

I don't understand - so the states RunState is using for stepping a task 
should be broken into subclasses?

As far as breakpoints are concerned... that doesn't really matter. The 
original breakpoint class went into RunState because it was used for 
stepping. More general breakpoints for usage by fhpd or the debugging 
window probably should get their own class.

- Mike