Editing class method sources in single place

I just got an idea, what if make option for browser to show all
methods in one big listing, so developer can see, edit and do search
e.t.c using single code window without switching to different methods.
The idea, in general is to make browser look more convenient for
newcomers because most of mainstream languages keeping per-class
sources in single big source file.

Note, i'm not saying that current source browsing/editing have to be
changed or it's less convenient than mode which i proposing. It just
an option, mainly focused to help newcomers to get on board.


--
Best regards,
Igor Stasenko AKA sig.

On Wed, 30 Jan 2008 00:12:57 -0800, Igor Stasenko <[hidden email]>  
wrote:

I've had the same thought. I think it would be helpful to see more of your  
code at one time, particularly for pedagogic purposes.

"Igor Stasenko" <[hidden email]> wrote in message
>I just got an idea, what if make option for browser to show all
> methods in one big listing

I also like such a "print-out" view of a class sometimes. More generally,
being able to see a set of user-selectable methods very conveniently would
be really nice.
- "Convenient" might mean simultaneously on screen, or tabs, back buttons,
etc.
- "Selectable" might by
   - entire class
   - all in a message protocol
   - self or hierarchy sends
   - hand-selecting a group of methods
   - even other criteria on method meta-data like <pragmas>, naming
patterns, etc.

It is very painful or impossible to get these kinds of view currently. Some
STers seem very attached to current browsers.

There are browser packages around for doing some of these but they generally
seem to have fallen out of favour. I'm not sure if the new improved
OmniBrowser framework makes this any easier than it was before. OB
previously seemed to be architected to support a series of (single?)
selections. Lukas is working on an updated tool set based on the new OB, I'm
sure he would have a good perspective.

- Sophie

On Jan 30, 2008 3:09 PM, itsme213 <[hidden email]> wrote:
>
> It is very painful or impossible to get these kinds of view currently. Some
> STers seem very attached to current browsers.

Well I'm a relatively new Smalltalker and I'm quite attached to the
way current browsers work.  In fact, my day job currently has me
working on C# and I really wish I had a view there that was like the
Smalltalk one.  All those methods on one screen is just clutter for me
since I only concentrate on one method at a time in any event.

But if someone else wants to work that way then it sounds fine.  I
just hope people who work only from such a view take the time to learn
how people write Smalltalk (i.e. small well factored methods) instead
of carrying *other* practices into Smalltalk (e.g. 1000 line Java
methods).

Perhaps the Whisker browser would be a good place to start.

http://www.mindspring.com/~dway/smalltalk/whisker.html

Not sure about the status of the project.

Regards,
Zulq.

Blake wrote:

"Jason Johnson" <[hidden email]> wrote

> But if someone else wants to work that way then it sounds fine.  I
> just hope people who work only from such a view take the time to learn
> how people write Smalltalk (i.e. small well factored methods) instead
> of carrying *other* practices into Smalltalk (e.g. 1000 line Java
> methods).

Fair enough, though I did not see the link to 1000-line Java methods.

However, just because Smalltalk's pure-objects-image view starts out far
superior to a file-based view, does not mean there are cannot be better
variations on an established pure-objects view.

- Sophie

On Jan 30, 2008 10:03 PM, itsme213 <[hidden email]> wrote:
>
> Fair enough, though I did not see the link to 1000-line Java methods.

Just an observation of human nature.  Someone comes into something new
and assumes it's just like something else they know and can be used
the same way.  They hit little bumps here and there but not enough to
make them stop and think.  It's not until the crash into a brick wall
that they stop and either (a) assume this new thing sucks, leave it
and never look back or (b) realize maybe things are different here and
go out and learn the new thing.

By giving "all the comforts of home" (e.g. an editor that seems to be
used just like their previous language editor was) we remove one more
of those "stop and think" places that would make the "b" people look
around and try to see if there is a better way to do things in this
new place.

> However, just because Smalltalk's pure-objects-image view starts out far
> superior to a file-based view, does not mean there are cannot be better
> variations on an established pure-objects view.

I really hope there are superior ways of doing things then what we
have right now.  But I wouldn't begin my search from old, overly
simplistic ways (e.g. code is just something vomited into a file).

>I just got an idea, what if make option for browser to show all
> methods in one big listing, so developer can see, edit and do search
> e.t.c using single code window without switching to different methods.
> The idea, in general is to make browser look more convenient for
> newcomers because most of mainstream languages keeping per-class
> sources in single big source file.

If you want to do that, I think GNU Smalltalk syntax is more "newcomer
friendly". Here is a simple example in case you haven't seen it.

Magnitude subclass: Date [
  | days day month year |

  Date class >> today [
    <category: 'instance creation (Blue Book)'>
    ^self fromSeconds: Time secondClock
  ]

  subtractDays: dayCount [
    <category: 'basic'>
    ^Date fromDays: self days - dayCount
  ]
]

Thanks Paolo! you've got rid of the exclamation marks in a beatiful way.

Cheers,
Francisco

Francisco Garau wrote:
Heh. This looks just like my SqueakScript hacks from 2001 ;-)

