HDTenEightyP/NetNews huggingface dataset:
From: smith@ctron.com (Larry Smith)
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
Subject: Re: comparing object-oriented platforms
Date: 5 Oct 92 14:44:14 GMT
Reply-To: smith@ctron.com
Followup-To: comp.lang.smalltalk
Organization: Cabletron Systems, Inc.

In article <kemtuha00awA8FZnhw@andrew.cmu.edu>, osoelgaultier+@CMU.EDU (Stefan Monnier) writes:
>You seriously mean you can write code so that noone can use your datatype
>directly ?

>Show me how !

It's not obvious, but it's pretty easy.  To take a trivial example:

foo.h:

#ifndef FOO_H
#define FOO_H

#define FOO struct foo

FOO    *init_foo(char *some_init_params);  /* constructor */
void    nuke_foo(FOO *foo_thing);          /* destructor */

long    inq_foo(FOO *foo_thing);           /* various methods... */
void    set_foo_name(FOO *foo_thing, char *name);
char   *get_foo_name(FOO *foo_thing);
void    do_foo_thing(FOO *foo_thing, char *some_arg);

#endif

That's all that goes in the header.  Now the rest of it can go in the .c,

foo.c

#include "foo.h"

/* reveal data type */
FOO {
  char *foo_name;
  long  foo_count;
  char *mysterious_foo_thing;
} foo;

static global_foo_count = 0;

/* end reveal */

FOO *init_foo(char *some_init_params) {
  FOO *result;

  result = (FOO *)malloc(sizeof(FOO));
  result->foo_count = global_foo_count++;
  result->foo_name = 0;
  result->mysterious_foo_thing = some_init_params;
  return result;
}

void nuke_foo(FOO *foo_thing) {
  if(foo_thing->mysterious_foo_thing) free(foo_thing->mysterious_foo_thing);
  if(foo_thing->name) free(foo_thing->name);
  free(foo_thing);
}

long  inq_foo(FOO *foo_thing){
  return foo_thing->foo_count;
}

void  set_foo_name(FOO *foo_thing, char *name) {
  if(foo_thing->name) free(foo_thing->name);
  foo_thing->name = strdup(name);
}

char *get_foo_name(FOO *foo_thing) {
  return foo_thing->name);
}

void  do_foo_thing(FOO *foo_thing, char *some_arg) {
  foo_thing->mysterious_foo_thing = some_arg;
}

If you don't want to be required to define all the methods of the data type
in the same .c file, abstract out the reveal data type and put it in an
_internal_header - I'd call it foo.i, and foo.i is included into all .c files
that define foo, but it is _not_ part of the .h interface to the foo module.

As I said, it's a fairly simple scheme, giving you most of the functionality
of objects without much overhead.  The actual mechanism is one I learned using
Modula2 and is called _opaque_types_, as the original poster mentioned.  One
advantage of learning lots of programming languages is that each one has it's
little schticks and little tricks, and the germ of these ideas can frequently
be transported to another language.  After I learned Modula2, it became quite
obvious how to do the same idea in C.

Larry Smith (smith@ctron.com)  No, I don't speak for Cabletron.  Need you ask?
-
How about we all do something reasonable?  I bet that'll confuse 'em!
From: scrl@otter.hpl.hp.com (Simon Lewis)
Date: Mon, 5 Oct 1992 06:43:03 GMT
Subject: Re: dynamically dropping views in PPST4.1
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.lang.smalltalk

To do this kind of thing, I always keep a handle on the view I want to
remove, as well as the container.  When the time comes to remove the view
I send the container the message remove: myView.  Worked under 4.0, still
works under 4.1.  (Might be removeComponent: or something like that.)

Simon.
From: nadja@jetsun.weitek.COM (Nadja Adolf)
Newsgroups: comp.lang.smalltalk
Subject: Re: comparing object-oriented platforms
Date: 5 Oct 92 18:26:56 GMT
Organization: WEITEK Corporation, Sunnyvale CA

