MorphicUIManager

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

MorphicUIManager

Casey Ransberger-2
Class comment is:
"The Morphic ui manager."

This comment is beyond useless. I'm glancing over the methods it exposes. Looks like it specializes a generic UIManager for morphic... and there's a similar MVCUIManager, comment is similarly useless.

Ah, the base class has a comment.

"UIManager is a dispatcher for various UI requests."

Do I take it the usual way of getting a UIManager is to send #default to the base class?

Thinking I'm going to add (at the least) a note to both subclasses saying "See the class comment in UIManager for more information." Technically this is true as it *does* have *slightly* more information. Then I'm going to mess around with it to get a sense for what it can do, and then expand the comment some.

Anything folks think I should know about this class before I go writing damned lies about it? :P
--
Casey Ransberger


Reply | Threaded
Open this post in threaded view
|

Re: MorphicUIManager

Hannes Hirzel
Casey,

yes, UIManager is a good class to start adding a comment.
Yes, in MorphicUIManager comment I would refer to the UIManager
comment. The same for MVCUIManager.

--Hannes


On 5/2/10, Casey Ransberger <[hidden email]> wrote:

> Class comment is:
> "The Morphic ui manager."
>
> This comment is beyond useless. I'm glancing over the methods it exposes.
> Looks like it specializes a generic UIManager for morphic... and there's a
> similar MVCUIManager, comment is similarly useless.
>
> Ah, the base class has a comment.
>
> "UIManager is a dispatcher for various UI requests."
>
> Do I take it the usual way of getting a UIManager is to send #default to the
> base class?
>
> Thinking I'm going to add (at the least) a note to both subclasses saying
> "See the class comment in UIManager for more information." Technically this
> is true as it *does* have *slightly* more information. Then I'm going to
> mess around with it to get a sense for what it can do, and then expand the
> comment some.
>
> Anything folks think I should know about this class before I go writing
> damned lies about it? :P
> --
> Casey Ransberger
>

Reply | Threaded
Open this post in threaded view
|

Re: MorphicUIManager

LawsonEnglish
In reply to this post by Casey Ransberger-2
On 5/1/10 7:14 PM, Casey Ransberger wrote:
Class comment is:
"The Morphic ui manager."

This comment is beyond useless. I'm glancing over the methods it exposes. Looks like it specializes a generic UIManager for morphic... and there's a similar MVCUIManager, comment is similarly useless.

Ah, the base class has a comment.

"UIManager is a dispatcher for various UI requests."

Do I take it the usual way of getting a UIManager is to send #default to the base class?

Thinking I'm going to add (at the least) a note to both subclasses saying "See the class comment in UIManager for more information." Technically this is true as it *does* have *slightly* more information. Then I'm going to mess around with it to get a sense for what it can do, and then expand the comment some.

Anything folks think I should know about this class before I go writing damned lies about it? :P
--

There's lies. damned lies, and Squeak Documentation...



Lawson



Reply | Threaded
Open this post in threaded view
|

Re: MorphicUIManager

David T. Lewis
In reply to this post by Casey Ransberger-2
On Sat, May 01, 2010 at 07:14:54PM -0700, Casey Ransberger wrote:

> Class comment is:
> "The Morphic ui manager."
>
> This comment is beyond useless. I'm glancing over the methods it exposes.
> Looks like it specializes a generic UIManager for morphic... and there's a
> similar MVCUIManager, comment is similarly useless.
>
> Ah, the base class has a comment.
>
> "UIManager is a dispatcher for various UI requests."
>
> Do I take it the usual way of getting a UIManager is to send #default to the
> base class?
>
> Thinking I'm going to add (at the least) a note to both subclasses saying
> "See the class comment in UIManager for more information." Technically this
> is true as it *does* have *slightly* more information. Then I'm going to
> mess around with it to get a sense for what it can do, and then expand the
> comment some.
>
> Anything folks think I should know about this class before I go writing
> damned lies about it? :P

Well this turns out to be a very interesting question. I had done some
work with UIManager in the course of refactoring some of the MVC stuff
to make MVC unloadable, so I figured that I aught to be able to explain
how it works. So I wrote a draft method comment explaining how I *thought*
it worked, and then did some double checking to make sure that the comment
matched reality.

It turned out that my comment did not match the implementation, and
this led me to notice that he implementation is actually somewhat broken.
I had expected that UIManager was swapping in the appropriate type of
manager (MVC or Morphic) whenever you switch projects, and that UIManager
has a Current class var that should point to the currently active
manager. But in fact the implementation is incomplete here, and every
time we make a reference to "UIManager current" we create a new instance
(after figuring out what kind on instance to create), and the result
is never actually cached in Current at all. This works fine, but it is
confusing (and inefficient), in that UIManager appears to be caching the
current manager, but in fact does not do so.

I tried fixing this so the cached Current value would be used, but the
result felt rather kludgy. I think that a better approach is to simply
associate an instance of UIManager with each project.

