Re: [vhdl-200x] Pass-through package

From: Trond Danielsen <trond.danielsen@gmail.com>
Date: Tue Jul 01 2014 - 22:34:09 PDT
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