In article <718144987snx@feki.toppoint.de> marten@feki.toppoint.de (Marten Feldtmann) writes:
>nadja@jetsun.weitek.COM writes in article <1992Oct1.013812.2130@jetsun.weitek.COM>:
>
>> Admittedly, the caching does make it faster than complete interpretation,
>> but it is still significantly slower than a compiled language. The more
>> complex the program, the greater the difference.

> Is this true? The more complex the program is, the greater the difference?
>I've been told, that the more complex the program is, the more less is
>the difference of the speed between compiled C++ and ST code.

> With ST one has drawbacks doing stuff like bit-shifting or complex
>arithmetic functions. But if your application consists of a lot of
>functions like this you can mix both ST-dialects with C procedures. Most
>of the daily applications do not use these things ...

What applications don't use complex arithmetic functions? I have yet to
find a business app that didn't do a lot of calculations...

> In my view the most significant problem with C++ is, that now most of
>the C programmers think too fast, that they managed or understand the
>OOP principles. They use procedural concepts and mix them with
>OOP-concepts and I think, these guys will get lost in big projects.

My experience has been the reverse. C++ people get the project done since
they design before they code; smalltalk people 'design on the fly', get
a demo up, and then have to redo everything several times to get a project.

There seems to be a big myth out there that C++==C. :-) A myth heavily
believed in by people who don't use C++. How many big projects written
in smalltalk have actually 'gone out the door?' How many in C++?

> After all, speed considerations will more and more vanish in the future
>and getting the solution will be the problem ...

It depends on what sort of speed considerations you are speaking of. :-)


-- 
The Earth Pig Bourne....

nadja@node.com (prefered email address)
nadja@weitek.com
Newsgroups: comp.lang.smalltalk
From: irvine@ntmtv.UUCP (Chuck Irvine)
Subject: Re: ST/VWin 2.0 upgrade - OVERPRICED???
Organization: Northern Telecom Inc, Mountain View, CA
Date: Mon, 28 Sep 1992 18:08:31 GMT

In article <1992Sep16.210551.5658@nstn.ns.ca>, bushell@fox.nstn.ns.ca (Tom Bushell) writes:

[deleted text]

|> 
|> When I got the package, I was quite disappointed, for the following
|> reasons:
|> 
|> 1)	The documentation has been repackaged - the Class dictionary
|> 	appendix has been broken out into a separate volume.  The format
|> 	and typefaces have also changed, making it somewhat more readable.
|> 	There are also some additional booklets describing Direct Connect,
|>         etc.   But there is NO new technical information provided - at
|> 	least, not that I could find.  It's strictly a cosmetic change!

I would describe the quality of their documentation as pathetic; it is grossly
incomplete.

|> 
|> 2)	2.0 is billed as being Windows 3.1 compatable, but there is no 
|> 	support for one of the biggest new features of Win 3.1 - OLE.
|> 
|> 3)	There are some new features, including MDI support, an object
|> 	filer, support for on line help in your applications, and some
|> 	others.  These look like useful enhancements.  Now, I havn't had
|> 	a chance to more than briefly play with some of these, but several
|> 	things struck me about them:
|> 		a)	They are provided as add-ons, not part of the
|> 			basic image.  Documentation is in the form of
|> 			readme files, and is pretty minimal.  Looks like
|> 			it would be a lot of work to figure out how to use
|> 			this stuff.  (Though, as several of you have
|> 			pointed out, this is par for the course for all
|> 			of Digitalk's documentation).

You get better documentation with most shareware packages I've seen!

|> 		b)	The help system requires the SDK Help Compiler.  I
|> 			bought VWin so I could AVOID all that stuff!  It
|> 			would have been nice if an alternate tool had been 
|> 			provided.

They have always said that with their product you don't need the SDK to develop
Windows applications. That was one of the reasons that I bought their product.

In summary:

