HDTenEightyP/NetNews huggingface dataset:
From: rick@rick.infoserv.com (Rick Klement)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 15 Aug 92 16:43:56 GMT
Organization: Rick's Place, San Jose, CA, USA

In article <5734@vexpert.dbai.tuwien.ac.at>, mst@vexpert.dbai.tuwien.ac.at (Markus Stumptner) writes:
> From article <52.30198@rick.infoserv.com>, by rick@rick.infoserv.com (Rick Klement):
> > In article <5720@vexpert.dbai.tuwien.ac.at>, mst@vexpert.dbai.tuwien.ac.at (Markus Stumptner) writes:
> > Well, the cost is independent of the benefit, you're talking value. 
> 
> I would say a evaluation based on cost alone is not useful.  Whenever
                                    ^^^^^^^^^^^^^^^^^^^^^^^^
I agree (and always have) ...

> you look at a feature, you look at the tradeoffs you incur by using
                                         ^^^^^^^^^
Of course...

> it, but that's always value, not cost alone.
> 
> > I didn't say that. I'm just saying that the costs should be understood
> > and evaluated before a choice is made.
> 
> I agree, but you DID talk about evaluating Smalltalk (which
> generalizes to any OO language), based on COST, and not VALUE, of
> inheritance.  I don't agree.

I don't agree either. What I didn't say was that benefits should be
understood and evaluated also (I just assumed this.)

> >> think), but that doesn't remove the problem completely.  Still makes
> >> it easier than doing without.
> > Maybe, maybe not. Evaluation before judgement.
> 
> Good point, I do not have a formal evaluation of the effects of
> inheritance on software reuse.

Neither do I. I strongly suspect that each situation must be evaluated
separately.

This might be a good topic for a research paper. I would like to see
this researched, rather than blindly accepted as a good thing.

> > [parts not superseded] + [parts you write] + [parts you override*]
> > seems like the whole chain to me...
> 
> No, because it may be sufficient to look at a projection of that chain
> (i.e., a flattened view).  Of course, that is a again a question of
> good design.

Then again, it may _not_ be sufficient to look at a projection. You
probably can't tell without looking at the whole chain :-)
-- 
Rick Klement - email:   rick@infoserv.com

#include <standard.disclaimer>
RULE #6: When you can say something in a positive way or a negative way,
         don't say it in the negative way.
Newsgroups: comp.lang.smalltalk
From: muhr@opal.cs.tu-berlin.de (Thomas Muhr)
Subject: Re: which smalltalk for the mac?
Organization: Techn. University of Berlin, Germany
Distribution: fb20
Date: Fri, 14 Aug 1992 06:50:20 GMT

chang@alc.com (Seyho Chang) writes:

>This is Smalltalk discussion forum. Not stupid religious war about
>which language is better (Smalltalk vs. C++, or Smalltalk vs. Prograph).
>If you want discuss advantages of Prograph, create your own newsgroups.
I think that one major topic in discussing a language X is to relate
it to other languages and show the advantages/disadvantages of the one
or the other.
>No language is better than other languages.  
This can only be stated from a very theoretical standpoint (Turing
equivalence of formal languages).
>Selection of development
>language is depends on application type and how your want to develop
>your systems.
So there are criterions how to scale languages at least?
I found the mentioning of ProGraph quite interesting, because
sometimes I think I am too deeply involved with Smalltalk (which
frequently turns out to be real SeriousTalk), not recognizing
alternatives very easily.
- Thomas

--
Thomas Muhr - Project ATLAS - Technical University of Berlin
voice: +49 30 314 27882  
BITNET: muhrth@db0tui11  INTERNET: muhr@cs.tu-berlin.de
Compu$erve: 100013,377
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.smalltalk
Date:         Thu, 20 Aug 1992 12:42:18 +0200
From:         "GWDGV1::JRADE1" <jrade1@GWDGV1.DNET.GWDG.DE>
Subject:      RE: Need Help Implementing a Component on Small Talk in a Course

