Subject: Re: Washington Issue 15 - Scope of Names

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Nov 1999 17:52:28 -0500

The problem with this analysis is that packages are not "private
extensions".
They are the major way you adapt the protocol to a wide range of gateways.
 
Having said that, I actually am in favor, personally, of Option 1.
 
Brian
 
 -----Original Message-----
From: Jon Steer [mailto:[email-masked]]
Sent: Monday, November 15, 1999 5:44 PM
To: Brian Rosen; [email-masked]
Subject: RE: Washington Issue 15 - Scope of Names

At 05:30 PM 11/15/99 -0500, Brian Rosen wrote:

Okay, so I define a signal called "Major" in Version 1 of
a package called foo.  Major is not a Megaco token.

In version 2 of Megaco, we define Major as a parameter in
ServiceChange.  Now foo/Major is illegal.

Sure, one of the problems with defining a private extensions 
or packages.

For example, compiler company A names it's keyword foobar
and then the ANSI language committee defines a keyword foobar
but with different semantics. compiler company A and all of
their users are out of luck. One of the reasons you try not
use private extensions.

Note that I ALWAYS can correctly parse foo/Major: the 
package name always precedes an item name.  Why can't I have
foo/TimeOut?  

Well, in order to have a solution like that, you imply
one of two things. 
1. The lexer is context sensitive and knows that the
   package names precede and therefore can assign
   the correct token type during the lexer pass.

 2. In a non-context sensitive lexer, what
 the lexer sees is "name" "slash" "Major" and
 it's up to the parser to now backtrack when it
 sees Major to allow it to be a "name".

 Making the lexer complicated by including context sensitive
 requirements isn't much better than requiring the parser
 to backtrack.

There is no tie between the version of a package and the version
of the protocol

this may be a problem in itself.

Of course, if I have a package called "Major", I will be in
trouble if I define Major in version 2 of the protocol, but
at least Package names are registered, so we will know about
possible problems when we get to version 2.

Brian

> -----Original Message-----
> From: Jon Steer [ mailto:[email-masked] <mailto:[email-masked]>
]
> Sent: Monday, November 15, 1999 5:15 PM
> To: [email-masked]
> Subject: Re: Washington Issue 15 - Scope of Names
> 
> 
> At 04:02 PM 11/15/99 -0500, Brian Rosen wrote:
> 
> I don't understand the rationale for this solution. It's 
> flying in the face
> of 40 years of language compilation experience.
> 
> In no compiled language that I know of, are keywords
> allowed as identifiers.
> 
> Before this is accepted, someone should explain why
> having to support token backtracking in a parser is
> cheaper than having to be minimally careful about naming
> privately defined packages,events etc..
> 
> Since MEGACO is supporting versioning, I don't understand
> why "Problem with Solution 1" is a problem at all. Isn't
> that one of the principal reasons for having versioning?
> 
> Or perhaps, there should be a public/private versioning
> system in place so that privately defined extensions can
> also be versioned.
> 
> jon
> 
> 
> >A number of issues were raised in the Washington meeting that
> >were "send to the list".  This is one of these issues, with the
> >problem and my suggested fix.
> >
> >Problem:
> >What is the scope of names?  Can package item (property, signal,
> >event, statistic) overlap Megaco protocol tokens and/or
> >other package items?
> >
> >Proposed Solution 1:
> >Overlap of names in property, signal, event, statistic is
> >allowed.  Overlap of package item with protocol tokens is
> >prohibited
> >
> >Problem with Solution 1:
> >Extensions to protocol may make a pre-existing package definition
> >invalid
> >
> >Proposal Number 2:
> >Overlap of names in property, signal, event, statistic is
> >allowed.  Overlap of package item with protocol tokens is
> >allowed.
> >
> >Brian
>

---

From: Jon Steer <[email-masked]>
Date: Mon, 15 Nov 1999 18:08:02 -0500

At 05:52 PM 11/15/99 -0500, Brian Rosen wrote:
>The problem with this analysis is that packages are not "private extensions".

I guess I view packages 2 ways.

First, IANA registered packages and secondly, manufacturer
X defined packages.

There is (an admittedly loose) correlation between
the version of the protocol and the IANA registered
packages that were known at the time of the protocol
version. Hence, those packages are potentially
"public". It doesn't take too much care to make
sure we are using unique tokens. Heck, this isn't
Fortran :-).. And after all it's not like all of
the strings used for the tokens make perfect semantic sense.

And as far as manufacturer X defined packages,
caveat emptor.