1) The upgrade was too expensive.
2) Their documentation is terrible. (As you rightly state, it's incomplete.)
3) Their support is too expensive.
4) Like you, I generally like their product, but I am beginning to dislike them.


All opinions are mine alone.

Chuck Irvine
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
From: maniattb@cs.rpi.edu (Bill Maniatty)
Subject: Re: comparing object-oriented platforms
Date: Sun, 27 Sep 1992 01:24:45 GMT

In article <welAJHa00Vor81pWA6@andrew.cmu.edu>, osoelgaultier+@CMU.EDU (Stefan Monnier) writes:
|> Excerpts from netnews.comp.lang.eiffel: 26-Sep-92 Re: comparing
|> object-orient.. John Nagle@netcom.com (1174)
|> 
|> > mwu@orion.oac.uci.edu (Matt Wu) writes:
|> > >I'm currently evaluating several object-oriented development platforms
|> > >and I was wondering if any of you would like to share your opinions on
|> > >platforms that you prefer or know about.  It'd be especially useful to hear
|> > >comparisons between different platforms (for instance, Eiffel v. Smalltalk).

	[Stuff Deleted]
|> > 	Eiffel		Limited interest - one or two compilers, one book.
|> > 			Less used than Smalltalk, C++, Ada, or Modula-2.
	[More Stuff Deleted]
|> Eiffel: not that uninteresting: clean, powerful, I would say
|> 	it is state of the art in strongly typed OOL. The ISE
|> 	environment is quite decent (I heard the version 3.0 is
|> 	even good)

I'm interested in Operating Systems, and Massively Parallel architectures.
Just how can these techniques be applied to these areas.  Consider Kernel
level programming.  A strongly typed language with strong support for reuse
of software should make for a better kernel implementation and design.
On the flip side, I'm under the impression that real time programming cannot be
done with a Garbage Collecting language, as the garbage collection could
happen at an arbitrary time, and cause a violation of the timing constraints.
And I wonder just how well the Eiffel assertion checking could handle parallel
computations?  Can I get a win by using Eiffel to do these sorts of things,
and if so, how?

|> 
|> Personnally, I don't like C++ much (mainly cause of it's lack of GC)
|> Between smalltalk and eiffel, it's a question of taste: do you like
|> strong static typing or prefer dynamic typing ?
|> I really think the smalltalk environment is excellent, much better
|> than what I know for eiffel, but the strictness of eiffel makes it
|> really nice to debug !
(Debugging is a drag, any tool that reduces the debugging load gets my vote).

|> 	Stefan Monnier

Bill Maniatty
-- 
|
|	maniattb@cs.rpi.edu - in real life Bill Maniatty
|
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
From: jcm@hgc.edu (James McKim)
Subject: Re: comparing object-oriented platforms
Organization: The Hartford Graduate Center
Date: Mon, 28 Sep 1992 13:31:56 GMT

In article <8mgztqf@rpi.edu> maniattb@cs.rpi.edu (Bill Maniatty) writes:

[...]

>
>I'm interested in Operating Systems, and Massively Parallel architectures.
>Just how can these techniques be applied to these areas.  Consider Kernel
>level programming.  A strongly typed language with strong support for reuse
>of software should make for a better kernel implementation and design.
>On the flip side, I'm under the impression that real time programming cannot be
>done with a Garbage Collecting language, as the garbage collection could
>happen at an arbitrary time, and cause a violation of the timing constraints.

Eiffel allows you to turn off GC when the system is under heavy time constraints
and then turn it back on when timing is less critical. The question then 
becomes: Can you do a better job of GC manually than the system can do
automatically? The answer depends on you, your system and the quality
of the automated GC. As automatic GC algorithms and implementations improve,
fewer and fewer people will be tempted to write their own.

>And I wonder just how well the Eiffel assertion checking could handle parallel
>computations?  Can I get a win by using Eiffel to do these sorts of things,
>and if so, how?

This is an area of current research. Bertrand just published a list
of references to work involving concurrency and parallellism with respect
to Eiffel. I could send you this list if you like.

