|Anonymous | Login||01-17-2020 18:19 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0001541||[Squeak] Tools||feature||always||07-25-05 23:26||07-25-05 23:40|
|Summary||0001541: [ENH] sandboxCategory-ls|
"Change Set: sandboxCategory-ls
Date: 10 September 2003
Author: Lex Spoon
Adds a 'Sandbox' system category and puts a 'Scratch' class in it. This
way, there is a quick place to put methods and classes that have not yet
been categorized. It should lower the number of concepts required for a
new user to do things in Squeak.
This changeset also tweaks the browser so that it chooses the Scratch
class automatically if no other class has been specified."
|Attached Files||sandboxCategory-ls.cs.gz [^] (870 bytes) 07-25-05 23:26|
(0001930 - 123 - 163 - 163 - 163 - 163 - 163)
"I like this.
This will make a new-users tutorial much simpler... anybody against
(0001931 - 163 - 203 - 245 - 245 - 245 - 245)
"I'm not convinced that this is different that any other class in the
Why this empty would help. I doubt about that."
(0001932 - 2400 - 2785 - 2867 - 2867 - 2867 - 2867)
"Lex Spoon" <firstname.lastname@example.org>:
"Let me first repost my earlier message, from the thread "Documentation,
more, more" back in September:
"mwgrant2001" <email@example.com> wrote:
> I ENVISION MYSELF FALLING INTO A WOODY ALLEN-ESQUE NEUROTIC
> PARALYSIS, UNABLE TO ACT ON ANY MATTER AS I WORRY OVER WHERE TO PUT
> ANY CLASSES I MIGHT DEVELOP!
I wouldn't have thought of that particular problem. Perhaps we should
add an empty category to the browser and put it at the top of the list.
It could be called something like "Sandbox". Every little bit that can
be shaved off of the initial user experience is helpful.
Okay, I've programmed it. It's in my next message.
The basic idea is to let people make decisions in whatever order they
like. I hate the break in flow that comes in Squeak when I am forced to
name a class and put it in a category before I can do anything with it.
Sometimes my thought is simply "I want an object holding a Foo and a
Bar". If it's the first class in a project, then I have to think up a
category name as well. If there is a Sandbox category available, I can
simply stick everything in there until I am ready. Similarly for the
class and methods.
For newbies, like the person I responded to, the situation is even
worse. Every step is harder for a newbie, and every step shaved is a
Tutorials should be benefited as well. Now they have the option of
telling people to stick code right into the Scratch class instead of
having them open a browser, do "add item", create a class, etc. That's
a lot of little steps when you stop and consider it!
Finally, to help your intuition, please consider what Squeak should look
like if we consider code as the document and the browser as an
application that edits that document. In most such software, the editor
starts up viewing a scratch document where users can immediately start
scribbling. Consider word processors, spreadsheets, drawing programs,
music notation generators, movie editors, .... Consider these programs
both with and without an automatic scratch area, and I think you'll
agree that it is nice to have an automatic scratch area pop up when you
start the program."
(0001933 - 126 - 160 - 202 - 202 - 202 - 202)
"ok you convinced me
Just a point for me scratch does not tell me anything except a noise"
(0001934 - 1659 - 1755 - 1798 - 1798 - 1798 - 1798)
Michael Grant <firstname.lastname@example.org>:
"Being the newbie the Lex refers to below I can only say that he states the case well from my perspective.
One of the touted aspects of smalltalk is how you can modify your environment and indeed the SM image. Well, I'm an old newbie with some experience with other languages and environments. So now I hit SM and am told "oh yeah, just go in and modify the SYSTEM, create this, and create that, and just start stuffing things into the image. If you don't like it then move it, go to the changeset or whatever...there are alternatives. Of course this is a very power capability, but I rather minimize time undoing and maximize time doing, as any of us would.
But if I get cute and start putting new subclasses, etc., under different categories and classes without a modicum of understanding (which comes only with experience) I could really make a mess of the image. For example, be it bad practice or whatever, in my first dalliances with Squeak I tended NOT to create new classes but to extend the existing ones. For example adding some statistical methods to Collections. It just seemed natural to do it that. But this soon made me uncomfortable--because I would never easly undo all the changes I might sprinkle thru the system--changeset or not. So you see, I needed some people like Lex, Dan, and Richard to give a little advice. Lex went a little further and sort of said 'people like you need a place to play, while you SORT things out.'
Learning SM is like anything else--there is a good deal of bootstrapping involved. But first you gotta find the laces.
Lex makes some good arguments."
(0001935 - 232 - 282 - 321 - 321 - 321 - 321)
"Richard A. O'Keefe" <email@example.com>:
"I'm already quite fed up with the amazing number of methods in
the 'as yet unclassified' category; I'm not looking forward to
a matching number of classes in a similar class category."
(0001936 - 691 - 789 - 828 - 828 - 828 - 828)
"Lex Spoon" <firstname.lastname@example.org>:
"Heheh, yes indeed. It seems like the same thing. But do you really
want to disallow 'as yet unclassified' methods? I wouldn't like that,
myself. And I like having a class and category around to muck in.
While these things should be cleaned up eventually, that doesn't mean we
should disallow them initially. A better fix, IMHO, would be to add a
file-out nagger for it.
Actually, I've been thinking that there should be more of these
auto-classes and auto-categories. Specifically, shouldn't each project
get its own category? And why not stick a class in there as well. It
gets complicated when someone renames a project, though...."
(0001937 - 1815 - 2131 - 2209 - 2209 - 2209 - 2209)
"Richard A. O'Keefe" <email@example.com>:
""Lex Spoon" <firstname.lastname@example.org> replied:
But do you really want to disallow 'as yet unclassified' methods?
I have made it a rule in my Smalltalk programming *never* to perpetrate
an 'as yet unclassified' method myself. Once or twice when I was getting
started or felt really lazy, I did that. Mea culpa, mea culpa, mea
maxima culpa. Never again. The only reason I can see for not classifying
a method that you are about to write is because you don't know what it is
going to be about, and in that case, why are you writing it? As a _reader_
of Smalltalk, I find 'as yet unclassified' methods such a pain (not least
because they are usually without any helpful comments either) that YES
I darned well WOULD like to disallow 'as yet unclassified' methods.
There is _always_ something better to put a method under than
'as yet unclassified'. If nothing else, 'unclassified command' -vs-
'unclassified query' would be a clue about whether the thing was supposed
to change the receiver's state or not.
And I like having a class and category around to muck in.
When I'm working with students, it's nice if _they_ are using
class category 'JoeStudent-461' and _I_ are using 'ROK-461' so that
I can file their mucking-around category into my image and vice versa.
If we all mucked around in the same category it wouldn't be so nice.
Creating a class category and a class is a good beginning exercise in
using a Browser.
My daughters are nearly five and a bit over seven and a half.
It's so _easy_ to do everything for them; it feels so unkind to
insist "YOU can do that. No, you CAN do that. You'd be surprised
what you can do. Go on, try." It is not clear to me that it is a
kindness to provide "canned" "no-brainer" defaults."
(0001938 - 872 - 1057 - 1096 - 1096 - 1096 - 1096)
""Richard A. O'Keefe" <email@example.com> wrote:
[SNIP of stuff I agree with, even though sometimes we just forget to
But personally I always try to go through my classes and categorize +
write the class comments before making proper releases.
> My daughters are nearly five and a bit over seven and a half.
> It's so _easy_ to do everything for them; it feels so unkind to
> insist "YOU can do that. No, you CAN do that. You'd be surprised
> what you can do. Go on, try." It is not clear to me that it is a
> kindness to provide "canned" "no-brainer" defaults.
This is indeed a point.
Though if some people really want this feature I am ok with getting it
in - we need to be smooth sometimes. And if it starts bothering people
enough - someone is bound to add a Preference for it or something. :)"
(0001940 - 2308 - 2609 - 2648 - 2648 - 2648 - 2648)
"Lex Spoon" <firstname.lastname@example.org>:
"What a deep difference we have. I make it a rule never to let a naming
problem stop me, and I write code all the time with only hazy initial
ideas. I like being able to dump my ideas into code and then play with
them. I wait until a later phase to clean things up, name them nicely,
fix up the categories, and generally make the code nice to read.
In fact, I used to have a serious problem with naming. I realized I was
actually failing to write down various code snippets because I couldn't
think of an appropriate file name to put the code in. I forced myself
to start using names like "temp" for such experiments, because otherwise
they wouldn't get written at all. If the code lived for more than a few
minutes then I would *later* think up a good name for it. But if I just
wanted to execute 4 lines of code, why do I have to stop to think up a
good name? Why should I?
Similarly, I've always been annoyed at having to think up a class
category name before making a Squeak class. I'm sure there's been code
I didn't write because I didn't want to bother with this.
Anyway, there is an additional problem: good naming and categorization
is HARD. A bad name takes at least one chunk of working memory. A good
name is likely to take much more, and leave you afterwards saying "now
what was I doing again... ah yes." This doesn't seem like a good thing
to force into the flow of development. Squeak should be a place where
people can experiment and mess around. I think Squeak should allow
people to dump ideas into code as quickly as possible. Cross the t's at
a later time.
In fact, I would actually like to Squeak move further in this direction.
I wish, for example, you could easily create *new* classes and methods
without specifying a name. I'd like the browser to always open on a
fresh class, and I'd like a way to type in some code and get
"unnamed143" as the selector name.
But, there's clearly a divide. I have no idea how to resolve this.
Goran's idea of a preference sounds all too realistic. What would it be
called? #instaNag? #tidyEnforcement? #sloppyProgramming? If we think
of a good name it might combine several others, e.g. #sloppyProgramming
might cause #autoAccessors to turn on."
(0001941 - 907 - 1030 - 1071 - 1071 - 1071 - 1071)
"Andreas Raab" <email@example.com>:
"> What a deep difference we have.
Funny thing to read for me, given that I agree with _both_ of you. How so?
Well, for just coding some idea I certainly don't want to think about names
and such. In this regard I'm with you. But for looking at and browsing
Squeak I hate to see unclassified methods, unclear names etc. That's because
I don't know what ideas were behind the code in question when it was
written, and a classification plus names helps greatly in understanding
other people's code. So my rule of thumb would be: As long as you're on your
own, do whatever you want. You want a quick hack? Go for it. But as soon as
you start sharing (which includes sending a CS around) I'd argue that things
should be classified by then. Or put differently: Nothing that ships with
"official Squeak" should have unclassified methods or non-descript names."
(0001942 - 1005 - 1200 - 1242 - 1242 - 1242 - 1242)
Doug Way <firstname.lastname@example.org>:
"Andreas Raab wrote:
> ... So my rule of thumb would be: As long as you're on your
> own, do whatever you want. You want a quick hack? Go for it. But as
> soon as
> you start sharing (which includes sending a CS around) I'd argue that
> should be classified by then. Or put differently: Nothing that ships
> "official Squeak" should have unclassified methods or non-descript
I was thinking the same thing. We could have a rule that we won't
incorporate any classes that are uncategorized into "official Squeak".
I could add a test for this in my proposed changeset validator. So
then we could have Lex's enhancement, and Richard wouldn't have to
worry about ever seeing uncategorized classes in base Squeak. :)
(We could also have a rule about not allowing uncategorized methods,
although for some reason they don't bother me quite as much, especially
for very small classes with only a handful of methods.)"
(0001943 - 465 - 560 - 602 - 602 - 602 - 602)
"> I was thinking the same thing. We could have a rule that we won't
> incorporate any classes that are uncategorized into "official Squeak".
> I could add a test for this in my proposed changeset validator. So
> then we could have Lex's enhancement, and Richard wouldn't have to
> worry about ever seeing uncategorized classes in base Squeak. :)
This is good idea and I like the fact that no unclassified get in."
(0001944 - 76 - 98 - 98 - 98 - 98 - 98)
"What is the status of that sandboxCategory stuff?"
(0001945 - 82 - 82 - 82 - 82 - 82 - 82)
|I filed this changeset into 3.8-6665-basic and it still seems to do as advertised.|
|07-25-05 23:26||KenCausey||New Issue|
|07-25-05 23:26||KenCausey||File Added: sandboxCategory-ls.cs.gz|
|07-25-05 23:27||KenCausey||Note Added: 0001930|
|07-25-05 23:28||KenCausey||Note Added: 0001931|
|07-25-05 23:28||KenCausey||Note Added: 0001932|
|07-25-05 23:29||KenCausey||Note Added: 0001933|
|07-25-05 23:29||KenCausey||Note Added: 0001934|
|07-25-05 23:30||KenCausey||Note Added: 0001935|
|07-25-05 23:30||KenCausey||Note Added: 0001936|
|07-25-05 23:31||KenCausey||Note Added: 0001937|
|07-25-05 23:31||KenCausey||Note Added: 0001938|
|07-25-05 23:32||KenCausey||Note Added: 0001939|
|07-25-05 23:32||KenCausey||Note Deleted: 0001939|
|07-25-05 23:33||KenCausey||Note Added: 0001940|
|07-25-05 23:33||KenCausey||Note Added: 0001941|
|07-25-05 23:34||KenCausey||Note Added: 0001942|
|07-25-05 23:35||KenCausey||Note Added: 0001943|
|07-25-05 23:35||KenCausey||Note Added: 0001944|
|07-25-05 23:36||KenCausey||Reporter||KenCausey => lexspoon|
|07-25-05 23:40||KenCausey||Note Added: 0001945|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
97 total queries executed.|
57 unique queries executed.