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

In article <5720@vexpert.dbai.tuwien.ac.at>, mst@vexpert.dbai.tuwien.ac.at (Markus Stumptner) writes:
> From article <48.1320@rick.infoserv.com>, by rick@rick.infoserv.com (Rick Klement):
> > 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.
> 
> Not a question of the language, but of the "code reuse" view of
> inheritance.  Also, this is not a newly introduced problem, but rather
> a kind of residue.  Don't forget that inheritance does make a lot of
> dependencies explicit that are implicitly present in non-oo programs,
> i.e., the cost you mention above is what's left over after subtracting
                                      ^^^^^^^^^^^^^^^^

Well, the cost is independent of the benefit, you're talking value. I
think that may be situational, sometimes the cost of inheritance may be
greater than the benefit, and sometimes less.

> the benefits of inheritance.  Saying "it's bad because it doesn't
                                ^^^^^^^^^^^^^^^^^^^^^^^^

I didn't say that. I'm just saying that the costs should be understood
and evaluated before a choice is made.

> handle *everything*" means throwing the baby out with the bathwater.
> A class has an interface to the classes that inherit from it, just as
> to those that use it.  You can restrict that interface (as C++ does)
> or use tools that present a flattened hierarchy (as Eiffel has, I
> think), but that doesn't remove the problem completely.  Still makes
> it easier than doing without.
     ^^^^^^^^^^^^^^^^^^^^^^^^^

Maybe, maybe not. Evaluation before judgement.

> 
> > 3) You absolutely must pay the cost for understanding the superclass
> > chain. Ignorance is not bliss, mostly it's a recipe for disaster.
> 
> You don't have to understand the whole chain, but the parts that have
> not been superseded in lower classes.

Let's see...

[parts not superseded] + [parts you write] + [parts you override*]

seems like the whole chain to me...

(* You should understand at least the interfaces to the
[parts you override] to be sure you override correctly, you _are_
spared from understanding some internal details)

Once more...

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...
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Newsgroups: comp.lang.smalltalk
Subject: Re: which smalltalk for the mac?
Date: 13 Aug 92 21:45:58 GMT
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL

Kurt Hebel uses Smalltalk-80 on the Mac, and his programs look
EXACTLY like standard Mac applications.  Of course, it took him
a lot of work, and Kurt is a masterful programmer, but it
certainly is possible.  Moreover, Kurt is willing to sell his
software.   You can reach him at hebel@uinova.cerl.uiuc.edu,
or maybe just hebel@cerl.uiuc.edu.
Newsgroups: comp.lang.smalltalk
From: brent@uwovax.uwo.ca (Brent Sterner)
Subject: Re: Smalltalk FAQ - please POST it.
Organization: University of Western Ont, London
Date: Mon, 17 Aug 1992 18:20:50 GMT

In article <SMALK%92081720052606@FINHUTC.HUT.FI>,         Bor-Yea You <ASBYY@ASUACAD.BITNET> writes:
> COULD YOU PLEASE ALSO SEND ME THE FAQ? THANK YOU.

   Could the faq be posted?  And perhaps REposted periodically?  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: nicted@toz.buffalo.ny.us (Nicole Tedesco)
Newsgroups: comp.lang.smalltalk
Subject: Selling A Smalltalk Program
Date: 15 Aug 92 14:53:48 GMT
Organization: The Tower of Zot - (716)691-3865

Has anyone dealt with the problem of trying to mass-market a Smalltalk-80 
program to clients who require a large number of run-time liscenses?  Our 
(potential) clients all have big networks, and LOTS of terminals.  
ParcPlace run-times would cost our clients thousands of dollars extra.

How does one deal with this marketing problem?

Please e-mail me, as I have a hard time keeping up with this sub.
Shalome

---------------------------------------------------------------------
nicted@toz.buffalo.ny.us (Nicole Tedesco)
-- Change this!
Newsgroups: comp.lang.smalltalk
From: frerk@informatik.uni-kl.de (Frerk Meyer)
Subject: Re: Yet Another Beginner's Question...
Reply-To: frerk@informatik.uni-kl.de
Organization: AG Telematik
Date: Mon, 17 Aug 1992 11:41:05 GMT

