RE: Private contracts?
In a message dated Thu, 3 Oct 2002, Garrett Goebel writes: > Michael G Schwern: > > On Thu, Oct 03, 2002 at 05:30:49PM -0400, Trey Harris wrote: > > > In a message dated Thu, 3 Oct 2002, Michael G Schwern writes: > > > > > > > On Thu, Oct 03, 2002 at 03:59:08PM -0400, Mike Lambert wrote: > > > > > With pre/post conditions, a subclass is allowed to weaken the > > > > > preconditions or strengthen the postconditions. > > > > > > > > How exactly does one "weaken" a precondition? > > > > > > You weaken a precondition by adding ORs; you strengthen a > > postcondition by adding ANDs. > > > > As expressions in Perl run a tad beyond simple boolean logic, > > could you give a concrete example? I don't know what you mean. How can a precondition be anything but boolean? > all inherited pre-conditions pass > or > class' own pre-conditions pass I'm afraid I'm a bit lost here. What does "pass" mean besides "evaluates to true in a boolean context"? And if that's what "pass" means, then can't you just OR the preconditions together, in subclass-to-superclass order? Trey
Re: Private contracts?
Michael G Schwern wrote: > How exactly does one "weaken" a precondition? Say I define a mathematical mod() function in my parent number class. precondition: $a > 0, $b > 0, $b is int mod( $a, $b ) Then in my subclass, I want to make it work in a wider variety of contexts. I change the definition to: precondition: $b is int, $b != 0 mod( $a, $b ) It now properly supports modulo arithmetic for negative numbers, because the requirements for running the function have been weakened. It is still completely substitutable anywhere that the parent implementation would work, but if code is dealing with my subclass it is allowed to work with the weakened precondition. Since your proposal was based upon the idea of having every parent condition apply to child implementations, the possibility for strengthened postconditions falls out of the proposal nicely. But since preconditions work in the opposite direction, they don't quite gel with that particular proposal. Mike Lambert
Re: Delegation syntax?
On Fri, Oct 04, 2002 at 12:28:29AM -0400, Trey Harris wrote: > I think my point here is that there are clearly places where we need > stronger built-in support in Perl of some OO concepts. Delegation may not > be one of them--it's easy enough to graft on, and TMTOWTDI may be good > here. Delegation is a basic OO technique. We definately should have fast, well-designed core support for it. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Is there an airport nearby or is that just my tae-kwon-do taking off?
Re: Delegation syntax? (was: Re: Private contracts)
On Thu, Oct 03, 2002 at 07:59:33PM -0600, John Williams wrote: > Reaction #2: Inheritance would automatically delegate all those > methods, so again, in what way does inheritance _not_ solve the problem? I don't think p6l is the right place to discuss the merits of delegation, let's just say it's a Good Thing to have in your OO toolbelt. Solves a lot of problems which would otherwise require hairy, ambiguous multiple inheritance situations. If you're curious I can explain more off-list. > Finally, a question about interfaces: > In what way is an interface different from a pure abstract class (i.e. > containing only method declarations, but no code)? An interface requires subclassers to implement all abstract methods and they must match the method signatures, conditions and invariants of the interface. A pure abstract class doesn't necessarily require subclasses to do anything, at least not in Perl. So an interface is simply a class, maybe abstract, which requires its subclasses to conform to its signature. At least that's how I see it. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One It's Airplane Glue sniffing time!
Re: Delegation syntax?
In a message dated Thu, 3 Oct 2002, Michael Lazzaro writes: > On Thursday, October 3, 2002, at 04:25 PM, Michael G Schwern wrote: > > Class::Delegation? > > Yeah, it's one of the best I've seen: it makes sense, does everything I > want, and is easy to explain even to newbies. The perl5 hash-based > syntax is still pretty scary, tho. > > Dunno, I keep wishing for something that's a one-liner for simple > cases. I guess something like: > > # $.data_manager receives all method calls for which > # it has a matching public interface. > > class DataSnippet { > attr $data_manager is DataManager receives ( -ALL ); > } Looks like a simple Perl 6 grammar munge to me--it's a simple postfix conditional which takes the declaration before it, gets its type (or looks at the code, TMTOWTDI) and creates accessors in the namspace of the caller. Doesn't appear particularly magical to me. In fact, if you didn't mind writing it attr data_manager => DataManager, receives => -ALL; you could easily write it in Perl 5 today. > > # alternative syntax, also useful on a method-by-method basis... > # Note that if steer() has an implementation, it's dispatched there > too. > > class Car is interface { > attr $left_front_wheel; > attr $right_front_wheel; > ... > > method steer ( ... ) is dispatched( $left_front_wheel, > $right_front_wheel ) { ... }; > } This is doable now too: dispatch steer => $left_front_wheel, $right_front_wheel; Could be written in Perl 5, simply enough, as sub dispatch { no strict 'refs'; my ($method, @dispatchees) = @_; *{caller()."::$_[0]"} = sub { $_->$method(@_) foreach @dispatchees; }; } I think my point here is that there are clearly places where we need stronger built-in support in Perl of some OO concepts. Delegation may not be one of them--it's easy enough to graft on, and TMTOWTDI may be good here. > Incidentally, I think the Car above is an example of why it might be ok > to allow attributes in interfaces. (I would definitely argue it's ok > to give default method implementations in interfaces. You don't have > to if you don't believe in it, but hey, some people prefer it.) You're > basically saying that the interface attaches these named attribs to > anything that use it. It usually isn't considered proper, but I don't > know if it's evil enough to explicitly disallow. > > The biggest problem I see with interface attribs myself is > implementational, not philosophical; if you've got attribs being > assembled from multiple interfaces, it makes implementation of > subclasses even more difficult to optimize. (Of course, we already > have multiple inheritance, so that ship's probably long sailed already.) I don't understand. A public attribute will have an autocreated accessor. So put the accessor in the interface, not the attribute. If you put the attribute in the interface, you've committed to having it as an attribute. If you decide to turn it into a computed method, you're out of luck--unless you make the attribute a tied variable itself (gak!). Trey
Re: Private contracts?
In a message dated Thu, 3 Oct 2002, John Williams writes: > On Thu, 3 Oct 2002, Trey Harris wrote: > > > Incidentally, has there been any headway made on how you DO access > > multiple classes with the same name, since Larry has (indirectly) promised > > us that? I.e., I import two classes "LinkedList" and "BTree", both of > > which define a "Node" class? > > Hopefully, LinkedList defines a LinkedList::Node class, and BTree defines > a BTree::Node class. Either by explicitly naming them that or by virtue > of being defined as an "inner" class (which might also make it private). Ah, but that's the way you do it now--name the classes differently. (Easy--assuming you control the source code!) In Perl 6, we're supposed to be able to use multiple versions of the same class concurrently, which I think would imply also being able to use multiple classes that happened to be named the same thing. Trey
Re: Private contracts?
On Thu, 3 Oct 2002, Trey Harris wrote: > Incidentally, has there been any headway made on how you DO access > multiple classes with the same name, since Larry has (indirectly) promised > us that? I.e., I import two classes "LinkedList" and "BTree", both of > which define a "Node" class? Hopefully, LinkedList defines a LinkedList::Node class, and BTree defines a BTree::Node class. Either by explicitly naming them that or by virtue of being defined as an "inner" class (which might also make it private). ~ John Williams
Re: Private contracts?
On Thu, 3 Oct 2002, Allison Randal wrote: > On Thu, Oct 03, 2002 at 03:00:21PM -0400, Michael G Schwern wrote: > > On Thu, Oct 03, 2002 at 02:46:38PM -0400, Michael G Schwern wrote: > > > class ATV is Car, interface { > > > > Hmmm. That should probably be > > > > class ATV isa Car is interface { > > That's: > > class ATV is Car is interface { I'd vote that properties be implemented as classes (see below), which prompts the question, How does one distinguish between a property class which inherits from another property class, and a property class which 'is' some property? Or perhaps there is no difference, because property-ness is actually implemented via inheritance? > We haven't finally decided how properties will be defined. They may be > subs: > they may be methods: > they may be classes: I came to the class implementation conclusion when thinking about runtime properties. Things like "but tainted" obviously need to propogate when operations are performed on them, so other properties, such as "but true/but false", may want to propogate as well. However the rules for propogating "tainted" (result is always tainted) are different from true/false (propogate according to boolean logic) are different from 'but We_better_call_ya("Bruce")' (never, ever propogate). So the obvious way to implement that is via operator overloading for the property classes. If two values have properties of the same type, the same operation performed on the values is performed on the properties. 5 but false + 3 but false == (5 + 3) but (false + false) If only one value has a property, the right thing to do is not entirely clear. Maybe in (5 but false + 3) the false property is combined with the boolean conversion of 3 (true). Or undef if the conversion is not possible. Or maybe I'm rambling on too long... ~ John Williams
Re: Delegation syntax? (was: Re: Private contracts)
On Thu, 3 Oct 2002, Michael Lazzaro wrote: > > 1) Delegation through inheritance: > (a.k.a. "mixin" classes, "hard delegation", "concrete interfaces", > etc., etc.) > > Example: I want to say that a class DataManager has the capabilities > of the interfaces DataStrategy and CacheStrategy, but is not strictly a > "subclass" of either. In other languages, this might appear like: > > class DataManager implements DataStrategy, CacheStrategy { ... } > - or - > class DataManager mixin DataStrategy, CacheStrategy { ... } Aside from runtime mixin', in what way does inheritance _not_ do what you want? > 2) Delegation through attribute: > (a.k.a "soft delegation", "instance-based delegation", etc., etc.) > > The ability to specify that, if an instance of an object DataSnippet > is affiliated with a specific, runtime instance of a DataManager, e.g. > > class DataSnippet { > attr $data_manager is DataManager; > } > > ... then [some, all] public methods of $self.data_manager can > automatically be delegated by the DataSnippet to that specific > instance, eliminating the need for code that makes you want > to kill yourself: > > method foo (...) { $self.data_manager.foo( ... ) } > method bar (...) { $self.data_manager.bar( ... ) } > # ... repeat until carpel tunnel syndrome sets in ... Reaction #1: Only on a perl list would it occur to people to complain about that. :) Reaction #2: Inheritance would automatically delegate all those methods, so again, in what way does inheritance _not_ solve the problem? Finally, a question about interfaces: In what way is an interface different from a pure abstract class (i.e. containing only method declarations, but no code)? ~ John Williams DISCLAIMER: This post assumes perl6 will have multiple inheritance.
Re: Delegation syntax?
On Thursday, October 3, 2002, at 04:25 PM, Michael G Schwern wrote: > On Thu, Oct 03, 2002 at 03:54:09PM -0700, Michael Lazzaro wrote: >> I have no *good* syntax proposals for this, I don't think I've ever >> seen the problem solved with syntax that I really ever liked. > > Class::Delegation? Yeah, it's one of the best I've seen: it makes sense, does everything I want, and is easy to explain even to newbies. The perl5 hash-based syntax is still pretty scary, tho. Dunno, I keep wishing for something that's a one-liner for simple cases. I guess something like: # $.data_manager receives all method calls for which # it has a matching public interface. class DataSnippet { attr $data_manager is DataManager receives ( -ALL ); } # alternative syntax, also useful on a method-by-method basis... # Note that if steer() has an implementation, it's dispatched there too. class Car is interface { attr $left_front_wheel; attr $right_front_wheel; ... method steer ( ... ) is dispatched( $left_front_wheel, $right_front_wheel ) { ... }; } Incidentally, I think the Car above is an example of why it might be ok to allow attributes in interfaces. (I would definitely argue it's ok to give default method implementations in interfaces. You don't have to if you don't believe in it, but hey, some people prefer it.) You're basically saying that the interface attaches these named attribs to anything that use it. It usually isn't considered proper, but I don't know if it's evil enough to explicitly disallow. The biggest problem I see with interface attribs myself is implementational, not philosophical; if you've got attribs being assembled from multiple interfaces, it makes implementation of subclasses even more difficult to optimize. (Of course, we already have multiple inheritance, so that ship's probably long sailed already.) MikeL
Re: Private contracts?
On Thu, Oct 03, 2002 at 07:23:14PM -0400, Michael G Schwern wrote: >invar { .shoulders == .knees == .toes == 2 } This may explain why I can only count to 12 with my shoes off. As this is my 3rd reply to myself in the thread, I'll call it a night. :) -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One If the women don't find you handsome, they should at least find you handy. -- Red Green
Re: Delegation syntax? (was: Re: Private contracts)
On Thu, Oct 03, 2002 at 03:54:09PM -0700, Michael Lazzaro wrote: > I have no *good* syntax proposals for this, I don't think I've ever > seen the problem solved with syntax that I really ever liked. Class::Delegation? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One MERV GRIFFIN!
Re: Private contracts?
On Thu, Oct 03, 2002 at 06:46:14PM -0400, Michael G Schwern wrote: > I see us already smashing too many things into the method signature as it > is. It will rapidly get messy if you have a method with a complex signature > and a handful of attributes and preconditions. I think I have my own counter example. Consider defining an abstract class with an interface and I want to put some conditions onto an abstract method. class Abstract::Human is interface { attr head, shoulders, knees, toes; invar { .head == 1 } invar { .shoulders == .knees == .toes == 2 } method eat ($food) is pre { !$food.isa('Poison') } is post { .return eq 'Burp' } } since I have no method body for eat() I have no choice but to hang it off the signature as an attribute. So conditions do have to go on the signature, but I still like the option of their being in the body as well, especially given the problem of wanting to put post conditions at the end. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Cottleston, Cottleston, Cottleston Pie. A fly can't bird, but a bird can fly. Ask me a riddle and I reply: "Cottleston, Cottleston, Cottleston Pie."
Re: Private contracts?
On Thu, Oct 03, 2002 at 04:47:26PM -0500, Garrett Goebel wrote: > > And if we make pre/post conditions and class invariants > > always enforced... > > no. > > post-conditions and invariants are always enforced, but pre-conditions are > different. Right, right. > A derived interface can loosen input constraints... so it must be > able to either satisfy all inherited pre-conditions _or_ its own > pre-conditions. Looking around, this seems to be regarded as something of a compromise because truly determining what a real logical weaking is is hard. Are there other ways to do it, just to mull them over? > > shouldn't we have private invariants and conditions? > > no. Ummm, why? > I should inject that I disagree with the use of term private as meaning > non-inheritable. I think of private as an methods and attributes accessible > only within the namespace of that class or its descendants. Isn't that "protected"? As I understand it, Perl 6's private will be non-inheritable methods accessable only inside the class which defined it. Ruby does it this way, AFAIK. > Perhaps a better > term would be something like: > > method foo is disinherited { ... } is disowned is get_a_haircut_and_a_job is i_have_no_son ;) > I also need to separate out the DBC topic from the interface one. For > instance I have a hard time thinking about attributes in the context of > interfaces. For me, interfaces should be limited to a bunch of abstract > methods with conditions. Any other declarations within an interface IMO > should be errors. I.e., all other declarations belong in the implementation > class... 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. class Human is interface { attr head, shoulders, knees, toes; invar { .head == 1 } invar { .shoulders == 2 } invar { .knees == 2 } invar { .toes == 10 } method talk ($say,$how_loud) { $say.uc if $how_loud >= 10: print "$say\n"; } } 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. class AbstractHuman is interface { attr head, shoulders, knees, toes; invar { .head == 1 } invar { .shoulders == 2 } invar { .knees == 2 } invar { .toes == 10 } method talk ($say,$how_loud); } class Human isa AbstractHuman { method talk ($say,$how_loud) { $say.uc if $how_loud >= 10: print "$say\n"; } } The above would result in the same thing. The latter explicitly seperates the interface from the implementation, as some like, while the former does them all in one class, as others like. > If you want to have a public and private "inheritable" interfaces that's > fine. But what's the point of a non-inheritable interface? Myself, I call > non-inheritable methods "functions". "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. Method signatures are obviously used to define how methods are to be called by outside users of the object, as well as change the contexts in which the arguments are parsed. Pre/post conditions and invariants, when private (ie. not inherited) can be used like assertions, guaranteeing that internal state and implementation details are kept sane. My ATV example may not have been clear enough in that I considered the tilt check to be an internal state check and not a documented feature of the object. A clearer example might be something like checking that an internal data structure used by the object is not circular. A class invariant, yet not something I want to enforce on my children. They're tools that when combined form an "interface" but are still useful seperately. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One The key, my friend, is hash browns. http://www.goats.com/archive/980402.html
RE: Private contracts?
Michael G Schwern: > On Thu, Oct 03, 2002 at 05:30:49PM -0400, Trey Harris wrote: > > In a message dated Thu, 3 Oct 2002, Michael G Schwern writes: > > > > > On Thu, Oct 03, 2002 at 03:59:08PM -0400, Mike Lambert wrote: > > > > With pre/post conditions, a subclass is allowed to weaken the > > > > preconditions or strengthen the postconditions. > > > > > > How exactly does one "weaken" a precondition? > > > > You weaken a precondition by adding ORs; you strengthen a > postcondition by adding ANDs. > > As expressions in Perl run a tad beyond simple boolean logic, > could you give a concrete example? all inherited pre-conditions pass or class' own pre-conditions pass -- 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]
Delegation syntax? (was: Re: Private contracts)
On Thursday, October 3, 2002, at 03:18 PM, Paul Johnson wrote: >> (As a lame aside, are we going to have a concept of "private" vs. >> "protected" vs. "public", or just private/public? > > No protected. Even Stroustrup admits it was a mistake in D&E. Oh, thank God. I was hoping people would say that. OK, for an entirely different thread... Is there an accepted preliminary syntax for OO delegation? (I've looked and can't find anything definitive.) By "delegation", I mean two different things (you can tell OO programming has firmly arrived by the fact that, Babel-like, no group of people can ever agree on the meaning of any given term, making all conversations painful). 1) Delegation through inheritance: (a.k.a. "mixin" classes, "hard delegation", "concrete interfaces", etc., etc.) Example: I want to say that a class DataManager has the capabilities of the interfaces DataStrategy and CacheStrategy, but is not strictly a "subclass" of either. In other languages, this might appear like: class DataManager implements DataStrategy, CacheStrategy { ... } - or - class DataManager mixin DataStrategy, CacheStrategy { ... } (yes, I know you probably wouldn't do a Manager/Strategy like that. it's just an example, and my mind is blanking right now...) 2) Delegation through attribute: (a.k.a "soft delegation", "instance-based delegation", etc., etc.) The ability to specify that, if an instance of an object DataSnippet is affiliated with a specific, runtime instance of a DataManager, e.g. class DataSnippet { attr $data_manager is DataManager; } ... then [some, all] public methods of $self.data_manager can automatically be delegated by the DataSnippet to that specific instance, eliminating the need for code that makes you want to kill yourself: method foo (...) { $self.data_manager.foo( ... ) } method bar (...) { $self.data_manager.bar( ... ) } # ... repeat until carpel tunnel syndrome sets in ... I have no *good* syntax proposals for this, I don't think I've ever seen the problem solved with syntax that I really ever liked. MikeL
Re: Private contracts?
On Thu, Oct 03, 2002 at 05:30:49PM -0400, Trey Harris wrote: > In a message dated Thu, 3 Oct 2002, Michael G Schwern writes: > > > On Thu, Oct 03, 2002 at 03:59:08PM -0400, Mike Lambert wrote: > > > With pre/post conditions, a subclass is allowed to weaken the > > > preconditions or strengthen the postconditions. > > > > How exactly does one "weaken" a precondition? > > You weaken a precondition by adding ORs; you strengthen a postcondition by > adding ANDs. As expressions in Perl run a tad beyond simple boolean logic, could you give a concrete example? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One My beverage utensil experiences a volume crisis.
Re: Private contracts?
On Thu, Oct 03, 2002 at 02:29:57PM -0700, Michael Lazzaro wrote: > Do you think it's sufficiently clear to newbies that the pre { } is > associated with the "signature" of the turn() interface method, and not > just the _implementation_ of turn() in Vehicle? The rule would be pretty simple to teach and remember, "conditions and invariants are inherited unless made private". -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One It's Flypaper Licking time!
Re: Private contracts?
On Thu, Oct 03, 2002 at 05:23:08PM -0500, Jonathan Scott Duff wrote: > I don't know, but I think it's supposed to be like this: > > # part of the signature > method turn($dir,$ang) is pre { $ang <= 20 } { > ... > } > > # part of the implementation > method turn($dir,$ang) { > PRE { $ang <= 20 } > ... > } > > turn() methods of derived classes would inherit the precondition in the > first case but not the second. I don't know why you'd want to do this > exactly, but it seems to me that perl should allow it. I see us already smashing too many things into the method signature as it is. It will rapidly get messy if you have a method with a complex signature and a handful of attributes and preconditions. Also, where do the postconditions go? In the signature at the front? That doesn't make sense, it should go at the end so you can keep them in mind when you're writing the return code. Consider... method foo($this, $that) is memoized is something is pre { $this <= 42 } is pre { $that == $this / 2 } is pre { a lot of code which is hard to shove into a block of code this close to the right margin } is post { what is a post condition doing at the front? } { ... } They can, of course, be pulled back from the margin: method foo($this, $that) is memoized is something is pre { $this <= 42 } is pre { $that == $this / 2 } is pre { now we have a little bit more room to play with using a differnt indentation style } is post { but post conditions are still distanced from the code which return()s } { ... } I realize that conditions are technically part of the signature, but putting them in there paints us into a stylistic corner. I'm also not fond of the pre/PRE distinction. Few of the other special blocks (given, eval, try, invar, etc...) use all cap names. At least I hope not. Simply attaching an "is private" attribute to a pre condition block seems the simplest way to go about it. Just like any other private thing, it's not inherited and not visible outside the current class. "pre" vs "PRE" doesn't convey that meaning. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One AY! The ground beef, she is burning my groin! http://sluggy.com/d/990105.html
Re: Private contracts?
On Thu, Oct 03, 2002 at 04:54:13PM -0500, Garrett Goebel wrote: > Garrett Goebel: > > Michael G Schwern: > > > But I don't want my subclasses to be constrained by that. > > > It's just an implementation detail that I only wish to > > > enforce upon ATV and not it's children. > > implementation details don't belong in interfaces It's encoded as a private condition, so it's not part of the interface. I see class invariants and conditions as just powerful, well organized assertions, so naturally I'm going to want to use them for more than just specifying an interface contract. In this case, I'm using them to ensure that internal details of my implementation are kept in order. It would be silly to have to define a whole new syntax for that purpose, so I just make them private. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One The eye opening delightful morning taste of expired cheese bits in sour milk!
Re: Private contracts?
On Thu, Oct 03, 2002 at 02:29:57PM -0700, Michael Lazzaro wrote: > One question I still have is the syntax of pre/post conditions, e.g: > > > method turn($direction, $how_sharp) { > > pre { $how_sharp <= 20 } is private; > > ...implementation... > > } > > This is obviously how it would fall out from Apocalypse 4, "pre/post" > being basically types of exception, but I keep having nagging concerns > about it. To me, this keeps looking like "pre { ... }" is a > precondition attached to the _implementation_ of the given method, not > the _signature_ of a given method... I don't know, but I think it's supposed to be like this: # part of the signature method turn($dir,$ang) is pre { $ang <= 20 } { ... } # part of the implementation method turn($dir,$ang) { PRE { $ang <= 20 } ... } turn() methods of derived classes would inherit the precondition in the first case but not the second. I don't know why you'd want to do this exactly, but it seems to me that perl should allow it. > On Thursday, October 3, 2002, at 01:11 PM, Allison Randal wrote: > > BTW, that's: > >attr $.tilt; > > Attributes are private by default. > > (As a lame aside, are we going to have a concept of "private" vs. > "protected" vs. "public", or just private/public? (In other words, > does "private" permit access by subclasses?) Not recommending it, just > wondering if anyone thinks we need it.) I don't think we should be actively reproducing C++'s mistakes :-) With the constructs shown so far, I can guess that it should be possible for someone to implement "protected" if they wanted it. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Private contracts?
On Thu, Oct 03, 2002 at 02:29:57PM -0700, Michael Lazzaro wrote: > (As a lame aside, are we going to have a concept of "private" vs. > "protected" vs. "public", or just private/public? No protected. Even Stroustrup admits it was a mistake in D&E. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
RE: Private contracts?
Garrett Goebel: > Michael G Schwern: > > But I don't want my subclasses to be constrained by that. > > It's just an implementation detail that I only wish to > > enforce upon ATV and not it's children. implementation details don't belong in interfaces
Re: Private contracts?
In a message dated Thu, 3 Oct 2002, Allison Randal writes: > So far, classes are uppercase and properties are lowercase, but that's > convention, not law. Do runtime (value) properties and compile-time (variable) properties share the same namespace? That is, to go back to an earlier discussion, if there is a system-defined value property C which marks a value as true in boolean contexts, can I also define a compile-time property C that makes the variable evaluate as true, whatever its value? Trey
RE: Private contracts?
Michael G Schwern: > > I've been mucking about a bit more with this whole interface thing. > > So if we make method signatures only enforced on subclasses > if the parent class or method has the interface property... > > except private methods, obviously. > > And if we make pre/post conditions and class invariants > always enforced... no. post-conditions and invariants are always enforced, but pre-conditions are different. A derived interface can loosen input constraints... so it must be able to either satisfy all inherited pre-conditions _or_ its own pre-conditions. > shouldn't we have private invariants and conditions? no. I should inject that I disagree with the use of term private as meaning non-inheritable. I think of private as an methods and attributes accessible only within the namespace of that class or its descendants. Perhaps a better term would be something like: method foo is disinherited { ... } I also need to separate out the DBC topic from the interface one. For instance I have a hard time thinking about attributes in the context of interfaces. For me, interfaces should be limited to a bunch of abstract methods with conditions. Any other declarations within an interface IMO should be errors. I.e., all other declarations belong in the implementation class... If you want to have a public and private "inheritable" interfaces that's fine. But what's the point of a non-inheritable interface? Myself, I call non-inheritable methods "functions". > class ATV is Car, interface { > attr _tilt is private; > invar { ._tilt <= 20 } is private; > > method turn($direction, $how_sharp) { >pre { $how_sharp <= 20 } is private; >...implementation... > } > } An interface shouldn't have attributes. And per above, private pre-conditions are pointless. I would rewrite the above as: class ATV is Car, interface { invar { .tilt <= 20 }; method tilt() is private; # in the "to class heirachy" sense method turn($direction, $how_sharp) { pre { $how_sharp <= 20 }; } } > I've implemented an ATV where I've put in a saftey > protection against rolling over in a turn as both an > invariant and a pre-condition. It will not allow you > to turn the car too sharply, else it simply blows up. > Wait second... ;) > > But I don't want my subclasses to be constrained by that. > It's just an implementation detail that I only wish to > enforce upon ATV and not it's children. So they're > private. > > Makes sense, no? No. Per DBC, pre-conditions are satisfied if either the inherited pre-conditions _or_ its own pre-conditions are satisfied. Thus allowing the loosening of input constraints which I believe is what you're after. -- 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]
Re: Private contracts?
On Thu, Oct 03, 2002 at 05:14:22PM -0400, Michael G Schwern wrote: > On Thu, Oct 03, 2002 at 03:45:33PM -0500, Allison Randal wrote: > > On Thu, Oct 03, 2002 at 03:00:21PM -0400, Michael G Schwern wrote: > > > On Thu, Oct 03, 2002 at 02:46:38PM -0400, Michael G Schwern wrote: > > > > class ATV is Car, interface { > > > > > > Hmmm. That should probably be > > > > > > class ATV isa Car is interface { > > > > That's: > > > > class ATV is Car is interface { > > Wouldn't this mean that class names and property names will inevitably > clash, so you can't have a class and a property with the same name? Yes. But if properties are classes (the generally favored solution, at least until Zurich), that's to be expected. So far, classes are uppercase and properties are lowercase, but that's convention, not law. Allison
Re: Private contracts?
In a message dated Thu, 3 Oct 2002, Michael G Schwern writes: > On Thu, Oct 03, 2002 at 03:59:08PM -0400, Mike Lambert wrote: > > With pre/post conditions, a subclass is allowed to weaken the > > preconditions or strengthen the postconditions. > > How exactly does one "weaken" a precondition? You weaken a precondition by adding ORs; you strengthen a postcondition by adding ANDs. Trey
Re: Private contracts?
> Makes sense, no? I like that quite a lot. One question I still have is the syntax of pre/post conditions, e.g: > method turn($direction, $how_sharp) { >pre { $how_sharp <= 20 } is private; >...implementation... > } This is obviously how it would fall out from Apocalypse 4, "pre/post" being basically types of exception, but I keep having nagging concerns about it. To me, this keeps looking like "pre { ... }" is a precondition attached to the _implementation_ of the given method, not the _signature_ of a given method... For the "is private" case above, it doesn't make much difference, but I keep thinking something like the below just feels wonky (?)... class Vehicle is interface { attr $tilt; attr $min_sharpness; method turn($direction, $how_sharp) { pre { $how_sharp <= $self.min_sharpness } ... a default implementation, if desired ... } } class Car is Vehicle { method turn { # this calls the precondition ... $self.SUPER.turn( ... );# ... hopefully not twice? ... ... a derived implementation ... } } class Cycle is Vehicle { method turn { # does this call the precondition? YES? ... a completely alternative implementation that doesn't call super } } Do you think it's sufficiently clear to newbies that the pre { } is associated with the "signature" of the turn() interface method, and not just the _implementation_ of turn() in Vehicle? e.g. I want a precondition associated with turn() that is called for _all_ subclasses, whether they call the superclass implementation of turn() or not, is it clear that that's going on? _IS_ it going on, in the above? On Thursday, October 3, 2002, at 01:11 PM, Allison Randal wrote: > BTW, that's: >attr $.tilt; > Attributes are private by default. (As a lame aside, are we going to have a concept of "private" vs. "protected" vs. "public", or just private/public? (In other words, does "private" permit access by subclasses?) Not recommending it, just wondering if anyone thinks we need it.) MikeL
Re: Private contracts?
In a message dated Thu, 3 Oct 2002, Allison Randal writes: > However they're defined, they will be clearly marked internally as > properties, so there's little risk of confusing property attachment with > inheritance. except that they seem to share a single namespace, since both user-defined properties and classes have the naming convention of an initial capital letter and following mixed-case word characters. Since they're both introduced with C, you may be able to define both a property C and a class C, but you wouldn't be able to use them both, right? Incidentally, has there been any headway made on how you DO access multiple classes with the same name, since Larry has (indirectly) promised us that? I.e., I import two classes "LinkedList" and "BTree", both of which define a "Node" class? Trey
Re: Private contracts?
On Thu, Oct 03, 2002 at 03:59:08PM -0400, Mike Lambert wrote: > With pre/post conditions, a subclass is allowed to weaken the > preconditions or strengthen the postconditions. How exactly does one "weaken" a precondition? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Home of da bomb
Re: Private contracts?
On Thu, Oct 03, 2002 at 03:45:33PM -0500, Allison Randal wrote: > On Thu, Oct 03, 2002 at 03:00:21PM -0400, Michael G Schwern wrote: > > On Thu, Oct 03, 2002 at 02:46:38PM -0400, Michael G Schwern wrote: > > > class ATV is Car, interface { > > > > Hmmm. That should probably be > > > > class ATV isa Car is interface { > > That's: > > class ATV is Car is interface { Wouldn't this mean that class names and property names will inevitably clash, so you can't have a class and a property with the same name? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One The key, my friend, is hash browns. http://www.goats.com/archive/980402.html
Re: Private contracts?
On Thu, Oct 03, 2002 at 03:00:21PM -0400, Michael G Schwern wrote: > On Thu, Oct 03, 2002 at 02:46:38PM -0400, Michael G Schwern wrote: > > class ATV is Car, interface { > > Hmmm. That should probably be > > class ATV isa Car is interface { That's: class ATV is Car is interface { We haven't finally decided how properties will be defined. They may be subs: sub *PropertyName is property ($referent, $data) {...} they may be methods: method PropertyName is property ($self: $data) {...} they may be classes: class PropertyName is Property {...} # or, like grammar definitions property PropertyName {...} or they may be some variation on these or something else entirely. However they're defined, they will be clearly marked internally as properties, so there's little risk of confusing property attachment with inheritance. Allison
Re: Private contracts?
On Thu, Oct 03, 2002 at 02:46:38PM -0400, Michael G Schwern wrote: > > attr _tilt is private; BTW, that's: attr $.tilt; Attributes are private by default. Allison
Re: Private contracts?
> I've been mucking about a bit more with this whole interface thing. > > So if we make method signatures only enforced on subclasses if the parent > class or method has the interface property... > > except private methods, obviously. > > And if we make pre/post conditions and class invariants always enforced... > > shouldn't we have private invariants and conditions? Semi-tangential to the point of your message... With pre/post conditions, a subclass is allowed to weaken the preconditions or strengthen the postconditions. The postcondition is not really a problem since one can always add additional checks. However, if the parent's preconditions apply to the child invariably, it would be rather difficult to make your subclass accept a wider variety of input. I'm not proposing a solution, but rather just a problem to keep in mind. Mike Lambert
Re: Private contracts?
On Thu, Oct 03, 2002 at 02:46:38PM -0400, Michael G Schwern wrote: > class ATV is Car, interface { Hmmm. That should probably be class ATV isa Car is interface { -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Help, help! A Heffalump, a Horrible Heffalump! Help, help, a Herrible Hoffalump! Hoff, Hoff, a Hellible Horralump!
Private contracts?
I've been mucking about a bit more with this whole interface thing. So if we make method signatures only enforced on subclasses if the parent class or method has the interface property... except private methods, obviously. And if we make pre/post conditions and class invariants always enforced... shouldn't we have private invariants and conditions? class Car is interface { attr wheels; invar { .wheels == 4 } method accel($how_fast); method turn($direction, $how_sharp); } class ATV is Car, interface { attr _tilt is private; invar { ._tilt <= 20 } is private; method turn($direction, $how_sharp) { pre { $how_sharp <= 20 } is private; ...implementation... } } I've implemented an ATV where I've put in a saftey protection against rolling over in a turn as both an invariant and a pre-condition. It will not allow you to turn the car too sharply, else it simply blows up. Wait second... ;) But I don't want my subclasses to be constrained by that. It's just an implementation detail that I only wish to enforce upon ATV and not it's children. So they're private. Makes sense, no? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Remember, any tool can be the right tool. -- Red Green