[REBOL] Transpose Re:(3)
From: joel:neely:fedex at: 6-Oct-2000 11:13
Hi, Andrew,
[news--ted--husted--com] wrote:
> [Al--Bri--xtra--co--nz] wrote:
>
> "fragile" - "arguments not vetted, you can crash this if
> you don't play well with others"
> "robust" - "good faith argument checking done, but there
> may be some gotchas left"
> "ironclad" - "we've collectively banged on this one REALLY
> hard, and are confident that errors will be
> pre-empted"
>
> How about applying the SourceForge nomenclature for applications:
>
> 1: Planning
> 2: Pre-Alpha
> 3: Alpha
> 4: Beta ("fragile")
> 5: Production-Stable ("robust")
> 6: Mature ("ironclad")
>
I like 'em (especially since this puts tradition on our side...), with
one minor reservation. There's an implication among the choices of
beta
, "production-stable", and "mature" that has to do with an item's
progression toward completeness.
There is, to my mind, a slightly different implication to describing
a function as "fragile" vs. "robust" than as "beta" vs. "production-stable"
in that I may want to use the robust version if I'm handling external data
(input from console, data file, etc.) but may be willing to use the fragile
version (for the speed gain of less checking) if I'm at a point in the code
where I'm working with data that has already passed some level of validity
checking -- or that I've constructed earlier in a way that ensures its
validity.
> > So... should we prefer a style for common/standard library
> functions, or at least document which position the author (and
> maintainers) took?
>
> How about starting with Carl's style guide
> <http://www.rebol.com/users/scrstyle.html >
> , and extending from there?
>
I'm sorry... I guess I didn't express that very well.
I think Carl's source coding style guide is a great place to start, for
all the issues it addresses. I was really thinking more of design style
questions, such as the choice between these hypothetical offerings:
max-in-block-fragile: func [b /local x] [
x: first b
foreach y next b [x: max x y]
x
]
max-in-block-sturdy: func [[catch] b [block!] /local x] [
x: b/1
foreach y next b [x: max x y]
x
]
max-in-block-sturdier: func [[catch] b [block!] /local safemax x] [
safemax: func [[catch] a1 a2] [
either any [(type? a1) = (type? a2) all [number? a1 number? a2]] [
max a1 a2
][
max to-string a1 to-string a2
]
]
x: b/1
foreach y next b [x: safemax x y]
x
]
...where we get...
>> max-in-block-fragile []
** Script Error: Out of range or past end.
** Where: x: first b
foreach y
>> max-in-block-sturdy []
== none
>> max-in-block-sturdier []
== none
>> max-in-block-fragile [1 #"a" http://www.rebol.com [carl--rebol--com]]
** Script Error: Expected one of: integer! - not: url!.
** Where: x: max x y
>> max-in-block-sturdy [1 #"a" http://www.rebol.com [carl--rebol--com]]
** Script Error: Expected one of: integer! - not: url!.
** Where: x: max x y
>> max-in-block-sturdier [1 #"a" http://www.rebol.com [carl--rebol--com]]
== "http://www.rebol.com"
If I built a block (e.g. of numbers) myself, and I already know that it is
non-empty, then MAX-IN-BLOCK-FRAGILE may be just fine, but maybe not in
the general case...
...and do we ever need the level of protection afforded (at a cost) by
MAX-IN-BLOCK-STURDIER ?
-jn-
--
; Joel Neely [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677
REBOL [] print to-string debase decompress #{
789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC
B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}
