[#3741] Re: Why it's quiet -- standard distribution issues — Aleksi Niemel<aleksi.niemela@...>
I think it's the feature of the mailing list archive to create a threads of
[#3756] RE: XMP on comments — Aleksi Niemel<aleksi.niemela@...>
> require "xmp"
[#3766] modulo and remainder — Dave Thomas <Dave@...>
[#3776] Kernel.rand — Aleksi Niemel<aleksi.niemela@...>
How about defining:
[#3781] Widening out discussions — Dave Thomas <Dave@...>
[#3795] Re: Array.uniq! returning nil — Aleksi Niemel<aleksi.niemela@...>
> As matz said in [ruby-talk:3785] and Dave said in [ruby-talk:1229],
Hi, Aleksi,
[#3823] Re: Array.pick — Aleksi Niemel<aleksi.niemela@...>
> > Just a general comment--a brief statement of purpose and using
[#3827] JRuby? — Aleksi Niemel<aleksi.niemela@...>
Is there or will there be Ruby equivalent of JPython?
[#3882] Re: Array.uniq! returning nil — Aleksi Niemel<aleksi.niemela@...>
> |look too strange, confusing, or cryptic. Maybe just @, $, %, &.
Hi,
[#3918] A question about variable names... — Dave Thomas <Dave@...>
[#3935] If your company uses Pallets, Skids, Boxes, Lumber, etc. — pallets2@...
[#3956] Tk PhotoImage options — andy@... (Andrew Hunt)
Hi all,
[#3971] Thread and File do not work together — "Michael Neumann" <neumann@...>
following example do not work correctly with my ruby
[#3986] Re: Principle of least effort -- another Ruby virtue. — Andrew Hunt <andy@...>
> Principle of Least Effort.
Hi,
[#4005] Re: Pluggable functions and blocks — Aleksi Niemel<aleksi.niemela@...>
Aleksi makes a question:
[#4008] Ruby installation instructions for Windows — Aleksi Niemel<aleksi.niemela@...>
I had to write these instructions for my friends. I thought it might be nice
[#4043] What are you using Ruby for? — Dave Thomas <Dave@...>
On 15 Jul 2000 22:08:50 -0500,
Hi,
[#4057] Re: What are you using Ruby for? — Aleksi Niemel<aleksi.niemela@...>
Johann:
[#4082] Re: What are you using Ruby for? — Aleksi Niemel<aleksi.niemela@...>
[#4091] 'each' and 'in' — hal9000@...
I just recently realized why the default
[#4107] Re: 'each' and 'in' -- special char problem? — schneik@...
[#4114] Method signature - a question for the group — Dave Thomas <Dave@...>
[#4139] Facilitating Ruby self-propagation with the rig-it autopolymorph application. — Conrad Schneiker <schneik@...>
Hi,
[#4158] Getting Tk to work on Windows — "Michael Neumann" <neumann@...>
Hi....
[#4178] Partly converted English Ruby/Tk widget demo working. — Conrad Schneiker <schneik@...>
Hi,
[#4234] @ variables not updated within method? — Hugh Sasse Staff Elec Eng <hgs@...>
Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> writes:
On 27 Jul 2000, Dave Thomas wrote:
[#4267] Ruby.next, Perl6, Python 3000, Tcl++, etc. -- Any opportunities for common implementation code? — "Conrad Schneiker" <schneiker@...>
Hi,
"Conrad Schneiker" wrote:
[ruby-talk:03905] Re: require, ensure, and Design by Contract
On Sun, 9 Jul 2000 14:36:44 -0700,
Hal E. Fulton <hfulton@austin.rr.com> wrote:
>I'd like to have an implementation that puts as
>little burden on the programmer as possible.
>Therefore I'm shying away from what I'm looking
>at right now: An implementation that requires the
>programmer to define two other methods for each
>method for which he wants to check pre- and post-
>conditions.
Agreed.
>I thought there might be some way to generate
>these on the fly, at the time the "pre" function was
>called, for instance. But there is no way to determine
>the class or object of the method that called you.
This is a problem, yes.
>But I have been thinking of a syntax something like
>this:
>
> pre("positive:x>0 empty:arr.size==0 old.somevar")
> # ...
> post("nonempty:arr.size>0 incr:somevar=old.somevar+1")
I quite dont like the fact that you write the assertions "horizontally".
It is quite hard to read. I would prefer a "pre" statement and then
list all assertions, one per line. This would be more readable.
>The "label:" notation would provide a mnemonic for the
>error message. (Doesn't Eiffel provide this?)
Yes it does.
>The "old.somevar" notation would be a signal to save off the
>value of somevar so that it could be checked at the end.
Basically, I agree. But I do not like "old" has to be mentioned in
"pre". This only would cause stupid ommission errors.
>This is all extremely half-baked, though. Inheritance is the real
>issue: We have to make sure that contracts are heritable.
..and we need something to make the programmer aware of that he is
weakening preconditions/strengthening postconditions in a subclass. In
Eiffel, this is done by enforcing "require else" and "ensure then" in a
subclass for adding assertions.
--
Best regards,
Patrick
--
---------------------------------------------------------------------------
e-mail: pschoenb@solidsoft.iksys.de
URL: http://www.geocities.com/Vienna/5357/
PGP Public Key: Mail to pgp@solidsoft.iksys.de with 'pschoenb' as subject
Fingerprint: 3C FB B0 A7 E2 C2 3B 2D 68 6C 66 7E B7 D5 C2 70
---------------------------------------------------------------------------