[REBOL] Re: Pre-REP on NONE! and SERIES! polymorphism
From: joel:neely:fedex at: 12-Jun-2002 8:23
Hi, Ladislav,
Ladislav Mecir wrote:
> Hi all,
>
> I do not hate polymorphism! That said, I must say, that all
> proposed solutions look like "an exception to an exception".
>
Having been accused before of unwillingness to "let REBOL be
REBOL", I'm simply thinking out loud about a way to live with
the current uses of NONE, rather than asking for a change in
that area. (See below.)
> My POV is, that current behaviour is complicated enough and
> I would prefer to not complicate things any more. If I had
> to choose the simplest variation, I would vote for 3c below,
> but the simplest way would be to use empty block where
> appropriate instead of replacing it by NONE.
>
I agree in principle, but in practice I don't see that as
feasible. REBOL currently yields NONE in a variety of cases
to indicate "nothing here", but knowing what was expected by
the author might have to wait until the telepathy module is
implemented!
I'm simply suggesting that taking an action for every piece of
content in "nothing here" and searching for a value in "nothing
here" could be allowed (respectively) to do nothing gracefully
or return "nothing here" gracefully. This has the advantage
that it breaks no existing code at all, and still allows those
who prefer explicit pre-tests to write them.
The goal of this idea-under-discussion is to deal with cases
such as these:
- PARSE-XML provides a three-part element/attributes/content
block for every XML element encountered. However, the
attributes or content portions are NONE, rather than an
empty block, when attributes or content are not present.
Since it is common in XML processing to iterate over the
content of an element, or to search an attribute list for
a given name, it would be nice to have those gracefully
do nothing when handed NONE.
- PARSE-XML's behavior in that case is related to the fact
that PARSE provides NONE instead of empty strings in some
cases. Again, since searching within an empty string for
a substring yields NONE with the desired substring is not
present, it would be convenient to have that null behavior
when the first argument is e.g. a NONE from PARSE rather
than an empty string.
- One can save memory by initializing as-yet-unknown attributes
of an object to NONE, especially when some of them are never
needed for a particular instance. For example, I believe that:
flight-proto: make object! [
passenger-tickets: none
shipment-waybills: none
]
flight101: make flight-proto [
passenger-tickets: [ ... some document IDs ... ]
]
flight407: make flight-proto [
shipment-waybills: [ ... some document IDs ... ]
]
;; and so on for a large number of similar objects
conveyed?: func [flightobj [object!] docID [string!]] [
any [
find flightobj/passenger-tickets docID
find flightobj/shipment-waybills docID
]
]
could save significant memory (depending on population, of
course!) compared with the use of a prototype that initialized
all attributes to empty blocks.
- Depending on the meaning of the data, testing for presence in
a complex data structure could IMHO be clearer with this
behavior in place. As a dinky example, consider a look-up
structure (block-of-block-of-block) containing country,
province/state, city, and address data for the offices of a
fictitious company:
our-offices: [
"US" [
"NY" [
"New York" "101 East 52nd Street"
"Albany" "2541 Washington Blvd"
...
]
"GA" [
"Atlanta" "525 E. Peachtree SW"
...
]
]
"CA" [
"ON" [
...
]
...
]
"CZ" [
...
]
...
]
(my geographic ineptitude and desire to save your time and mine
cause the example to be severely incomplete ;-)
With the behavior under discussion, I can retrieve the address
of an office in a specific city (or the NONE that signals that
there's no such office) with the expression
find find find our-offices country st-province city
which seems much simpler and direct than any expression I can
think of. Gabriele's elegant suggestion with ANY allows
find any [
find any [
find our-offices country
[]
] st-province
[]
] city
(assuming that OUR-OFFICES has been initialized! ;-) which still
takes more work to parse with my poor eyeballs.
While not suggesting that this is the highest priority for RT to
address, I really *do* think that it returns a small measure of
simplicity to existing complexities surrounding NONE, rather than
adding to them, and (given the compatibility with existing code)
has no impact on those who desire not to use the new behavior.
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
