HDTenEightyP/NetNews huggingface dataset:
From: knight@mrco.carleton.ca (Alan Knight)
Subject: Re: get/set behaviour (was: >>Voluntary method typing)
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: Carleton University
Date: Thu, 28 Jan 1993 12:35:39 GMT

In <1993Jan28.004755.1438@cs.uow.edu.au> humm@cs.uow.edu.au (Bernhard G Humm) writes:

>No, you missed my point (and I didn't make it too clear I have to admit). 
>I am well aware that in an OO language methods can do more that get and 
>set internal variables, they can e.g. send messages to other objects. What 
>I want to say is:

>The OO paradigm in its pure form is state based: the state of a system is 
>based on the state of all its objects only and the state of an object is 
>based on the values of its variables. And the only way of changing variables 
>is setting them. So, whatever a method might do its effect has to somehow 
>change object state.

That's not entirely true. The state of the system is also determined
by what objects exist, and a method can create new objects without
modifying the state of any old ones.  It is also determined by
invocation stacks and parameters just as much as any functional
language.  It is quite conceivable that one could write a program
using an OO language in which no state variables of any object were
ever modified (i.e. set except at creation time).  It has already been
extensively debated whether this is "really OO", and I have no wish to
re-open the topic, but such programs can certainly be written in a
"pure OO" language, making it a question of style.

In any case, this is clearly distinct from "database" type objects,
which have no behaviour other than get/set.

>>There is also the issue that in an OO language it is not necessary to
>>provide these get/set methods, so the internal state of an object may
>>not be (entirely) visible to code not part of that object. e.g.
>> ...

>Well, I suppose you are aware that encapsulation (one of the features of OO) 
>says that internal object state is NEVER visible to any outside code.

It's not directly visible, but if you write get/set methods for all
instance variables you have effectively circumvented encapsulation.

-- 
 Alan Knight  knight@mrco.carleton.ca  +1 613 225 8812
 The Object People, 885 Meadowlands Dr., Suite 509
 Ottawa, Ontario, Canada, K2C 3N2

Newsgroups: comp.lang.smalltalk
From: aa421@Freenet.carleton.ca (Michael Wilson)
Subject: Re: Questions on GNU Smalltalk
Reply-To: aa421@Freenet.carleton.ca (Michael Wilson)
Organization: The National Capital Freenet
Date: Thu, 21 Jan 1993 18:14:45 GMT


In a previous article, wwm@ef5003.efhd.ford.com (Bill Meahan) says:
>1) What's the status of Smalltalk 1.2 (or later)?  Archie shows entries
>   for smalltalk-1.2 at a couple of European sites, but the "canonical"
>   site (prep.ai.mit.edu) only has version 1.1.1.

Why bother? GnuST is useless. On the benchmark suite I ran it was
more than THIRTY TIMES slower than the slowest commercial smalltalks.
This makes it unusable for anything but extremely toy applications.

McQ
-- 
Michael Grant Wilson (McQ)
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
From: panu@ajk.tele.fi (Panu Viljamaa)
Subject: Re: SmallTalk Products Recommendation
Organization: Telecom Finland
Date: Fri, 22 Jan 1993 10:22:37 GMT

> We are currently in search of PC (Windows) and Mac based 
> (Smalltalk)

	We worked with both ObjectWorks (ParcPlace) &
 Smalltalk-V (Digitalk). Unfortunately they seem
 to be the only major players. Their systems
 (= the libraries) are not as compatible with each
 other as you would like. More or less you have to
 choose one and stick to it.  

 Main points in favor of each:

 Digitalk:
  - Cheap

  - No run time license, so you can actually make
    a product with little risk.

  - Less programming tools but you can (should)
    by them from 3. party.

  - Less portability between Mac & PC but better
    integration with each environment (eg: support 
    for DLL:s & XCMDs).

  - GUI is exactly the native GUI of each environment


 Parc Place (Objectworks for Smalltalk)

  - Expensive.
  - Excellent programming environment.

  - Excellent binary portability 
     (when using the SAME release).

  - Run time licences, but if you have big
    internal user-base, tolerable. However,
    if the system doesn't get into widespread use,
    you lose money.

  - Objectworks is akin to Windows, to run 
    applications you need to buy the 'substrate'.
    Unfortunately there aren't many commercial
    packages available to run on top of it, so
    YOUR system has to justify the cost alone.

  - GUI does not quite conform to the native style 
    used on each of the platforms.