On: Wed, 19 Aug 1992 11:19:00 EST,
"Tom Cunningham, Computer Science Department" <TPC@IUP.BITNET> wrote:
> ... I would like to introduce Small Talk using about six class hours
(currently I am covering objects in Turbo Pascal).

Computerscience is not where I'm started from and I had no teacher,
and I took me quite some time to understand even the basic concepts of
oo-programming. But having well prepared courses an a thourough basis
to build on may help. Please don't get me wrong - I don't want to
discourage your project - just have apropriate goals for your
participants. I would like to read your and other peoples
experiences in teachning ST.

>     I need the name and phone number of suppliers of inexpensive PC based
>Small Talks.  (The department will purchase several copies.  The students will
>_not_ be buying individual copies.)
>
>     If there are several PC based Small Talks available, I would appreciate
>suggestions, hopefully including reasons, as to which one I should purchase.
>
>     I need suggestions regarding inexpensive introductory textbooks for Small
>Talk.  (Remember these students are already buying a "Programming Languages"
>textbook, $50 - $75.)  If possible, please supply title, author, and publisher.

There is a PD implementation of ST, called Little Smalltalk by Timothy Budd.
It's available from the archives (Illinois, st.cs.uiuc.edu & Manchester,
it's Internet name escapes me). Mr. Budd also has a nice textbook which is
significantly lower priced than the Addison-Wesly series. I think it's
titled "Little Smalltalk" also.
LST has no GUI (as far as I know).

You may also consider ST/V DOS ($99) and ST/V 286 ($199) by DigiTalk Inc.
Both have GUI and a Debugger. The Textbooks that come with it are not
sufficient for learning ST. Try to contact Dan Goldman at
71361.1636@compuserv.com .

