paj@uk.co.gec-mrc (Paul Johnson) (11/22/90)
What happens if you define a "Create" procedure in an Eiffel class as a "once" procedure? The book (Eiffel: The Language 2.2) does not seem to say. If it is not defined, may I propose the following semantics: Given a class FOO with "Create is once....end", and some other class containing a variable foo:FOO, then the first "foo.Create" should create an instance of FOO and set foo to refer to it. Subsequent "foo.Create"s should simply set foo to the first instance of FOO. Of course the instance should be safe from garbage collection. The reason I want this is so that when I define a class where all instances will be the same in any execution (a command line parser for example) I only need one class. At present I need two: one to parse the command line and one to have a "once" function. Paul. Paul Johnson UUCP: <world>!mcvax!ukc!gec-mrc!paj --------------------------------!-------------------------|------------------- GEC-Marconi Research is not | Telex: 995016 GECRES G | Tel: +44 245 73331 responsible for my opinions. | Inet: paj@uk.co.gec-mrc | Fax: +44 245 75244
rick@tetrauk.UUCP (Rick Jones) (11/23/90)
In article <714@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes: > >What happens if you define a "Create" procedure in an Eiffel class as a >"once" procedure? The book (Eiffel: The Language 2.2) does not seem >to say. > > ... > >The reason I want this is so that when I define a class where all >instances will be the same in any execution (a command line parser for >example) I only need one class. At present I need two: one to parse >the command line and one to have a "once" function. This is essentially the "global object" problem, and I'm not sure that Creates as once routines is a good idea (what Eiffel actually does with Create-once at the moment I'm not certain - I think the compiler should bounce it). I have a number of global objects in my development, and I find the simplest way to deal with them is to use global definition classes from which all interested classes inherit. Such definition classes can be used to define constant attributes as well as global objects (which can be thought of as constant objects). The use of inheritance is here more analogous to including header files in C or other conventional languages (aside - is OOP still UNconventional?). Such a class looks like: class DEFS feature Const1: INTEGER is 1 ; Const2: INTEGER is 2 ; Const3: INTEGER is 3 ; -- etc ... foo: FOO is once Result.Create ; end ; -- etc ... end Hence any class which inherits from DEFS can refer to foo as an attribute of the Current object, and all classes will share only one instance. In a large system it may be appropriate to have multiple definition classes, each concerned with a particular group of cooperating classes which can be treated as a subsystem. My main objection to making Create a once routine as Paul suggests is that you embed in the _class_ the fact that you can only create one instance of this class in any program in which you use it. This seems an unnecessary constraint if possible future reuse is considered - you can't anticipate an application where you might want to reuse the class and have more than one instance. However, the definitions class will generally be specific to one program or project, and provides some of the glue which defines how all the components interact. It does this without compromising the encapsulation and modularity of the individual classes, thus maximising their potential for reuse. -- Rick Jones Was it something important? Maybe not Tetra Ltd. Maidenhead, What was it you wanted? Tell me again I forgot Berks, UK -- Bob Dylan rick@tetrauk.uucp