Take you pick !

Panu

-----------------------------------------
Panu Viljamaa (panu@ajk.tele.fi) 
Telecom Finland Business Systems R&D
----------------------------------------- 
Newsgroups: comp.lang.smalltalk
From: humm@cs.uow.edu.au (Bernhard G Humm)
Subject: Re: get/set behaviour (was: >>Voluntary method typing)
Organization: Dept of Computer Science, Wollongong University, Australia
Date: Thu, 28 Jan 1993 00:47:55 GMT

knight@mrco.carleton.ca (Alan Knight) writes:

>The distinction is quite clear from the original post.  It says
>"database-type objects which _just_ have get/set behaviour". Clearly
>objects have a record structure internally, but they also may provide
>a great deal of additional behaviour beyond just setting and getting
>the state of instance variables. I believe the original author was
>referring to objects which do not provide any additional behaviour and
>are thus very much like objects n a database or a "normal" language.

No, you missed my point (and I didn't make it too clear I have to admit). 
I am well aware that in an OO language methods can do more that get and 
set internal variables, they can e.g. send messages to other objects. What 
I want to say is:

The OO paradigm in its pure form is state based: the state of a system is 
based on the state of all its objects only and the state of an object is 
based on the values of its variables. And the only way of changing variables 
is setting them. So, whatever a method might do its effect has to somehow 
change object state.

This is one extreme end of a spectrum. The pure functional paradigm is at 
the other end. In purely functional languages there are no variables at all, 
only parameters to function calls. The ``state'' of a system is determined 
by invocation stacks and the parameters being passed.

``Real programming'' is neither purely OO nor purely functional. But if you 
take a purist's view, the only thing that really counts is get/set, whatever 
a method does in-between.


>There is also the issue that in an OO language it is not necessary to
>provide these get/set methods, so the internal state of an object may
>not be (entirely) visible to code not part of that object. e.g.
> ...

Well, I suppose you are aware that encapsulation (one of the features of OO) 
says that internal object state is NEVER visible to any outside code.

-- 
________________________________________________________
         Bernhard G. Humm   (humm@cs.uow.edu.au)        
       Telecommunications Software Research Centre      
Department of Computer Science, University of Wollongong
Newsgroups: comp.lang.smalltalk
From: hutch@alias.com (Robert Hutchison)
Subject: Re: probs with saving image in stv/win 2.0
Reply-To: hutch@alias.com (Robert Hutchison)
Organization: Alias Research, Inc. Toronto Canada
Distribution: na
Date: Tue, 26 Jan 1993 14:39:24 GMT

In article <C1FFMo.7r@aisdo.AIS-Dortmund.DE>, bernd@aisdo.AIS-Dortmund.DE (Bernd Finger) writes:
> Hello world!
> I have a very curious problem with stv/win 2.0:
> When I start the image, save it and quit, the image size  shrinks from
> 4.1 MB to 3.0 MB. I don't do any further actions!!
> When I try to restart the saved image, I get a general protection
> fault at 00008:0389 in the VWVM20.DLL. The only way to save my work is
> to file out all changed classes and to install them i a virgin image.
> This is sometimes very depressing :-(
> Can somebody help me?
> cu,
> 	Bernd!
> 
> P.S.: I have the following applications installed in the image:
> - Windowbuilder 2.03
> - Subpanes/V
> - AMST/V
> 

I have had a very similar problem, with the same fault at 0008:0389.

In my case it caused by assigning something new to the root of a 
not too complicated or large tree structure (about 2 meg of image).

I filed my classes into a 'clean' smalltalk image (as shipped with none
of the options installed) -- exactly the same thing happened.

I reported this to bug@digitalk.com on 21 December, 1992.  I have 
recieved no reply at all.

The end result is that I have gone back to using C++.  This is 
annoying.  C++ is not as efficient as smalltalk for development, and
I have not yet found anything like WindowBuilder and SubPanes in the
C++ world.



> 
> -- 
> AIS GmbH
> Bernd Finger
> Luetge Brueckstrasse 12
> 4600 Dortmund 1 / Germany

--
Bob Hutchison
Alias Research                  Phone: (416)392-9181 
110 Richmond St. E.                    (416)392-8558x427 (direct)
Toronto Canada                  FAX:   (416)392-0630
M5C 1P1                         email: hutch@alias.com

Newsgroups: comp.lang.smalltalk
From: koeppen@hp06c.sonne.informatik.uni-essen.de (Eckhart Koeppen)
Subject: ST V/PM problem using DLLs
Date: Thu, 21 Jan 1993 14:37:17 GMT
Reply-To: koeppen@hp06c.informatik.uni-essen.de (Eckhart Koeppen)
Organization: University of Essen, Germany

  I have been trying to build a DLL and call some functions from ST V/PM but
the thing won't work. Here is the code:

test.c:

void empty(void) asm ("empty"); /* used here to tell gcc 2.1 not to produce */
								/* underscores */

void empty(void)
{
}

test.def:

LIBRARY  TEST
EXPORTS  empty

The DLL is interfaced through the class TestDLL (subclass of PMHandle).
The class has only one method named fileName which returns 'TEST'. The
only instance method is called empty and looks like this:

empty
	"calls the C function empty"
	<api: empty none>
	^self invalidArgument

Though I tried several variations (dropping the asm in the declaration of
test.c: (compiled with gcc 2.1)
The DLL compiles fine and it is no problem to open it with TestDLL open,
but any invocation of the method empty results in an error message.
Any help would be appreciated,

Eckhart
Newsgroups: comp.lang.smalltalk
From: hutch@alias.com (Robert Hutchison)
Subject: Re: probs with saving image in stv/win 2.0
Reply-To: hutch@alias.com (Robert Hutchison)
Organization: Alias Research, Inc. Toronto Canada
Distribution: na
Date: Tue, 26 Jan 1993 18:02:11 GMT

In article <1993Jan26.042727.3834@netcom.com>, poliquin@netcom.com (Tom Poliquin) writes:
> bernd@aisdo.AIS-Dortmund.DE (Bernd Finger) writes:
> : Hello world!
> : I have a very curious problem with stv/win 2.0:
> : When I start the image, save it and quit, the image size  shrinks from
> : 4.1 MB to 3.0 MB. I don't do any further actions!!
> : When I try to restart the saved image, I get a general protection
> : fault at 00008:0389 in the VWVM20.DLL. 
> 
>  Bernd...
> I have heard of a bug like this in the Compuserve Digitalk forum
> (GO DIGITALK). I believe there is a fix for it in the Cserve forum
> library.
> A workaround (if I recall correctly) is to only save
> the image from the menu ... not when quitting ST.... a technique
> I have used with no probs (...so far).

In my case, I am using the menu.  I got out of the habit of saving
the image on quitting in the 1.x releases.

This problem does not seem to be helped by this technique.

If anyone has access to the Cserve forum and would care to post
anything applicable, I, for one, would be appreciative.

> 
> Gud Luck
> 
> Tom Poliquin
> San Jose
> "All great truths begin as blasphemies" George Bernard Shaw
> 
> 

-- 

Tapadh leibh -- mar sin leat,
  Hutch
Organization: University of Central Florida--Computer Services
Date: Sat, 23 Jan 1993 20:58:35 EST
From: Michael Brunetti <MICHAELB@UCF1VM.BITNET>
Newsgroups: comp.lang.smalltalk
Subject: Smalltalk book recommendation

POSTED FOR A FRIEND.  PLEASE REPLY TO MY ADDRESS DIRECTLY.
I desparately need a recommendation for a third party book on Smalltalk.
None of the book stores that are in this area have anything.
If you know of anything, the ISBN would be helpful.

Thanks in advance for any info,
BILL







*************************************************************************
  Michael Brunetti                     michaelb@ucf1vm.cc.ucf.edu
  Consultant (I & R Support)          UCF Computer Engineering Student
*************************************************************************
    "I believe OS/2 is destined to be the most important operating
     system, and possibly program, of all time" - Bill Gates, Nov, 1987.
*************************************************************************
From: ivang@cup.portal.com (Ivan - Godard)
Newsgroups: comp.lang.smalltalk
Subject: Re: Voluntary method typing in ST80
Date: Sat, 23 Jan 93 09:31:55 PST
Organization: The Portal System (TM)

>
>>Can you give details/send code on your approach?
>>
>I got so fed up with defining 'record-like' objects with lots of setX,getX
>type methods that I defined a Record as a subclass of Dictionary.
>the only method is 'doesnotunderstand'.
>If you send
>obj setName: arg
>
>it bounces back as doesNotUnderstand.  this looks at the 'setName', peels
>off the 'set' and sets name->arg in the dictionary.
>similarly 'getName' retrieves it.
>
[...omission...]
>
>Of course, this only applies to database-type objects which just have
>get/set behaviour, but this seems quite a significant subset.
>
>all the best,
>>>benedict


Faced with a similar problem, I defined a method Class>>accessMethods which
ran through all the instance variables of a class and defined get and
set methods for those instance names. Much simpler and much more
performant. There is a reason for compilers, after all. If you do this,
Make sure that the generated text contains comments indicating that it is
mechanically generated, so that later you (or others) won't modifiy the
method and then lose the modification when accessMethods is rerun.



Ivan
Newsgroups: comp.lang.smalltalk
From: hasko@heeg.de (Hasko Heinecke)
Subject: Re: Voluntary method typing in ST80
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG
Date: Tue, 26 Jan 1993 13:45:48 GMT

In article <1993Jan25.070651.2105@cs.uow.edu.au> humm@cs.uow.edu.au (Bernhard G Humm) writes:
>>>Of course, this only applies to database-type objects which just have
>>>get/set behaviour, but this seems quite a significant subset.
>
>Are there really any other cases in a pure OO language?

Are there really _such_ cases in a pure OO project?

Hasko

-- 
+-------------------------------------------------------+
| Hasko Heinecke @ Georg Heeg Objektorientierte Systeme |
| I _never_ mean what I say - and nobody else does...   |
+-------------------------------------------------------+
Newsgroups: comp.lang.smalltalk
From: liblit@cs.psu.edu (Benjamin R. Liblit)
Subject: Re: Questions on GNU Smalltalk
Date: Thu, 21 Jan 1993 23:01:47 GMT

In article <1993Jan21.181445.8193@freenet.carleton.ca>,
aa421@Freenet.carleton.ca (Michael Wilson) writes:

> Why bother [using GNU Smalltalk]? GnuST is useless. On the benchmark
> suite I ran it was more than THIRTY TIMES slower than the slowest
> commercial smalltalks.

I have a different angle on this than you do.  As an unfunded
undergraduate CS student, benchmarks are measured in units of money,
not time.  And according to *my* test suite, Gnu Smalltalk blows the
others away, to the tune of multiple hundreds of hard-earned dollars.

So is this the old "you get what you pay for" cliche?  Perhaps.  All I
know is Gnu Smalltalk works, and if I run out to get a copy with two
pennies in my pocket, I've still got a Lincoln duet when I'm done.

Commercial Smalltalk implementations are thirty times faster?  Cool.
Want to buy me a copy for my birthday?  :-)

--
Ben Liblit   -----   "Fais que tes reves soient plus longs que la nuit."
liblit@cs.psu.edu   --   brl102@psuvm.psu.edu   --   brl102@psuvm.bitnet
From: jeff@amikoj.rn.com (Jeff Kunce)
Newsgroups: comp.lang.smalltalk
Subject: Re: WindowBuilder 2.0 - Bug fixes
Date: Wed, 27 Jan 93 21:34:50 CST
Organization: ** Amikoj en Esperantujo **

dugerdil@uni2a.unige.ch writes:
> In article <ALOIS.4.0@edvz.uni-linz.ac.at>, 
> > Lately I bought Cooper + Peters WindowBuilder 2.0 with Subpans/V for
> > Windows. But this product has some bugs.
> > ...
> The fixes are on Compuserve. But C&P distribute a disk with the bug fixes
> free of charge to the registered users of WB 2.0. Just send them a fax
> or call them directly.
> ...

According to a recent posting on CompuServe, Ken Cooper of Cooper & Peters
says:

"...On February 1st, Objectshare will be taking on the support, development, 
and marketing of our product line.
...
Objectshare Systems, Inc.
5 Town & Country Village
San Jose, CA 95128-2026

Product Order & Information   (408) 727-3742
Product Support Hotline       (408) 727-3742
Fax (Order & Support)         (408) 727-6324
BBS (Starting in March)       (408) 727-6284
CompuServe                    76436,1063"
                 [that is, 76436.1063@compuserve.com]

He seems very confident that Objectshare Systems will carry on the
Acumen / C&P tradition of quality Smalltalk development tools.

   --Jeff  [no connection w/ C&P, except as satisfied customer]

P.S. I hand-typed the quotes above, I think there are no errors...

--
jeff@amikoj.rn.com (Jeff Kunce)
Jefferson City, Missouri
Newsgroups: comp.lang.smalltalk
From: dvines@syl.dl.nec.com (Don Vines)
Subject: pure vs hybrid OOPLS
Organization: NEC Systems Lab., C&C Software Technology Center (Dallas, TX)
Date: Sat, 23 Jan 1993 16:42:48 GMT



>>>>Could someone point out a reference or identify some of the design
>>>>rationale (benefits) of having a pure OOPL like Smalltalk as opposed
>>>>to a hybrid OOPL like C++.
>>>>
>>>>I did not want to start any language wars so I just posted to
>>>>comp.lang.smalltalk.  If possible please email the responses
>>>>to me.


>>Could you post a summary of responses as well?  


I'd be glad to..


-- 
Donald H Vines, Jr.
NEC Systems Laboratory, Inc.                  Phone: (214)518-3486             
1901 Gateway Dr.                              Fax  : (214)518-3552             
Irving, Texas 75038                           Email: dvines@syl.dl.nec.com
From: bush@ecs.ox.ac.uk (Mark Bush)
Newsgroups: comp.lang.smalltalk
Subject: Re: Questions on GNU Smalltalk
Date: 22 Jan 93 09:47:37 GMT
Organization: Oxford University Computing Laboratory
Originator: bush@thom5.ecs.ox.ac.uk

In article <11533@prijat.cs.uofs.edu> bill@cs.uofs.edu (Bill Gunshannon) writes:
#Considering that trying to run it on a Sparc with 8 Meg of memory returns
#the error "Not enough memory", I can't imagine it ever running on the 3B1.

Look in mstoop.c for lines which look like:

#ifndef atarist
/* Min for Kernel = 512K, Kernel+STIX min is 1M */
/* you can increase this value if you need more space, and it won't hurt
 * performance *if* your machine has enough physical memory (otherwise, you
 * thrash the pager) */
#define INIT_MEM_SPACE_SIZE             /*(512 * K) */ (2 * K * K)
#else
#define INIT_MEM_SPACE_SIZE             (1152 * K) 
#endif

For non-atari versions, this sets the size of the two spaces used for
garbage collection to 2Mb each.  The commented out version uses 512k eack.
This is the minimum initial configuration.  Smalltalk will grow if it needs
more space.

Note that it's not memory which restricts the size, but swap space size...
Though things run a lot slower if you don't have the RAM to support the size
of the semi-spaces.

Mark
Newsgroups: comp.lang.smalltalk
From: hasko@heeg.de (Hasko Heinecke)
Subject: Re: Inheritance of Smalltalk
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG
Date: Thu, 28 Jan 1993 14:18:33 GMT

In article <1k667uINNbkn@montaigne.lif.icnet.uk> js@montaigne.lif.icnet.uk (Jack Shirazi <js@biu.icnet.uk>) writes:
>In article <1993Jan26.150808.62839@qut.edu.au> bub@qut.edu.au writes:
>>Is any one there can tell me if Smalltalk/v windows has the capacity of
>>multiple inheritance? What about ParcPlace's Smalltalk in windows?
>
>As far as I know, no implementation of smalltalk has proper multiple
>inheritance (you can always reimplement doesNotUnderstand: to send
>the message on to one of the instance variables for a kind of multiple
>inheritance). I remember reading that several groups have looked at
>implementing multiple inheritance in the image, but all have given up
>after finding that the effort wasn't worth it. Personally, I think it
>would be a useful addition to Smalltalk, but having thought about ways
>of implementing it, I realize that it would take more effort than I have
>available. Anyone out there trying?

ParcPlace's Smalltalk-80 optionally implemented multiple inheritance until
version 2.3. BTW, there was also a syntax for typed paramters provided,
although there was no functionality behind it. People just found that
- as you said - multiple inheritance isn't worth the effort, not only in
implementing it but also in using it. Therfore, MI was removed in favor
of other enhancements to Smalltalk.

Hasko Heinecke

-- 
+-------------------------------------------------------+
| Hasko Heinecke @ Georg Heeg Objektorientierte Systeme |
| I _never_ mean what I say - and nobody else does...   |
+-------------------------------------------------------+
Newsgroups: comp.lang.smalltalk
From: looi@ssfarch.attmail.com (Wan Looi)
Subject: SmallTalk Products Recommendation
Date: Fri, 22 Jan 1993 00:38:29 GMT
Organization: DHL Worldwide Express, Redwood City, Calif., USA


We are currently in search of PC (Windows) and Mac based
Smalltalk package(s) for a custom application. Some of
the major considerations are

1) Must run on PC 386 or higher and Mac II series or better;
2) Ability to strip runtime image/executable size to smallest possible;
3) Portable between PC and Mac with minimum modifications;
4) Flexible licensing for deployment/distribution; and
5) Excellent documentation and support.

