Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!microsoft!t-robje From: t-robje@microsoft.UUCP (Rob Jellinghaus) Newsgroups: comp.lang.c++ Subject: Re: Named arguments? Message-ID: <7436@microsoft.UUCP> Date: 18 Aug 89 19:35:46 GMT References: <2179@uw-entropy.ms.washington.edu> <6590229@hplsla.HP.COM> <3671@internal.Apple.COM> Reply-To: t-robje@microsoft.UUCP (Rob Jellinghaus) Organization: Microsoft Corp., Redmond WA Lines: 41 In article <3671@internal.Apple.COM> arn@apple.com (Arn Schaeffer) writes: >In article <6590229@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >> Instead, all those parameters and options should be represented in the >> state of the underlying object, not represented a gigantic list of >options >> to one function. Options are invoked by calling a method, with perhaps >> a parameter or two, to turn on that option. The option being turned on >> is uniquely represented by the name of the method called -- not the name >> of a named argument supplied to that option. Defaults are established >> by the constructor to an object, so that optional methods need not be >> called for standard usage. > >This could have severe implications if an object was shared by more than >one process. In general, it seems that ephemeral information like >parameters should not be part of the state of the object. You're still not seeing it. The example we've been dealing with is that of a graph, which might have a number of different attributes (x, y axis labels, dataset to be plotted, type of graph, etc., etc.) In this case, one might want to define a DATASET class, which contains the data being plotted. This is the information that would be shared between processes. Then one could define a GRAPH object, with the state information of the particular graph to be drawn, which would contain the various parameters of the graph, and a reference to the DATASET to be plotted. This separates the information that should be shared from that which need not be shared (although if you come up with a good graph, you could simply send the GRAPH object to another process in order for that process to be able to produce that graph...). In general, any procedure with many, many parameters is probably a useful, general-purpose, central-to-the-system routine. Any such routine probably encapsulates functionality that could profitably be objectified. Even if you balk at the idea of creating objects that seem to have no purpose other than as argument lists, you should ocnsider the idea carefully. It may lead to a better object-oriented design. >Arnold Schaeffer >arn@apple.com >The opinions expressed are not necessarily those of Apple Computer. Rob Jellinghaus (robertj@CS.Yale.EDU)