From: "Adam P. Jenkins" Date: 2005-07-09T03:20:48+09:00 Subject: Re: Inheriting Array and slice() behaviour Pit Capitain wrote: > William Morgan schrieb: > >> Excerpts from Ara.T.Howard's mail of 7 Jul 2005 (EDT): >> >>> On Fri, 8 Jul 2005, William Morgan wrote: >>> >>>> My problem with Array#slice is that the objects created will never >>>> have #initialize called. Indeed, they never *can* have it called, >>>> because who knows what arguments need to be supplied. >>> >>> >>> it's this simple: >> >> >> >> Actually, it's even simpler---the author of Expression can simply >> override #slice to do the right thing. The point is that the *author* >> must do this explicitly. If Ruby tries to do this automatically, it will >> return invalid objects. >> >> In short, the current #slice behavior is a) wrong in non-trivial cases, >> b) magic, and c) inconsistent with #+ and other methods. > > > The LSP has been mentioned before in this thread. According to that > principle, if someone creates a subclass of Array, you should be able to > use the subclass like the original Array class. Array has a well defined > #initialize method that can take zero arguments. So should the subclass, > otherwise you're breaking the LSP. In other words, it's perfectly legal > to call self.class.new in #slice. If Expression can't provide an > #initialize method without arguments, it shouldn't be a subclass of Array. The LSP is defined in terms of particular interfaces. Given an interface IF, according to the LSP I should be able to use any object which claims to implement IF interchangably, without having to be aware of the object's specific type, as long as I'm only using the functionality specified by IF. When it comes to is-a relationships, I've never seen the LSP interpreted to mean subclasses must have the same constructor signatures as their superclasses. The constructors are generally considered to be outside the scope of the interface, unless explicitly stated otherwise. Adam