Newsgroups: comp.object,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!europa.chnt.gtegsc.com!news.sprintlink.net!noc.netcom.net!netcomsv!uu3news.netcom.com!netcomsv!uucp3.netcom.com!slcgate!servio!servio!marcs
From: marcs@slc.com (Marc San Soucie)
Subject: Re: Feeding complete Object (Data and Behaviour) to other modules
Message-ID: <marcs.803511808@servio>
Sender: news@slc.com (USENET News)
Nntp-Posting-Host: servio
Organization: GemStone Systems, Inc., Beaverton OR, USA
References: <3rhii9$ij7@rainbow.rmii.com>
Date: 18 Jun 95 21:43:28 GMT
Lines: 25
Xref: glinda.oz.cs.cmu.edu comp.object:33063 comp.lang.smalltalk:24766

opm@rainbow.rmii.com (OmpraKash Mishra) writes:

> 	I am working on project which designed as Parallel/Pipeline 
> architecture. I have to come up with method where I will able to pass 
> the whole Smalltalk object with data and behaviour to the system 
> running in parallel implemented in non Smalltalk. The downstream 
> system don't want to accept just attribute or data, i.e., they don't 
> want to rewrite methods to process them. 

It might make sense to consider using an object database for this. If the
shared objects (and their classes and methods) reside in a repository
accessible to all clients, you won't have to "pass" them back and forth.
You need only have all clients read and update them as needed, paying
attention to concurrency issues when updating, of course. GemStone could do
this, as you can store and execute methods in GemStone, and access the
objects from Smalltalk, C++, or C.

However, you haven't said much about the object manipulation requirements
of your system. For some problems a separate database may be too large an
instrument.

    Marc San Soucie
    GemStone Systems, Inc.
    Beaverton, Oregon
    marcs@slc.com