There is also Objectworks/Smalltalk by ParcPlace (formerly ST-80). They
have implementaions for Windows and OS/2. You have to spent some $$ for
good monitors, or you may not be able to read the text inside the windows
:-(((. They have educational discounts. ParcPlace is listening here.

As textbook I would recommend the socalled BlueBook: Smalltalk 80 -
The Language and it's Implementation, by Adele Goldberg, Addison Wesley.
But it's out of print now. The successor is: Smalltalk 80 - The Language,
same autor, same publisher (Purple Book).

>     Thank you for your time.

You are wellcome. Since your question is a FAQ, please summarize and submit
it for the FAQ file.

Good luck - Joerg
Newsgroups: comp.lang.smalltalk
From: brent@uwovax.uwo.ca (Brent Sterner)
Subject: Yet Another Beginner's Question...
Organization: University of Western Ont, London
Date: Wed, 12 Aug 1992 17:37:36 GMT

   Me again with another beginner's question.

   I have the following code fragment in the displayOn method for a view:

		(self graphicsContext)
			paint: ColorValue black;
			displayRectangle: graphBar.

   I would like to vary the colour from black to other colours, depending
   on various conditions.  I cannot get the simplest case to work:

		| colour |
		colour := black.

        	(self graphicsContext)
                	paint: ColorValue colour;
	                displayRectangle: graphBar.

   I'm told 'colour' is a new message.  I guess it is, but the concept
   eludes me.  Your help is again appreciated.  Thanks,  b.
--
Brent Sterner                       Manager, Academic Technical Support
Fast:       <BRENT@uwo.ca>          <129.100.2.13>
Telephone:  (519)661-2151 x 6036    Fax:   (519)661-3486
Slow:  Computing & Communications Services, Natural Sciences Building
       The University of Western Ontario, London, Ontario, Canada  N6A 5B7
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 12 Aug 92 16:40:08 GMT
Article-I.D.: m.1992Aug12.164008.15220
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL

robert@metropolis.com (Robert Munyer) writes:


>You explained the problem with what she's doing, but didn't explain how to
>avoid it.  So, how about it?  How can you make it impossible to get an un-
>initialized instance of an object, without having to understand the entire
>superclass chain that you're inheriting?

You don't have to understand the entire superclass chain, but you have
to know something about any superclass that you are inheriting.  This
is true whenever you make a subclass; if you don't know anything about
a class, why are you subclassing it?

The real question is: what do you have to know about a class to make a
subclass of it?  In general, you have to know about the methods that
you are expected to override.  If the superclass overrides "new" so
that it can send "init" to a new instance then you need to know that
you need to override "init" to initialize your variables.  You also
need to know that you should probably call the inherited version of
init, i.e. you should write init as

super init.
"initialize all the variables declared in this class"
From: rick@rick.infoserv.com (Rick Klement)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 15 Aug 92 16:07:36 GMT
Organization: Rick's Place, San Jose, CA, USA

In article <1992Aug14.181242.19096@m.cs.uiuc.edu>, johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
> rick@rick.infoserv.com (Rick Klement) writes:
> 
> >3) You absolutely must pay the cost for understanding the superclass
> >chain. Ignorance is not bliss, mostly it's a recipe for disaster.
> 
> Strictly speaking, this is not true.  You must pay the cost for understanding
> the specification of the superclass.  If the specification has been written
> well then you will NOT have to understand the superclass chain.  Unfortunately,
> most Smalltalk classes are not specified, and you have to understand their
> specification by looking at their implementation and reverse engineering
> them.  Their implementation is made up of the superclass chain.  Thus, in
> practice you have to understand the superclass chain, but that wouldn't be
> necessary if the classes were documented properly.

You started out saying "this is not true", then spent the second half
of the paragraph tearing down your own argument ?????

If the specification has been "written well" _and_ if it is "exactly
correct" then the cost of understanding may be reduced. These could be
the world's two largest "if"s.  However, you still have to pay the cost
of verifying that the specification _is_ "exactly correct".

I never had the luxury of being able to say "This is not well
specified, so I don't have to work on it. I will give the developer a
grade of "F" and wash my hands of it." Some of us have to make things
work.

> Thus, in practice you have to understand the superclass chain,

Thank you for stating my argument so well.

-- 
Rick Klement - email:   rick@infoserv.com

#include <standard.disclaimer>
RULE #6: When you can say something in a positive way or a negative way,
         don't say it in the negative way.
From: peskin@cesl.rutgers.edu ( R. Peskin)
Newsgroups: comp.lang.smalltalk
Subject: Re: which smalltalk for the mac?
Date: 12 Aug 92 16:51:23 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

Notice that I said "IF you have to use Smalltalk (on a Mac)..". There is 
little question in my mind that Prograph is far superior to Smalltalk for
the Mac. The rumor we hear is that there will be Unix/X Prograph in the not
too distant future. Another feature is that Prograph is a data flow system
with syncho operators. This makes it good for prototyping for parallel
computing.

--dick peskin
From: bushell@fox.nstn.ns.ca (Tom Bushell)
Newsgroups: comp.lang.smalltalk
Subject: Re: catalog of classic bugs
Date: 13 Aug 92 20:35:49 GMT
Organization: NSTN Network Operations Centre, Nova Scotia, Canada

Ralph,

Thanks for the catalog of classic bugs.  I think
this will be a real service to many of us on this newsgroup.

-Tom Bushell
From: jrade1@GWDGV1.DNET.GWDG.DE (GWDGV1::JRADE1)
Newsgroups: comp.lang.smalltalk
Subject: designing an OO language (Was: Re: Yet Another Beginner's
              Question...)
Date: 17 Aug 92 11:26:36 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

On: Thu, 13 Aug 1992 07:59:36 GMT,
Robert Munyer <robert@METROPOLIS.COM> writes:

>[Note to the experts out there:  I am designing an OO language that does not
>have this feature -- variables can be used as messages, in which case the value
>of the variable determines which message will be sent.  Do you think I am
>making a mistake?  Is there something I don't know about that will bite me?]

I wouldn't term myself an OO-expert, but from what I've learned through
previous postings to this newsgroup, your design would make all instance
variables of your classes accessible to all other code. This would
contradict the objective of encapsulation. ST uses explicit coded
messages to access instance variables instead. A workaround would be
using import/export restrictions. But then your original intentions are
not met?
I'm not quite shure wether I understood you right, what do you exactly
mean by "the value of the variable determines which message will be sent"?

- joerg rade
From: scrl@otter.hpl.hp.com (Simon Lewis)
Date: Thu, 13 Aug 1992 07:15:11 GMT
Subject: Re: catalog of classic bugs
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.lang.smalltalk

In comp.lang.smalltalk, johnson@m.cs.uiuc.edu (Ralph Johnson) writes:

> Classic Smalltalk Bugs

> Neither Smalltalk-80 nor Smalltalk-V return to the sender when a
> new window is opened in a standard fashion.

Not any more.  In Objectworks\Smalltalk release 4.1 (what you're calling
Smalltalk-80), open now does return, so...

> aScheduledWindow1 open.
> aScheduledWindow2 open
 
...now works as you might expect.

Simon.
From: irvine@ntmtv.UUCP (Chuck Irvine)
Newsgroups: comp.lang.smalltalk
Subject: ST/V Win - MDI-debugger-bug
Keywords: MDI, ST/V Win, Bug, Debugger
Date: 17 Aug 92 19:12:02 GMT
Organization: Northern Telecom Inc, Mountain View, CA

When I'm in the MDI mode using ST/V for Windows (2.0), 
the bebugger intermittantly hangs. The window has no
mouse sensitivity or any other functionality that I've noticed.
The only escape is to close the debugger window. The
problem can occur when a bug is encountered and also after
I've inserted a "self halt" message. I can reproduce
the problem at will.

Has anyone else seen this problem? Or better yet, anyone know
of a fix? I otherwise really like the MDI mode. Any
help appreciated.

Chuck Irvine
ames!ntmtv!irvine
Northern Telecom
From: khaw@parcplace.com (Mike Khaw)
Newsgroups: comp.lang.smalltalk
Subject: Re: Yet Another Beginner's Question...
Date: 14 Aug 92 18:25:46 GMT

In <1992Aug12.133736.1@uwovax.uwo.ca> brent@uwovax.uwo.ca (Brent Sterner) writes:

->   I would like to vary the colour from black to other colours, depending
->   on various conditions.  I cannot get the simplest case to work:

->		| colour |
->		colour := black.

->        	(self graphicsContext)
->                	paint: ColorValue colour;
->	                displayRectangle: graphBar.

->   I'm told 'colour' is a new message.  I guess it is, but the concept
->   eludes me.  Your help is again appreciated.  Thanks,  b.

Instead of
		colour := black.
		...
		ColorValue colour.
use
		colour := #black.
		...
		(ColorValue perform: colour)
--
Michael Khaw	Domain=khaw@parcplace.com, UUCP=...!uunet!parcplace!khaw
ParcPlace Systems, Sunnyvale, CA	PRODUCT INFO: info@parcplace.com
From: rick@rick.infoserv.com (Rick Klement)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 12 Aug 92 19:36:12 GMT
Organization: Rick's Place, San Jose, CA, USA

In article <Bstq9M.I9K@metropolis.com>, robert@metropolis.com (Robert Munyer) writes:
> In article <47.23492@rick.infoserv.com> rick@rick.infoserv.com (Rick Klement)
> writes:
> 
> > In article <iLc8oB3w165w@toz.buffalo.ny.us>, nicted@toz.buffalo.ny.us
> (Nicole Tedesco) writes:
> 
> > > Now, I admit I am new to Smalltalk (I LOVE it, by the way!) and I'm still 
> > > "feeling my way around."  If I am doing something dreadful, please let me 
> >                                                     ^^^^^^^^
> > Well... sort of.
> > 
> > You make it possible to get an un-initialized instance of an object.
> > This violates encapsulation, forcing the programmer to "do the right
> > thing", instead of giving him/her no option but the correct one.
> > 
> > Basically, you have to understand the entire superclass chain that you
> > are inheriting. If _any_ superclass does ^super new initialize, then
> > you don't have to (pronounced 'shouldn't).
> 
> You explained the problem with what she's doing, but didn't explain how to
> avoid it.  So, how about it?  How can you make it impossible to get an un-
> initialized instance of an object, without having to understand the entire
> superclass chain that you're inheriting?

You probably can't make it impossible (as in 'basicNew') but it seems
as if 'new' is always expected to do the initialization, as a
'convention' rather than an enforced standard. Providing a 'new' that
doesn't initialize may confuse 're-users' of your class.

This still does not free you from the requirement of understanding the
entire superclass chain. I don't see any way around that. Inheritance
is not free, or particularly easy, there is a cost associated with it
(time, effort, understanding, etc...). This cost may (or may not) make
Nicole's LOVE for Smalltalk wane eventually, when she realizes all the
implications of the language.

Summary (after only 2 paragraphs?):

1) 'MyClass new' should return an initialized object.

2) You can't prevent someone from getting an uninitialized
object('basicNew'), but don't make it easy(see 1).

3) You absolutely must pay the cost for understanding the superclass
chain. Ignorance is not bliss, mostly it's a recipe for disaster.
-- 
Rick Klement - email:   rick@infoserv.com

