--
On Thu, 3 Oct 2002 18:46:14
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.
This is the sort of creeping elegance which made me
worry about is/but in the first place.
>
>Also, where do the postconditions go? In the signature at the front?
Well, if pre and post conditions are blocks they don't
have to go in the signature at all. We can affect a
lexical scope outside of the lexical scope, so we can
simply define the PRE and POST blocks lexically to the
method _outside_ of the method. No need to put it in
the signature. Assuming method foo
foo.MY{ PRE } := sub { ... };
This is all contingent on the idea that we can name
lexical scopes (such as with loop labels, named rules
and subs, methods). The precondition here will refer
to whatever method foo is defined, wherever it is
defined in the inheritance heirarchy. If you want to
point to a specific foo, use it's fully qualified
name, if you want to point to a lexically scoped foo
__FILE__.MY{ '&foo' }.MY{ PRE } := sub { ... };
#Ugly, ain't it?
though why you wouldn't want to do it in the method
definition itself is beyond me.
Now this example syntax is ugly intentionally. It's
ugly so that someone smarter than me will feel the
need to fix it. The symbol table, taking a reference
to a class, the %MY stash are all a little vague
anyway, and I'd like to see someone propose good
syntax for it.
-Erik, of the evil mailer
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
>
Is your boss reading your email? ....Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