I will post fixes to trunk and add the following class comments:

  UIManager comment:
    UIManager is a dispatcher for various user interface requests, such as
    menu and dialog interactions. An instance of UIManager is associated with
    each Project to implement the appropriate functions for Morphic, MVC or
    other user interfaces.
   
  VMCUIManager comment:
    MVCUIManager is a UIManager that implements user interface requests for
    an MVC user interface.
   
  MorphicUIManager comment:
    MorphicUIManager is a UIManager that implements user interface requests
    for a Morphic user interface.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: MorphicUIManager

Casey Ransberger-2
Interesting. Is the class variable used at all? If not, we should probably remove it. 

David: thank you very much for your reply. As you have some experience with these classes, and are willing to make it happen, I'm going to continue my quest in other classes:)

I am filled with joy right now.

On Sun, May 2, 2010 at 2:54 PM, David T. Lewis <[hidden email]> wrote:
On Sat, May 01, 2010 at 07:14:54PM -0700, Casey Ransberger wrote:
> Class comment is:
> "The Morphic ui manager."
>
> This comment is beyond useless. I'm glancing over the methods it exposes.
> Looks like it specializes a generic UIManager for morphic... and there's a
> similar MVCUIManager, comment is similarly useless.
>
> Ah, the base class has a comment.
>
> "UIManager is a dispatcher for various UI requests."
>
> Do I take it the usual way of getting a UIManager is to send #default to the
> base class?
>
> Thinking I'm going to add (at the least) a note to both subclasses saying
> "See the class comment in UIManager for more information." Technically this
> is true as it *does* have *slightly* more information. Then I'm going to
> mess around with it to get a sense for what it can do, and then expand the
> comment some.
>
> Anything folks think I should know about this class before I go writing
> damned lies about it? :P

Well this turns out to be a very interesting question. I had done some
work with UIManager in the course of refactoring some of the MVC stuff
to make MVC unloadable, so I figured that I aught to be able to explain
how it works. So I wrote a draft method comment explaining how I *thought*
it worked, and then did some double checking to make sure that the comment
matched reality.

It turned out that my comment did not match the implementation, and
this led me to notice that he implementation is actually somewhat broken.
I had expected that UIManager was swapping in the appropriate type of
manager (MVC or Morphic) whenever you switch projects, and that UIManager
has a Current class var that should point to the currently active
manager. But in fact the implementation is incomplete here, and every
time we make a reference to "UIManager current" we create a new instance
(after figuring out what kind on instance to create), and the result
is never actually cached in Current at all. This works fine, but it is
confusing (and inefficient), in that UIManager appears to be caching the
current manager, but in fact does not do so.

I tried fixing this so the cached Current value would be used, but the
result felt rather kludgy. I think that a better approach is to simply
associate an instance of UIManager with each project.

I will post fixes to trunk and add the following class comments:

 UIManager comment:
   UIManager is a dispatcher for various user interface requests, such as
   menu and dialog interactions. An instance of UIManager is associated with
   each Project to implement the appropriate functions for Morphic, MVC or
   other user interfaces.

 VMCUIManager comment:
   MVCUIManager is a UIManager that implements user interface requests for
   an MVC user interface.

 MorphicUIManager comment:
   MorphicUIManager is a UIManager that implements user interface requests
   for a Morphic user interface.

Dave





--
Casey Ransberger


Reply | Threaded
Open this post in threaded view
|

Re: MorphicUIManager

David T. Lewis
On Sun, May 02, 2010 at 03:22:56PM -0700, Casey Ransberger wrote:
> Interesting. Is the class variable used at all? If not, we should probably
> remove it.

Right you are. I removed it.

> David: thank you very much for your reply. As you have some experience with
> these classes, and are willing to make it happen, I'm going to continue my
> quest in other classes:)
>
> I am filled with joy right now.

Thanks for putting some focus on this. It is actually a good little
case study on the value of documenting the system. The moral of the
story is that if you can't explain how something works in clear language,
then there is a pretty good chance that you don't know how it works.
And if you don't know how it works, then there is a pretty good chance
that it doesn't ;-)

Dave


Reply | Threaded
Open this post in threaded view
|

Re: MorphicUIManager

Casey Ransberger-2
That's quotable! I'm going to quote you in the other thread:)

On Sun, May 2, 2010 at 4:07 PM, David T. Lewis <[hidden email]> wrote:
On Sun, May 02, 2010 at 03:22:56PM -0700, Casey Ransberger wrote:
> Interesting. Is the class variable used at all? If not, we should probably
> remove it.

Right you are. I removed it.

> David: thank you very much for your reply. As you have some experience with
> these classes, and are willing to make it happen, I'm going to continue my
> quest in other classes:)
>
> I am filled with joy right now.

Thanks for putting some focus on this. It is actually a good little
case study on the value of documenting the system. The moral of the
story is that if you can't explain how something works in clear language,
then there is a pretty good chance that you don't know how it works.
And if you don't know how it works, then there is a pretty good chance
that it doesn't ;-)

Dave





--
Casey Ransberger