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

[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 ]