Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!tness7!tness1!sugar!peter From: peter@sugar.UUCP (Peter da Silva) Newsgroups: comp.sys.amiga.tech Subject: Re: Object Oriented IPC -- Some reservations Summary: Poking my fingers into the pie. Message-ID: <2313@sugar.UUCP> Date: 15 Jul 88 17:50:42 GMT References: <11750@agate.BERKELEY.EDU> <6524@well.UUCP> Organization: Sugar Land UNIX - Houston, TX Lines: 45 ... and stirring up trouble ... In article <6524@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes: > Probably calling it IPC is a mistake. It should probably be called > something else. How about OO-OSE, object oriented operating system extensions. (then my idea for procedural subsets would be local OO/OSE, and seperate servers are a global OO/OSE...) > In the example given of the FILE - IFF - ILBM class hierarchy, you > probably wouldn't want to override the reading method when creating each > subclass. You might want to read and IFF as if it were a FILE for > example, so you could call the different methods FILE/READ, IFF/RIFF, > and ILBM/RDBM. This would allow you to READ an ILBM as if it were a > file, RIFF it as if it were an IFF, or RDBM it like a bitmap. I don't like this idea. Better to set up different objects of the appropriate type. Why would you want to do a FILE/READ on an object of type ILBM? There isn't any meaningful place to read into. > | I get the feeling that we're reaching a consensus that BOTH PPIPC and > | OOIPC will have their place... > I doesn't make sense to have TWO "standards." Either paradigm could be > implemented as a sub-set of the other, it's just a question of which way > is more elegant (or more Zen, as some people would say ;-). They're both Zen, but for different models. My original idea for IPC was that you would eventually be able to write programs in it, graphically, the way you can with UNIX pipelines. You just have your programs that act as generators and filters and stick them together with lines in a patch-panel sort of thing. Like if you wanted to filter an IFF image you'd have your "ILBM" icon which reads an IFF file and wraps it in a message and writes it to its output port. Your filter icon would take the ILBM and do a transform on it. Your display icon would take the ILBM and pop it up. If you wanted to edit it or save it instead you'd pop in the appropriate icons. It seems this would be easier with PPIPC, but it shouldn't be impossible with OOIPC. Why don't you two guys take a crack at it? -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to alt.dev.null. -- "Running OS/2 on a '386 is like pulling your camper with an Indy car"