>
>
>Bill Maniatty
>-- 
>|
>|	maniattb@cs.rpi.edu - in real life Bill Maniatty
>|


Hope this helps,
-- Jim
-- 

*------------------------------------------------------------------------------*
Jim McKim  (203)-548-2458     In exactly 3.2 seconds it will be a few 
Internet:  jcm@hgc.edu   minutes to 5:00.
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: comparing object-oriented platforms
Date: Sun, 27 Sep 92 07:37:12 GMT
Organization: Object Systems

In article <8mgztqf@rpi.edu> maniattb@cs.rpi.edu (Bill Maniatty) writes:
>...[On OO languages]...
>I'm interested in Operating Systems, and Massively Parallel architectures.

Me too.

>Just how can these techniques be applied to these areas.  Consider Kernel
>level programming.  A strongly typed language with strong support for reuse
>of software should make for a better kernel implementation and design.
>On the flip side, I'm under the impression that real time programming cannot be
>done with a Garbage Collecting language, as the garbage collection could
>happen at an arbitrary time, and cause a violation of the timing constraints.

Depends on the level and layering of the OS.  You may not be able to use
all of the facilities of a language at all levels; you'll have to watch
for infinite recursion in some cases.  So its silly to say languages with
GC can't be used in the OS; you just may not be able to use the facility.
This was all relevant in an OS I worked on in an OO extension of Ada.

bob
objsys@netcom.com
Newsgroups: comp.lang.smalltalk,comp.object,comp.lang.objective-c
From: bouwman@cs.few.eur.nl (Peter Bouwman)
Subject: Re: MVC shortcommings
Organization: Erasmus Universiteit Rotterdam
Date: Tue, 29 Sep 1992 13:57:32 GMT

johnson@m.cs.uiuc.edu (Ralph Johnson) writes:

>frerk@informatik.uni-kl.de (Frerk Meyer) writes:

>>MVC is a White Box as opposed to a Black Box.

>This is much less true of the MVC in R4.0 (and R4.1) than it was
>in 2.5.  As often happens with frameworks, MVC is becoming more
>and more black-box.  And the original question was about the MVC
>*paradigm* (whatever that is), so one could take any criticism
>of the *implementation* and just say that it is bug waiting to be
>fixed, not really a problem with the paradigm

>I agree that black box frameworks are easier to reuse.  The use of
>Wrappers in 4.1 makes user interface components much more composable
>and means you have to understand less about their implementation.

>-Ralph Johnson

Are there any references to these MVC versions? Thanks.

-Peter.
Newsgroups: comp.lang.smalltalk
From: acmtsv@gsusgi2.gsu.edu (Thomas Scott Vaughn)
Subject: Finding good applications for smalltalk
Organization: Georgia State University
Date: Wed, 30 Sep 1992 23:59:02 GMT


I'm doing research on the use of OOPL by the private sector.  I'm
wondering if smalltalk is used by anyone for "industrial-strength"
software.  I'd be interessted to hear from you if you have experiences
or opinions regarding this.  Feel free to be as verbose or as brief as
you like.  Any responce will be appreciated.

Thanks.
Tom Vaughn
acmtsv@gsusgi2.gsu.edu
From: marten@feki.toppoint.de (Marten Feldtmann)
Newsgroups: comp.lang.smalltalk
Subject: Re: comparing object-oriented platforms
Distribution: world
Date: Sat, 03 Oct 92 20:43:07 GMT
Organization: Private OS/2 System

nadja@jetsun.weitek.COM writes in article <1992Oct1.013812.2130@jetsun.weitek.COM>:

> Admittedly, the caching does make it faster than complete interpretation,
> but it is still significantly slower than a compiled language. The more
> complex the program, the greater the difference.

 Is this true? The more complex the program is, the greater the difference?
I've been told, that the more complex the program is, the more less is
the difference of the speed between compiled C++ and ST code.

 With ST one has drawbacks doing stuff like bit-shifting or complex