Cheers,
   - Andreas

"Jason Johnson" <[hidden email]> wrote

> But I wouldn't begin my search from old, overly
> simplistic ways (e.g. code is just something vomited into a file).

You are absolutely right about that.

- Sophie

What benefits i see, comparing to single-method view.

You can scroll to other method using keys, instead click-click , open
new browser window and click, totally losing your focus.
You can do a full-text search on listing.
With some shortcuts it's easy to make actions like moving caret to
different method, simply by typing first letters of it's selector.
What else can be done: more reacher editor functionality:
- bookmarks, letting you remember and then jump to previously bookmarked method.
- more area for text editing/view. Yes, most of the methods are too
short, that you can say it's not worth it, but consider when you can
see multiple methods in single big window, it can be better than using
multiple browser windows with own set of controls (and which is 99%
will overlap each other).
- edit window splitting , when you need to code something, while
referring to other methods/sources.
My vision is to make upper pane of browser more compact and make more
space for text editing.
As option, we can add a tiny button, which when clicked will collapse
all lists, making more space for editing text, while list should be
still available via using small combo-boxes on window top.
All i seek, is more convenience: less clicking and fuzzy typing, more
coding and analyzing :)

--
Best regards,
Igor Stasenko AKA sig.

"Igor Stasenko" <[hidden email]> wrote in message

> - edit window splitting , when you need to code something, while
> referring to other methods/sources.

This is one good scenario of use where todays browser is not efficient.

(It happens to be exacerbated by the tool requiring you to Accept or
Cancel -- so you end up clicking your way into another browser window -- but
it would be awkward even otherwise).

- Sophie

On 30-Jan-08, at 3:30 PM, itsme213 wrote:

> "Igor Stasenko" <[hidden email]> wrote in message
>
>> - edit window splitting , when you need to code something, while
>> referring to other methods/sources.
>
> This is one good scenario of use where todays browser is not  
> efficient.
That's exactly where having many browsers open at once is a big win. I  
typically have 5 - 10 browsers open. A couple where I might be in the  
midst of editing, a couple open on related methods, some available for  
looking up stuff. I've been doing it that way since a 640*400 screen  
was a luxury. Why add the complication of window splitting when it is  
merely a poor attempt at what we already have?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
All wiyht.  Rho sritched mg kegtops awound?

On 30-Jan-08, at 2:39 PM, Igor Stasenko wrote:
>
> You can scroll to other method using keys, instead click-click , open
> new browser window and click, totally losing your focus.
Could trivially be implemented, if indeed some analogue of alt-tab  
type window cycling hasn't already been done. How is moving the code  
around in a single view any different focus-wise to looking at a  
different window?

>
> You can do a full-text search on listing.
You can do that in Squeak already.

>
> With some shortcuts it's easy to make actions like moving caret to
> different method, simply by typing first letters of it's selector.
Within the method list that already happens, pretty much. So add a key  
to jump up to the method list or add access to that functionality to  
the texteditor morph(s)

>
> What else can be done: more reacher editor functionality:
> - bookmarks, letting you remember and then jump to previously  
> bookmarked method.
An open browser is a pretty good bookmark, with the added advantage  
that you can type remarks into the text there. For example, if I have  
to leave a bit of editing unfinished overniht I will often type
XXXXXXX working on frobulating the libnoz XXXXXXX
into the code.
>
>
> - edit window splitting , when you need to code something, while
> referring to other methods/sources.
Many browsers open at once solves that problem much more effectively.

Before anyone tries to tell me I should try an editor with splittable  
windows and bookmarks etc. I should perhaps point out that I spent  
nearly 20 years using one for my C coding. Within that style it is of  
some use but Smalltalk allows a much nicer style. I'm no more likely  
to accept your arguments on the matter than I would accept claims that  
"you people need to change the syntax to match visual basic".

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- His page was intentionally left blank.

On Thu, 31 Jan 2008 00:39:23 +0200, "Igor Stasenko" <[hidden email]>
wrote:

> - bookmarks, letting you remember and then jump to previously bookmarked method.

We thought long and hard about this one when I was with The Object People
and we were building a new browser for Visual Smalltalk. We decided that
bookmarks are way more trouble than they are worth, because you have to
manage them, mainly because you eventually end up with too many, and you
can't find anything anymore.

However, it turns out there's a better metaphor that people intuitively
understand - a stack. When you're coding, and you need to look something
up, just push the current browser state onto the stack (we used Alt-C for
this), and then go find what you're looking for. When you find it, Alt-V
takes you right back to where you were before, as if you never left. If you
are somewhere looking after pushing, and need to remember what you were
looking for, Alt-X swaps the current state and the saved state, and then
Alt-X swaps you right back again.

Of course, you can push more than one state on the stack, and it works
exactly the way you would expect it to work.

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      [hidden email]      http://www.huv.com/jon

  Project: Micro Raptor (Small Biped Velociraptor Robot)
           http://www.huv.com/blog

Hi,

