Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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 > < > > , 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" [carl--rebol--com]]
** Script Error: Expected one of: integer! - not: url!. ** Where: x: max x y
>> max-in-block-sturdy [1 #"a" [carl--rebol--com]]
** Script Error: Expected one of: integer! - not: url!. ** Where: x: max x y
>> max-in-block-sturdier [1 #"a" [carl--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}