arithmetic functions. But if your application consists of a lot of
functions like this you can mix both ST-dialects with C procedures. Most
of the daily applications do not use these things ...

 In my view the most significant problem with C++ is, that now most of
the C programmers think too fast, that they managed or understand the
OOP principles. They use procedural concepts and mix them with
OOP-concepts and I think, these guys will get lost in big projects.

 After all, speed considerations will more and more vanish in the future
and getting the solution will be the problem ...

 MF

--
Marten Feldtmann,     Kieler Str. 29,       2300 Kiel 14,    Germany
E-Mail: marten@tpki.toppoint.de, FAX possible
From: Hubert.Baumeister@mpi-sb.mpg.de (Hubert Baumeister)
Newsgroups: comp.lang.smalltalk
Subject: Re: mysterious buffering and MVC in Objectworks\Smalltalk version 4.1
Date: 6 Oct 92 10:43:56 GMT
Organization: Max-Planck-Institut f"ur Informatik
NNTP-Posting-Host: gs-serv1.dfki.uni-sb.de

In article <golovch.718316580@phoenix.rose.utoronto.ca>, golovch@phoenix.rose.utoronto.ca (Gene Golovchinsky) writes:
|> The reason nothing is displayed when you include the code in a class method
|> is that nothing is executed after the open message to the window.