If you have experience with any PC/Mac based SmallTalk package,
I would like to hear your experience and perhaps, recommend
a product best suited for PC and Mac platforms.

Thank you!

Wan
-- 
Systems Arch., DHL Airways, Inc., 333 Twin Dolphin Dr, Redwood City, CA 94065
INET: looi@ssfarch.attmail.com  UUNET: uunet!ssfarch!looi
VOICE: (415) 802-4584	FAX: (415) 593-1689
From: gerard@integow.integrity.nl (Gerard Huysmans)
Newsgroups: comp.lang.smalltalk
Subject: Re: Varieties of Smalltalk
Date: 21 Jan 93 07:21:23 GMT
Organization: Integrity BV, Woerden, NL
X-Newsreader: Tin 1.1 PL4

steve@fulcrum.oz.au (Steve Taylor) writes:
: I'd like to move over to another Smalltalk system, but
: it looks like the field (on intel machines) is pretty limited. The options
: that I'm aware of are:
: 
: 	Digitalk ST/V                - even older than ST V/286
: 	Digitalk ST/V Windows        - don't really want to run MS Windows,
: 				       but maybe...
: 	Digitalk ST/V PM             - supposedly pretty good, but I definitely
: 				       don't want to run OS/2
: 	ParcPlace ST/80              - good, but can't afford it.
: 	GNU ST                       - could port it to DOS, via GCC, but it's
: 				       still basically a tty interface, isn't 
: 				       it? Would prefer a windowing environment
: 
: My question (and I'm hoping to hear a "yes") is, Have I missed any
: implementations in this list?

What about the Enfin package (by the EASEL Corporation):
	Enfin/2 Windows SQL v 2.00   - requires MS Windows
	Enfin/3 PM v 1.06            - requires OS/2

I'm new at the Smalltalk business, but to me it looks like the latest versions
of Enfin are using true Smalltalk instead of their own Smalltalk dialect. As
far as I could see, Enfin is a complete development environment including a
graphical interface editor, source code control system, SQL database support
and a program generator for creation of license free runtimes.

-- 
======================================================================
Gerard Huysmans,                           E-mail: gerard@integrity.nl
Integrity Software Consultants             Voice:  +31-(0)3480-30131
Woerden, the Netherlands                   Fax:    +31-(0)3480-30182
Newsgroups: comp.lang.smalltalk