#include <standard.disclaimer>
A respected software manager once said: "There may even be some
Computer Science graduates that can actually do useful programming." or
something like that. I know who but I'm not telling...
Newsgroups: comp.lang.smalltalk
From: irvine@ntmtv.UUCP (Chuck Irvine)
Subject: shareware/public domain ST/V Win code
Organization: Northern Telecom Inc, Mountain View, CA
Date: Tue, 18 Aug 1992 17:30:34 GMT

I wondering if there are sources of public domain or shareware
source code for ST/V Win? I'm interested in anything. If anyone 
knows of any I'd certainly appreciate information on how to
access it. Thanks much.

Chuck Irvine
ames!ntmtv!irvine
Northern Telecom
Newsgroups: comp.lang.smalltalk
From: dpbsmith@world.std.com (Daniel P. B. Smith)
Subject: Smalltalk/V-PM: yeah, but why CRASHES?
Organization: The World Public Access UNIX, Brookline, MA
Date: Sat, 15 Aug 1992 12:41:16 GMT

What I'm really after here is flame bait for the OS/2 advocacy group.
For about two years, around 1990-1991, I was using Smalltalk on an
experimental project and had a real love-hate relationship. Smalltalk
itself is the most delightful environment I've ever used. I'm simultaneously
grateful to Digitalk for making it available at an affordable price, and
annoyed at general bugginess.  