This was true for former versions of Smalltalk-80 but is no longer true for
Release 4.1. (Note that Sophia's question applied to Release 4.1) Try

|win|
win := ScheduledWindow new open.
win inspect

You will see both windows appear in Release 4.1, the ScheduledWindow and the
Inspector. In releases prior to 4.1 only the ScheduledWindow will appear.

Hubert

-- 
Hubert Baumeister
MPI Informatik, Im Stadtwald, W-6600 Saarbr"ucken, Germany
Phone: (x49-681)302-5432
e-mail: Hubert.Baumeister@mpi-sb.mpg.de
Newsgroups: comp.lang.smalltalk
From: nadja@jetsun.weitek.COM (Nadja Adolf)
Subject: Re: Is Smalltalk the language for us?
Organization: WEITEK Corporation, Sunnyvale CA
Date: Mon, 28 Sep 92 22:33:02 GMT

In article <STEINMAN.92Sep25081636@hawk.is.morgan.com> steinman@is.morgan.com (Jan Steinman) writes:
>I don't really want to start a C++/Smalltalk flamefest. (Use a hammer

>   [C++] Unlike smalltalk, you can dispose of an object; in smalltalk
>   one of my favorite bugs is the notorious 'resurrection bug.' This
>   is a result of the fact that smalltalk objects 'get lost' when they
>   are no longer needed.

>As Mike Khaw pointed out recently, one should not be using
>#allInstances in real code -- it's a diagnostic method. If you're
>getting zombie objects, you're doing something wrong. Lots of
>Smalltalk developers manage to produce things as diverse as
>oscilloscopes to financial applications without ever having a problem
>with this!

Thank you Jan. But what happens when you have something that machine A
thinks is still live (since machine B gave it to it) and it then passes
it back to machine B? Since smalltalk doesn't have destructor behaviors,
one winds up with extra classes to tell machine B that what machine A 
gave it isn't really real anymore...

>Consider also, that in C++ you don't have the option of saying
>#allInstances. One could as easily argue that C++ is bogus becuase you
>can hang on to pointers to locals after a function has returned,
>referring to "zombie object" in the obsolete stack frame. One would be
>equally wrong!

That's nice - but C++ doesn't come equipped with a whole bunch of objects
left over in the development object. You are aware of the little problem
of the Parc smalltalk revs that were carrying around tasks that had become
stopped on semaphores several revs before? These little gems were discovered
after numerous ports and upgrades. Some of them had died at Xerox about
a decade ago - but their little bodies were still around eating up swap
space, and waiting for the semaphore...

>Gee, that's strange. I've moved rather complex images between a Sun, a
>PC-clone, and a Mac, with no problems! Of course, if you use
>machine-specific features, or you write primitives in a
>machine-specific manner, you get what you asked for!

OK. Now try to write a program that has pieces running on all of these
at once, live.

>Another point of view is that if you cannot break your problem down
>into pieces that can be managed by 1-4 person teams, you have a
>non-modular design.

Just what is the most complex project you've ever worked on, anyway?

>Remember: "tight binding, loose coupling". The "leaky object syndrome"
>is a design problem, not a Smalltalk or a C++ problem.

See the above little note on the famous sleeping tasks.
Leaky objects are somewhat encouraged by garbage collectors; especially
when there is a lack of destruction behavior.



-- 
The Earth Pig Bourne....

nadja@node.com (prefered email address)
nadja@weitek.com
Newsgroups: comp.lang.smalltalk
From: jwh@citi.umich.edu (Jim Howe)
Subject: Re: ST/VWin 2.0 upgrade - OVERPRICED???
Date: Mon, 28 Sep 92 09:51:14 EDT
Organization: IFS Project, University of Michigan
Reply-To: jwh@citi.umich.edu

In article <1992Sep16.210551.5658@nstn.ns.ca>, bushell@fox.nstn.ns.ca (Tom Bushell) writes:
|> 
|> So, my question for all of you is:
|> 
|> Am I the only one who thinks this upgrade is grossly overpriced?  Did any
|> of you have the same reaction I did, or are my expectations too high?
|> 

I was offered the chance to upgrade my V/Win and I declined.  I use V for
OS/2 exclusively, but I had previously obtained V/Win via an inexpensive
upgrade.  Had the V/Win upgrade been reasonably priced I would have 
upgraded so that I could have a test platform for applications that
I write that I would like to have run under both Windows and OS/2.

Recently I received an offer to upgrade my V for OS/2 for the amazing
low price of $275 (+ 25 s/h).  A discount of over 70% from their new
list price of $995.  I had to purchase the upgrade but their new pricing
irritates me.  The new version of V for OS/2 is very nice.  I know, because
I was a beta-tester.  However, the improvements made to the system
do not warrant the jump in price to $995.  There aren't any new features
to speak of, other than preformance improvements.  The documentation
may be better, I don't know because I haven't seen it.  With its
new pricing, Digitalk seems to be freezing out small developers.


James W. Howe                  internet: jwh@citi.umich.edu
University of Michigan             uucp: uunet!mailrus!citi.umich.edu!jwh
Ann Arbor, MI   48103-4943         
Xref: sparky comp.lang.smalltalk:1958 comp.lang.eiffel:1189 comp.object:3765
From: mjb@netcom.com (Martin Brown)
Newsgroups: comp.lang.smalltalk
Subject: C&P unofficial WB mods available
Date: 27 Sep 92 16:51:45 GMT
Article-I.D.: netcom.4r#p9jr.mjb
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

I have uploaded to the archives at st.cs.uiuc.edu the file "WB_unupdate.zip" .
It currently resides in pub/tmp, but I have asked that it be moved to st_v .

Essentially, this file contains modifications to Window Builder 2.0 from
Ted Peters of Cooper & Peters, the makers of Window Builder.  

These modifications are very UNOFFICIAL.

The mods address the following problems:

   1) text panes to identify the panes selected from the two palettes along
      the left side.

   2) a text pane to identify the type of pane selected in the layout pane.

   3) a text pane to indicate the size and position of a pane selected in the
      layout pane.

The zip file contains three files:

   info.txt - information
  mail1.bin - the mods from Ted Peters
wndwbldr.cls - slight polishing of the mods I did

All is explained in the text file.

IMO, the mods are quite helpful.

Enjoy.


-- 

                                   - mjb -

                                mjb@netcom.com
Newsgroups: comp.lang.smalltalk,comp.object,comp.lang.objective-c