1. juli 2014 kl. 22:47 skrev <ryan.w.hinton@L-3com.com> <ryan.w.hinton@L-3com.com>: > Here's a problem I just ran into that will turn into an enhancement request unless somebody on the list can show me a semi-good way to solve it. > > I have a package, call it A. In particular, it defines a type I'll call A_TYPE. Then I needed a '93-compatible version of A, so I wrote another package, call it B. B also (identically) defines A_TYPE and its operations. Now I want to refactor package A to get rid of the duplicate type/code and "pass through" the type definition and functions from package B. When I "use" package B in the package A definition, then all of B's definitions become available -- but are not defined for a user of package A. > > Here are the options I see > > 1. I can redefine the A_TYPE and its operations and call (using type conversions and selected names) the package B operations. This involves lots of duplication, so this is my least favorite option. > > 2. I can define a subtype of A_TYPE in package a *with the same name* so users of package A will see that name -- and it will have the same effective type. I can create aliases to the A_TYPE operations from package B in the package A declaration. This has less duplication of code and types, so it's better than 1. But the signatures in the alias declarations are going to be a mess. And there is significant danger one of my tools will reject it. (I realize that tool support is orthogonal to the language definition.) > > Any better ideas? I can imagine a language construct to do this. Maybe something like the following. > > package A is > alias work.B.all; > ... > end package A; > > "Alias" isn't exactly the right meaning, but it's probably close enough. > > Thoughts? Isn’t this what contexts are for? — Trond Danielsen — -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Jul 1 22:34:32 2014
This archive was generated by hypermail 2.1.8 : Tue Jul 01 2014 - 22:35:02 PDT