The bulk of the work was done in ST/V-Mac. We intended to port it to
Windows, and for about three months before ST/V-Windows was available, I 
was using ST/V-PM as a bridge.

Anyway, the question I have is this. This was ST/V-PM 1.0 or 1.1 and OS/2
1.21.  When I made stupid mistakes, I was CONSTANTLY locking up the system
so badly that a reboot was required.  To listen to OS/2 advocates, you'd
think that even if my code was buggy (which it surely was), and even if
Digitalk's was buggy (which it surely was, though not as buggy as mine) ...
it STILL isn't supposed to crash the OS itself.

Now I'm reading that others (specifically Marten Feldtmann) are experiencing
the same thing.

So, what's going on? Is this a legitimate knock on OS/2?  Are the OS/2
advocates who tell me it doesn't crash like the PC owner who told me he
had never had any problem with it... so I asked him to demo it for me ...
and he said, "Oh, I can't until I get the new power supply -- the old
one burned out..."  And I said, "but you said you'd never had any problems
with it..." and he says, "I haven't had any problems at all with the
computer itself, this is just the POWER SUPPLY..."



-- 
Daniel P. B. Smith
dpbsmith@world.std.com
From: irvine@ntmtv.UUCP (Chuck Irvine)
Newsgroups: comp.lang.smalltalk
Subject: Modifying Class Hierarchy Browser titles
Keywords: ClassHierarchyBrowser, label, title, MDI
Date: 17 Aug 92 19:37:31 GMT
Organization: Northern Telecom Inc, Mountain View, CA