In the old MorphicWrappers package you could "tear-off" a method or a class
from the browser. They were a mixture of a bookmark (because they were
always there using very little screen space) and a browser (because you
could edit the code there).

The MorphicWrapper for a class (seen as the little orange boxes in the
screenshot) also acted as bookmarks. You would normally put several classes
on the desktop, send the message "browse" to some of them and get the usual
browser. Once you identified the interesting method, tear it off and leave
it on the desktop. I would accomodate these methods from different classes
in a similar order as they appear in the debugger. I loved that.

I hope the screenshot clarifies what I am trying to say.

Cheers,
Francisco

----- Original Message -----
From: "tim Rowledge" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Thursday, January 31, 2008 12:22 AM
Subject: Re: Editing class method sources in single place

"tim Rowledge" <[hidden email]> wrote
>>> - edit window splitting , when you need to code something, while
>>> referring to other methods/sources.
>>
>> This is one good scenario of use where todays browser is not  efficient.
> That's exactly where having many browsers open at once is a big win.

Compared to having just one similar browser - certainly.

> I  typically have 5 - 10 browsers open. A couple where I might be in the
> midst of editing, a couple open on related methods, some available for
> looking up stuff. I've been doing it that way since a 640*400 screen  was
> a luxury. Why add the complication of window splitting when it is  merely
> a poor attempt at what we already have?

Everything you say is true and objective, except perhaps "complication" and
"poor attempt". Why doesn't everyone just mouse + keyboard + search around
using separate general-purpose browser windows for all tasks? Why do people
like hierarchy browsers for some purposes? Or senders and receivers? Or
chasing variations of these? Or the refactoring browser?

If I consider an open browser, or collection of browsers, as a working
context for the task I am focused on this moment (a reasonable approach to
usability); then, if I consider
 - what I want to accomplish in that task,
 - what things I want to see and do,
 - what other things I have to see and do (including selection clicks, menu
actions, moving between windows, number of repeated panels with similar or
identical lists of categories, classes, protocols, methods, action
buttons...),
I see several scenarios where the general purpose tool of multiple browsers
can be improved.

All from a newbies perspective ... but sometimes both newbies and
ThoseInTheKnow bring useful old as well as fresh views of things.

Thanks - Sophie

"Francisco Garau" <[hidden email]> wrote
> I hope the screenshot clarifies what I am trying to say.

Absolutely, thank you. Even better would be to have all the torn-off bits
available in one "working context" (such as a window) that you can minimize,
maximize, close, etc. as one unit. Traditional file-based split editor
windows are not the only alternative to N open browsers.

Perhaps the new OB framework makes these more doable?

- Sophie

Hi sophie, did you see Dolphin Smalltalk? It has what they call the *idea
space* which group all the ST tools in one system window. It sound nice at
first, at least to me was attractive but I quickly gravitate again on having
my N system browsers and never used the idea space again.

I think that for experienced users there is information on the way they
accommodate the windows in the screen area. Sometimes you make a little
portion of the transcript to be seen very low under N other windows just to
monitor if something has moved without loosing much really useful area. N
details like that can be observed in users.

It's a little like trying to find a way to organize the way we use the
objects on the desk (the phisical one). I'm more and more minimalistic on
that subject.

Cheers,

Sebastian

On Wed, 30 Jan 2008 16:22:30 -0800, tim Rowledge <[hidden email]> wrote:

> Many browsers open at once solves that problem much more effectively.

I find that I: a) run out of screen space quickly; b) need to revert to  
the mouse to switch browsers; c) if I try solve (a) by collapsing, I end  
up with even more mouse clicks at (b). Maybe there's a hot-key for  
switching conveniently that I'm missing, but in my experience ST is pretty  
keyboard hostile.

Something like what John Hyland describes--stack based, so that the window  
shows the latest methods you've been working on--seems like it would be  
very useful, and having a single screen of code (that could actually be  
debugged, so you could look at how the code moves without the visually  
distracting flipping that occurs) would be very useful for teaching.

Conceptually, this wouldn't even need to be that different from the  
regular browser, really, just a browser that showed code from more than  
one method at once.

Jason Johnson wrote:

"Just an observation of human nature.  Someone comes into something new
and assumes it's just like something else they know and can be used
the same way.  They hit little bumps here and there but not enough to
make them stop and think.  It's not until the crash into a brick wall
that they stop and either (a) assume this new thing sucks, leave it
and never look back or (b) realize maybe things are different here and
go out and learn the new thing."

        You say this almost like it's a bad thing. It's only bad when people do  
(a), and if they do (a) anyway, moving the brick wall up so that they hit  
it right at the beginning makes it more likely that they're going to think  
that it sucks, because there's not enough time for anything new to  
insinuate itself in to their thought processes.

        I love Smalltalk: It's informed my programming for 15 years now. But it  
does not suit the way I work at all. I write tiny little routines and  
objects in all the languages I work in (even in procedural languages) but  
I can write a lot more a lot quicker if I don't have to take my hands off  
the keyboard.

        ===Blake===