[Click] Scoping/naming issues

[Philip Prindeville]

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