I typically have several class hierarchy browsers open at
the same time. To be able to distinguish between them, it
would be nice to have the title bars of the windows say
more than just "Class Hierarchy Browser". For example, they
might be labelled "Class Hierarchy Browser | Object->hash", 
indicating that I'm currently browsing the "hash" method of "object".
Also, when in MDI mode, it would be very helpful to have these
more descriptive titles displayed in the pull down "Windows" 
menu. 

I would be very thankful to anyone that could lend me help in
doing this. Actually, I think it would be a helpful addition to
the product.

Thanks

Chuck Irvine
ames!ntmtv!irvine
Northern Telecom
From: marten@feki.toppoint.de (Marten Feldtmann)
Newsgroups: comp.lang.smalltalk
Subject: Re: Digitalk ST/V-PM:
Distribution: world
Date: Fri, 21 Aug 92 18:32:42 GMT
Organization: Private Site

tom.koschate@rose.com writes in article <1992Aug16.211721.3062@rose.com>:

> Sorry, it causes no problem for me.  Try this fix that is part of a 
> group posted on Compu$erve by Digitalk:

 Well, that fix solved my problems. It would be interesting to get all
the other patches as well :-))))

 MF

--
Marten Feldtmann                         E-Mail: marten@tpki.toppoint.de
2300 Kiel 14,    Kieler Str. 29,   Tel.: 0431-731916,   FAX: 0431-737677

Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.smalltalk
Date:         Fri, 14 Aug 1992 18:25:50 +0200
From:         "GWDGV1::JRADE1" <jrade1@GWDGV1.DNET.GWDG.DE>
Subject:      RE: Yet Another Beginner's Question...

On: Wed, 12 Aug 1992 17:37:36 GMT,
Brent Sterner <brent@UWOVAX.UWO.CA> wrote:
>   I would like to vary the colour from black to other colours, depending
>   on various conditions.  I cannot get the simplest case to work:
>
>		| colour |
>		colour := black.
>
I'm assuming you are working in ST/V Mac (which I do not know). ST should
have barked here, if black is neither instance variable nor a local
variable. You are coding in a Workspace, aren't you?
>
>        	(self graphicsContext)
>                	paint: ColorValue colour;
>	                displayRectangle: graphBar.
>
>   I'm told 'colour' is a new message.  I guess it is, but the concept
>   eludes me.

ST is trying evaluate 'ColorValue colour'. It sends the message colour
to the object 'ColorValue'. This is either a class or a global variable
containing the instance of a class. To inquire about this evaluate:
'ColorValue inspect'.
If it's a class, try 'ColorValue browse'. It should then have defined
some class method that can take an argument in the form of: 'colour:
anInteger'. If 'ColorValue'is an instance of a class, look for a similar
instance method. Try '*className* browse'.
> Your help is again appreciated.  Thanks,  b.
You are wellcome. Hope this is of any help. - joerg
From: tigre@netcom.com (Jordan Bortz)
Newsgroups: comp.lang.smalltalk
Subject: Re: Tigre email address
Keywords: tigre
Date: 14 Aug 92 21:55:51 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

>Does anybody know the new email address of tigre ?
>The address in their manual is not valid anymore.


Our Email address has changed.  It is now: tigre@netcom.com


	Jordan

-- 
Jordan Bortz, tigre@netcom.com 408 427 4900
Newsgroups: comp.lang.smalltalk