In article <BswwvC.xn@metropolis.com>, robert@metropolis.com (Robert Munyer) 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'm far from been an expert, but my two cents are:

- If you must use the same name for the message and the variable then you are voilating
encapsulation, are you have no 'private' variables.

- In Smalltalk you can modify the method for Class creation in MetaClass so that methods for
reading and writing all variables are created by default. Classes created this way
behave like records. Therefore this behaviour is not part of the definition of Smalltalk.
You CAN do it if you like, but you don't have to.

-- 
Frerk Meyer                 Who was the most successful athlete    __o 
frerk@informatik.uni-kl.de  of the Olympic Games in Barcelona?   _`\<,_
IRCNICK = Portnoy           Ms. Anna Bolica !                   (_)/ (_)
Newsgroups: comp.lang.smalltalk
From: podenski@bcsaic.boeing.com (Patrick Podenski)
Newsgroups: comp.lang.smalltalk
Subject: Re: which smalltalk for the mac?
Date: 13 Aug 92 15:54:50 GMT
Organization: Boeing Computer Services AI Center, Seattle

In article <Aug.10.13.37.31.1992.26239@cesl.rutgers.edu> peskin@cesl.rutgers.edu ( R. Peskin) writes:
>If you have to use Smalltalk on the Mac, I suggest that you use Digitalk's ST/V 
>Mac. It maintains the Mac window paradigm (which I'm told will be available in
>emulation form with PPS 4.1), and has a better way to deal with user added
>primitives. With ST/V Mac primitives are code resources, with PPS you have to
>link a new interpreter. Both allow one to create standalone applications (but
>not without some effort). Be aware however that ST/V Mac is in serious need of
>updating. It has no color support of real use, and its no support of System
>7 goodies. An update is supposedly due by 1993.

PPS 4.1 has a greatly improved external interface in which you can call
or be called by vanilla C programs. There is a C programmers kit (extra
$)
that takes a .h file and processes it into appropriate Smalltalk code
to facilitate the C interface. This works on all PPS platforms which
include Macintosh, PC, Unix.

I have heard that PPS is unveiling a GUI builder in the next month.

ST/V Mac is definitely out of date. Still works but needs major overhaul
to be as good as the PC versions. I understand that Digitalk is putting
ST/V on selected Unix platforms by sometime around the beginning of next
year.
Newsgroups: comp.lang.smalltalk
From: brent@uwovax.uwo.ca (Brent Sterner)
Subject: Re: Cannot effect change to controller menu
Organization: University of Western Ont, London
Date: Thu, 13 Aug 1992 17:18:13 GMT

In article <1992Aug12.165803.1@uwovax.uwo.ca>, brent@uwovax.uwo.ca (Brent Sterner) writes:
>    I have just experienced a *very* strange effect in ParcPlace Smalltalk
> version 4.0 running on a sparcstation.  I have a simple counter model (which

	A bunch of people explained that st was caching the menu behind
	my back.  The problem was a class variable; I switched to an
	instance variable, and the problenm vanished.

	Thanks to "the bunch"... you know who you are.  Cheers,  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
Newsgroups: comp.lang.smalltalk
From: brent@uwovax.uwo.ca (Brent Sterner)
Subject: Cannot effect change to controller menu
Organization: University of Western Ont, London
Date: Wed, 12 Aug 1992 20:58:03 GMT

   I have just experienced a *very* strange effect in ParcPlace Smalltalk
version 4.0 running on a sparcstation.  I have a simple counter model (which
by the way I did *not* write :-) written and "distributed" by pp in their
course "Introduction to OO Concepts..." course.  I have just discovered that
I cannot change the controller menu of that model *within* st.  (I can edit
the controller menu and "accept" the change, but it does *NOT* take effect
even with a new instance of the counter model!)

   Curiously, if I "file out" the controller, physically "remove" the
controller code from the st system, and "file it in" again, the edit *does*
take effect.  Future edits remain ineffectual, however.

   This *seems* to me to be a serious system-related error, but I'm not
fluent enough with the product to know how to verify this either way.

   Yes, I'm the beginner who has authored a bunch of beginner questions
to this newsgroup already.  (Which makes me somewhat reluctant to jump up
and down over this... it may simply be another case of me not knowing enough.)
Please enlighten me.  If you've seen this (ill) effect, I'd also like to know
about it.  Thanks for whatever you can tell me.  TTFN,  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: jaeck@alc.com (William A. Jaeck)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 14 Aug 92 18:22:27 GMT
Organization: Ascent Logic Corporation, San Jose, CA

Here is a Smalltalk bug which bit me just this morning:

I had created a subclass of OrderedCollection with an instance
method called with:. This is supposed to do the same thing as
add:.

Then, I implemented a class method called with:with: as

   with: arg1 with: arg2

	 ^ self with: arg1; with: arg2

This ended up producing a result as if I had implemented it as

	^ self with: arg2

The correct implementation of with:with: is, of course

	^ (self with: arg1) with: arg2
Newsgroups: comp.lang.smalltalk
From: sticklen@cps.msu.edu
Subject: 3 button mice  and PP ST r4
Organization: AI/KBS Lab, Michigan State University
Date: Mon, 17 Aug 92 19:26:32 GMT

I am running PP ST r4.1 on a Mac. I want to be using a 3 button mouse, and to
that end, I just bought a A3 mouse. It works wonderfully for a lot of things,
but i cannot program it with <opt>CLICK and <apple>CLICK on the middle and
right buttons. 

Anyone else faced this before? Any workaround. Any other mouse I should have
bought other than the A3 mouse?

Thanks in advance,
  ---jon---

 
Newsgroups: comp.lang.smalltalk
From: robert@metropolis.com (Robert Munyer)
Subject: Re: which smalltalk for the mac?
Organization: Metropolis Software, Inc.
Date: Thu, 13 Aug 1992 06:28:52 GMT

In article <5600@vtserf.cc.vt.edu> cohill@vtserf.cc.vt.edu (Andrew M. Cohill)
writes:

> Is [Prograph] Smalltalk?  No, it's better.

Prograph is very interesting, and it seems to have a lot of potential.  But
it's not (yet?) serious competition for Smalltalk.  Its class library is tiny,
compared to what you get from Smalltalk.  More importantly, it's not really
object-oriented.  Objects communicate with each other by accessing each other's
instance variables BY NAME.  MAJOR violation of encapsulation!  It doesn't have
a real metaclass protocol, its environment is not extensible, and several
primitive data types are not objects.

Prograph seems to have been designed by someone who was a genius at dataflow
programming, but a novice at object-oriented programming.

However, it IS much better than (current implementations of) Smalltalk, when it
comes to implementing the Macintosh user interface guidelines.  Unfortunately,
I have to agree with Andrew and Dick's complaints about Smalltalk on the Mac.
I'm currently involved in a search for an OO Macintosh programming environment,
and I've had to rule out both Smalltalk and Prograph.  Currently I'm thinking
of using CLOS under Macintosh Common Lisp.  Any suggestions?

[Sorry if any of this sounds like a flame -- but surely, Andrew, you had to
expect some backlash when you said "X is better than Smalltalk" in a Smalltalk
newsgroup!  In fact, I guess I should expect some backlash from THIS article!]

______________________________________________________________________
Robert Munyer            |   "I may be synthetic, but I'm not stupid."
robert@metropolis.com    |      -- Bishop, _Aliens_
Disclaimer: this does not necessarily reflect the opinions of my employers.

Newsgroups: comp.lang.smalltalk
From: jwh@citi.umich.edu (Jim Howe)
Subject: Re: Help: Porting smalltalk code in a DLL!
Date: Tue, 18 Aug 92 16:33:58 EDT
Organization: IFS Project, University of Michigan
Reply-To: jwh@citi.umich.edu
Keywords: DLL Portability

In article <Bt6s0J.JHA@datlog.co.uk>, gbunyan@datlog.co.uk (Gordon Bunyan) writes:
|> I've recently spent a number of hours reading ST VPM 1.4
|> and ST V 2.0 manuals trying to understand if I can put a ST application
|> in a DLL for use by another programming language (eg, Visual Basic or
|> C). 
|> 
|> The manuals state quite clearly that "any procedure in any DLL is
|> callable from ST/V". However, I can't find any such clear statement
|> which say's that the converse is true -- "any procedure (method) in
|> any DLL is callable from ...".
|> 
|> The intention is to use a smalltalk application I have written to
|> manipulate data between two visual basic programs (commercially 
|> available products).
|> 
|> I have a sneaking suspicion that ST DLL's arn't REAL DLL's
|> because they don't seem to provide the facility for an API which
|> can be used by another programming language. Am I right ?
|> 

I believe you are correct.  The DLL's created by ST/VPM are real
DLL's, they just don't contain executable code.  In V/PM 2.0, the
code is stored in some internal format and then dynamically compiled
when it gets referenced.  Once compiled, it remains in a cache so
the code doesn't constantly get recompiled.  The advantage of
this approach is that the DLLs are much smaller.  The
disadvantage is that you can't directly execute the 'code' in
a Smalltalk DLL.  If you think about what happens when you
'call' a method (object creation, deletion, garbage collection, etc.)
it's not surprising that you couldn't simply call a method in
a DLL even if it were stored as machine instructions.



James W. Howe                  internet: jwh@citi.umich.edu
University of Michigan             uucp: uunet!mailrus!citi.umich.edu!jwh
Ann Arbor, MI   48103-4943
From: mst@vexpert.dbai.tuwien.ac.at (Markus Stumptner)
Newsgroups: comp.lang.smalltalk
Subject: Re: How to upload to Manchester?
Date: 20 Aug 92 16:49:34 GMT
Organization: DB and ES Subdivision, TU Vienna

From article <1992Aug20.150928.11736@cs.tu-berlin.de>, by muhr@opal.cs.tu-berlin.de (Thomas Muhr):
> I have a few pieces of ST/V software from Digitalk's Compu$erve forum

> How do I upload the sources to Manchester?

By sending the submit command to the server address
(goodies-lib@cs.man.ac.uk), you should get a set of instructions on
how to do it.

Could you post a list of the stuff you received?  That would make it
easier than digging for new stuff in the archives.


-- 
Markus Stumptner                                mst@vexpert.dbai.tuwien.ac.at
University of Technology Vienna                 vexpert!mst@relay.eu.net
Paniglg. 16, A-1040 Vienna, Austria             ...mcsun!vexpert!mst
From: steve.rainwater@ocitor.fidonet.org (Steve Rainwater)
Sender: FredGate@ocitor.fidonet
From: muhr@opal.cs.tu-berlin.de (Thomas Muhr)
Subject: Posting to Manchester
Organization: Techn. University of Berlin, Germany
Date: Sat, 22 Aug 1992 17:15:38 GMT

I just received the manual on how to submit to the Manchester goodies
libraries. From a first quick view this seems to be a bit complicated
and the posting of the parser generator for ST/V Win will be delayed.
I will forward the guidelines and legal statements to the author
of the code. A problem seems to be that an easy uploading via ftp in a
compressed format is not possible (at least it is not mentioned). The
people who are managing the library should not put too many obstacles
in the way of people willing to contribute. The part concerning the
legal stuff is also meant for lawyers I suppose!-)
- 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
From: ecrosbie@swift.cs.tcd.ie
Newsgroups: comp.lang.smalltalk
Subject: <None>
Date: 19 Aug 92 16:27:45 GMT
Organization: Computer Science Department, Trinity College Dublin

Can anyone recomend a good book that describes the Smalltalk 
MVC framework.  I have read all the PARC books by ADDISON-
WESLEY, are there any more up to date books, espcially those 
aimed at the environment in which I am currently working,  
specifically OBJECTWORKS smalltalk 4.1.
		
			Ed. Crosbie.
Comp. Science Dept.			telephone:+353-1-772941
Trinity College,			  telefax:+353-1-772204
Dublin 2,				    email:in"ecrosbie@cs.tcd.ie" 
Ireland.



Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Subject: (no subject given)
Original_To:  JNET%"smalk@finhutc"
Newsgroups: comp.lang.smalltalk
Date:         Fri, 21 Aug 1992 09:03:00 N
From:         LEO PLUGGE <VRDP3PLU@HMARL5.BITNET>

Hi,

Although the Smalltalk list is an interesting place, some of the discussions
are not relevant for someone programming in Actor (mainly).

Does anyone know of a discussion list for Actor (formarly Whitewater Group)
users?
I have performed a global listserver query, but without result.

===========================================================================
Dr. Leonard A. Plugge                    |    phone: (0)43-881039/881042
(Cognitive Psychologist)                 |      fax: (0)43-671096
University of Limburg                    |    email: VRDP3PLU@RuLimburg.NL
Faculty of Medicine                      |   BITNET: VRDP3PLU@HMARL5.BITNET
Dept. Neuropsychology & Psychobiology    +---------------------------------
P.O.Box 616                              |
6200 MD Maastricht                       |
The Netherlands                          |
============================================================================
From: rick@rick.infoserv.com (Rick Klement)
Newsgroups: comp.lang.smalltalk
Subject: Re: Cannot effect change to controller menu
Date: 14 Aug 92 04:25:47 GMT
Organization: Rick's Place, San Jose, CA, USA

In article <1992Aug12.165803.1@uwovax.uwo.ca>, brent@uwovax.uwo.ca (Brent Sterner) writes:
> 
>    I have just experienced a *very* strange effect in ParcPlace Smalltalk
> version 4.0 running on a sparcstation.  I have a simple counter model (which
> by the way I did *not* write :-) written and "distributed" by pp in their
> course "Introduction to OO Concepts..." course.  I have just discovered that
> I cannot change the controller menu of that model *within* st.  (I can edit
> the controller menu and "accept" the change, but it does *NOT* take effect
> even with a new instance of the counter model!)
> 
>    Curiously, if I "file out" the controller, physically "remove" the
> controller code from the st system, and "file it in" again, the edit *does*
> take effect.  Future edits remain ineffectual, however.
> 
>    This *seems* to me to be a serious system-related error, but I'm not
> fluent enough with the product to know how to verify this either way.
> 
>    Yes, I'm the beginner who has authored a bunch of beginner questions
> to this newsgroup already.  (Which makes me somewhat reluctant to jump up
> and down over this... it may simply be another case of me not knowing enough.)
> Please enlighten me.  If you've seen this (ill) effect, I'd also like to know
> about it.  Thanks for whatever you can tell me.  TTFN,  b.

In 2.5 menus were cached on the class side. This fits your symptoms.
Simply clear the cached menu...
-- 
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: leo@avs.com (Leo O'Donnell)
Subject: Copying a superclass object?
Organization: Advanced Visual Systems Inc.
X-Newsreader: Tin 1.1 PL4
Date: Mon, 17 Aug 1992 13:33:19 GMT
X-Posted-From: phobos.avs.com
X-Posted-Through: sol.ctr.columbia.edu

    I've got a bunch of objects of class A that need to be copied to
    its subclass A+. This always happens when an object of A+ is created.
    I could always reorganize my class hierarchy and make A and instance
    object of A+. I could also write methods that would permit me to copy
    all of the instance objects of A. Both of these are tedious and require
    careful maintenance. 

    Is there a better way? (If I'm missing something obvious -- Please, be 
    gentle with me :=)).


Leo O'Donnell                Email: leo@avs.com
Advanced Visual Systems      Voice: (617) 890-4300 ext 2120
Waltham, MA