Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!spock!kim From: kim@spock (Kim Letkeman) Newsgroups: comp.object Subject: Re: Should a constructor do "work"? Message-ID: <3929@kim> Date: 19 Jul 90 13:16:42 GMT References: <55236@microsoft.UUCP> <519@tetrauk.UUCP> <364@eiffel.UUCP> Followup-To: comp.object Organization: Mitel. Kanata (Ontario). Canada. Lines: 48 In-reply-to: wex@dali.pws.bull.com's message of 18 Jul 90 16:07:47 GMT In article , wex@dali.pws.bull.com (Buckaroo Banzai) writes: | In article <364@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: | If invariants are checked and a creation operation raises | an exception, the target of the Create should remain void, | excluding any creation of an inconsistent object. | | I don't understand why this is so. I agree that it's one way to specify a | language, but surely it's not the only way. It is one of the best ways to avoid introducing a significant increase in complexity - that being the change from having two states for an object reference (good or bad) to having three (good, bad, we're not sure.) I've seen a lot of code that attempted to compensate for incomplete initialization and other subtle failures. Code that treats the world in a more binary fashion has (in my experience) always been simpler, faster and just as useful. | For example, let's say that I create an object, and as part of that | creation, I wish to initialize some of its slots (oops, my CLOS is showing | :-). | | Suppose then that some of the initialization fails. Can't I write a | specification that says "the value will be a list of numbers or NULL"? Then | when the initialization fails, I can return an object with that particular | slot having a NULL value. | | This would fulfill the specification; are you saying that this would not | "raise an exception" in the sense that you mean it above? You're really just saying that your class invariant would allow for some of the "slots" to be NULL. I.e. a failure during initialization of some of the slots would not actually violate the invariant. If your object is actually useful with these slots NULL, then you are being completely consistent with Meyer's statement above. If, on the other hand, your object is not useful (requiring a lot of extra code to handle special cases where NULL slots exist), then you have violated Meyer's statement and created an incorrect class invariant. I believe that an object should function exactly as the interfaces (methods, features ...) intend from the very moment of creation, or not exist at all. -- Kim Letkeman mitel!spock!kim@uunet.uu.net