From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4ee5611d3fbf05b7 X-Google-Attributes: gid103376,public From: bralick@seas.smu.edu (William Bralick) Subject: Re: Enumeration literal visibility and use type Date: 1998/05/26 Message-ID: <6kensr$fqq$1@hermes.seas.smu.edu>#1/1 X-Deja-AN: 356658943 References: <6kej65$dnh$1@hermes.seas.smu.edu| <6kejt5$75u@gcsin3.geccs.gecm.com> Organization: SMU - School of Engineering & Applied Science Newsgroups: comp.lang.ada Date: 1998-05-26T00:00:00+00:00 List-Id: In article <6kejt5$75u@gcsin3.geccs.gecm.com|, John McCabe package doodah is |> |> type state_value_type is (state0, state1, state2, state_etc); |> |> -- and just to make things interesting, let's create a useful message |> |> type useful_message is record |> state_stuff : state_value_type; |> other_stuff : natural; |> end record; |> |>end doodah; | |There is no "cool_type". There is "state_value_type" and |"useful_message", so you're "use type doodah.cool_type" will never work |for a start. Hmm ... so much for changing horses (examples) in midstream. Yes, I obviously intended "use type doodah.state_value_type" where I wrote "use type doodah.cool_type". Mea culpa. |>For some reason that I have yet to fathom, I had convinced myself |>that "use type" would give immediate visibility of the enumerals in |>doodah.cool_type. I am now convinced that it doesn't (though I am ^^^^^^^^^ state_value_type |>ready to argue that it _should_). | |Despite the obvious error, the "use type" clause is designed to provide |visibility to the OPERATORS of the type, NOT the type itself so the |behaviour you are seeing is correct. Yes ... and I had understood that visibility of the type name was still restricted (one would always need to write doodah.state_value_type), but I was convinced that the enumerals themselves would be visible to avoid (1) the use of the "use clause" or (2) defining a series of named constants. The latter work-around looks disturbingly like the function renames that we were avoiding with the use type clause. So once again, I am merely asking for a reference to some documentation that might describe _why_ OPERATORS only were made visible and in particular why enumerals were left in the (somewhat) clumsy Ada'83 form. Perhaps this was never even considered ... that would be important to know, too. Anybody? Best regards, -- Will Bralick ............_/......._/__/..._/.......__/..._____/ ........._/....._/_/._/.._/......_/._/.._/..._/ ........................._/..._/______/._/...________/._/___/ ........._/._/_/....._/_/...._/....._/_/.._/