> Carl Cerecke wrote:
>> The EBNF rule for ReferencedType is:
>>
>> ReferencedType ::= [ GlobalModuleId "dot" ] TypeReference [
>> ExtendedFieldReference ]
>>
>> What, exactly, is the [ ExtendedFieldReference ] there for? Are not
>> all types defined in the module-definition scope, and hence
>> accessible by at most <globalid>.<typename>?
György Réthy wrote:
> Hi,
>
> Not in all cases. Just two examples:
>
> 1. Module B imports type T1 from module A (non-recursively, which is
> the basic mechanism); Let T1 be a structured type which references T2
> (defined in module A) in its field f1. The name T2 is not seen in
> module B, so moduleid.typename can not be used to refernce it (this
> form is meant for name clash resolution, does not <should not!> help
> if the type name itself is not seen in module B); but the type
> information of T2 is still available via the ExtendedFieldReference
> as T1.f1.
As I understand it, something like this:
module A {
type record T1 {
T2 f1;
}
}
module B {
import from module A {
type T1;
}
function F1() {
var T1.f1 foo := bar;
}
}
My opinion is that, if module B wants to use type T2, then it should
either import T2 directly or import T1 recursively. I don't see the
advantage in being able to specify T1.f1 over T2. I think that T1.f1 is
actually worse, because it adds an unneccesary extra layer of indirection.
Allowing an ExtendedFieldReference essentially adds an extra
"intermediate" layer of type visibility. As well as a type being
invisible, and visible, we can have an indirectly-visible type which is
sort-of invisible but you can use it if you really want to. I don't
think it is a good idea. Better to be explicit about what is visible,
and everything else is invisible.
> 2. ASN.1 allows to embed inner type definitions into an outer type
> definition (like T3 := SEQUENCE { s1 CHOICE { c1 INTEGER, c2 BIT
> STRING }, s2 INTEGER}; The inner type definition does not have its
> own name and accessible ONLY by the ExtendedFieldReference as T3.s1
I don't know ASN.1, so correct me if I'm wrong.
If a variable of the type of s1 was intended to be used, then wouldn't
this have been made a separate type in the ASN.1 file? In other words,
the fact that the type of s1 is not given a name implies that no
variables of that type should be created. Is it really useful to be able
to refer to an anonymous inner type of a named type? Should the
anonymity intended by the ASN.1 author be intentionally subverted?
> So, I would say, these two mechanisms are complementary from the
> point of view of their use, even if merged into the same BNF
> production.
>
> BR, Gyorgy
>
Cheers,
--
Carl Cerecke - Software Designer
Da Vinci Communications Ltd
Christchurch - New Zealand
TEL : +64 3 3838311
FAX : +64 3 3838310
e-mail:
This email address is being protected from spambots. You need JavaScript enabled to view it.
www :
www.davinci-communications.com
