[Click] Scoping/naming issues

[Ian Rose]

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):
--------------------------------------
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