Michael G Schwern: > Garrett Goebel wrote: > > Michael G Schwern: > > > ....shouldn't we have private invariants and conditions? > > > > no. > > Ummm, why? Maybe I'm just grinding an ax...
If you allow an interface's post conditions and invariants to be overlooked, then you've got a broken interface. If you derive an interface then you've got to garrauntee to satisfy the same output and invariant constraints. You can't pick and chose, or your not deriving an interface. You're coming up with a new one. I think my ax could rest more peacefully if I could see more clearly how the syntax would allow us to clearly disambiguate between the interface and the implementation; constraints on a method's inputs and outputs as separate from how its implemented. > I hope we're not going to explicitly seperate interfaces from > implementation. ie. That you can define an interface at the > same time as you implement it. This is something I really > like about Perl as opposed to other OO systems, class > definition and implementation are not kept seperate. I hope we do when we explicitly flag a class as an interface. After all, a class which isn't explicitly qualified as an interface still has one. And you can still attach pre, post, and invariant conditionals to its methods and attributes. I'd be a whole lot more happy with your syntax if you weren't explicitly hanging the 'is Interface' attribute off them. How can you garrauntee the interface when you conflate it with the implementation? It becomes difficult to separate the two. But I suppose that is what your private idea is all about. In the context of a class private means "just don't inherit this". In the context of an interface private means "this is not part of the interface". It still looks like it'll be messy when deep inheritence is involved. I guess I'm kosher with private conditions and invariants in the sense that any conditions on a private method or attribute would implicitly not be inherited. So long as private method is not considered part of an interface. However, I would still disagree with allowing private conditions on non-private methods. At least not when you're tagging the class with a label declaring it to be an interface, since non-private methods are implicitly part of the interface. > Of course, if "interfaces" in the Java sense are just classes with no > implementation details, there's no reason why you can't do it > seperately. TIMTOWTDI. But if you're going to explicitly label something as an interface, the bondage and discipline ought to be consistent with DBC principles. > "Interface" is not quite simply the union of "method signature", > "conditions" and "invariants". Interfaces are a combination > of the three, true, but it's only a subset of their use. > They're all useful beyond simply enforcing how subclasses are > designed and implemented. Understood. But again, if you're hanging an "Interface" tag on a class, you ought to be constricted to using them according to what they mean in the context of an interface. In short, go ahead and write it in a single class. You know where the interface leaves off and the implementation begins. Just don't hang the 'Interface' attribute off it. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
