[Click] Scoping/naming issues

Beyers Cronje bcronje at gmail.com
Tue Jan 18 18:43:55 EST 2011


The config you posted below Ian explicitly states "This would be legal:" at
the top.  I think Ian is referring to the second config that will cause
issues:

"
I think this should complain that fd[0] is being used twice (port
connection error), although it may take a minute to see why that's the
case (and would be much trickier to see in a more complex config):
--------------------------------------
fd::FromDevice(...);

elementclass Bar {
    fd[0] -> Print() -> [0]output;
}

a::Bar() -> Discard();
b::Bar() -> Discard();
--------------------------------------
"


On Wed, Jan 19, 2011 at 12:32 AM, Philip Prindeville <
philipp_subx at redfish-solutions.com> wrote:

> On 1/18/11 7:34 AM, Ian Rose wrote:
> > If I am thinking this through correctly, IMHO it wouldn't be a good idea
> > to allow elementclasses to do this.  Reason being that in some cases you
> > could create port connection errors merely through declaring multiple
> > elements of your new elementclass type.  This would be an unexpected and
> > confusing error since its impossible to do currently.  AFAIK currently
> > there are no errors that can occur merely by *declaring* too many
> > elements of some type.  So this would introduce a whole new category of
> > error.  Some examples:
> >
> > This would be legal:
> > --------------------------------------
> > fd::FromDevice(...);
> >
> > elementclass Bar {
> >       fd[0] ->  Print() ->  [0]output;
> > }
> >
> > a::Bar() ->  Discard();
> > --------------------------------------
> >
> > I think this should complain that fd[0] is being used twice (port
> > connection error), although it may take a minute to see why that's the
> > case (and would be much trickier to see in a more complex config):
>
> Sorry, not seeing why the above case represents using the port twice...
>
>
> > --------------------------------------
> > fd::FromDevice(...);
> >
> > elementclass Bar {
> >       fd[0] ->  Print() ->  [0]output;
> > }
> >
> > a::Bar() ->  Discard();
> > b::Bar() ->  Discard();
> > --------------------------------------
> >
> > In order to cause this same error currently (without the proposed
> > elementclass enhancement) you'd have to do this, which I think makes the
> > error more obvious:
> > --------------------------------------
> > fd::FromDevice(...);
> >
> > elementclass Bar {
> >       input[0] ->  Print() ->  [0]output;
> > }
> >
> > fd[0] ->  a::Bar() ->  Discard();
> > fd[0] ->  b::Bar() ->  Discard();
> > --------------------------------------
> >
> >
> > Just my $0.02.
> >
> > - Ian
> >
> >
> > On 01/17/2011 07:55 PM, Philip Prindeville wrote:
> >> Yeah, it especially makes sense to have arpfoo be global if it needs to
> be accessible from two different elementclass's, one that deals with the IP
> flow (input [0] and output [0]) and another one that deals strictly with the
> ARP request/reply flow (input [1] and output [1]).
> >>
> >> Someone else will have to come up with the patches...  I've not yet
> dabbled in the code itself.
> >>
> >>
> >> On 1/17/11 4:35 PM, Eddie Kohler wrote:
> >>> Hi Philip,
> >>>
> >>> I can see why you thought compound elements would work that way, but
> they don't.  They are very strictly encapsulated: all connections to other
> elements must take place through explicit inputs and outputs.
> >>>
> >>> I admit it would make sense to do it the way you've imagined.  Patches
> welcome...
> >>>
> >>> Eddie
> >>>
> >>>
> >>> On 1/15/11 2:53 PM, Philip Prindeville wrote:
> >>>> I've got a configuration where I do:
> >>>>
> >>>> ...
> >>>> arpfoo :: ARPQuerier(...);
> >>>>
> >>>> elementclass Bar {
> >>>> ...
> >>>>         class :: classifier(...);
> >>>> ...
> >>>>          class [2] ->     [1] arpfoo;
> >>>> ...
> >>>> }
> >>>>
> >>>>
> >>>> but it complains that "unknown element class 'arpfoo'" in a few
> places, and that input 1 isn't used...
> >>>>
> >>>> So I'm confused.  Everything is scoped globally... even stuff defined
> within an elementclass gets scoped globally.
> >>>>
> >>>> Why then can't I access a global variable from within an
> elementclass's scope?
> >>>>
> >>>> What am I missing?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> -Philip
> >>
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>


More information about the click mailing list