[Click] "Graft" ports

[Philip Prindeville]

One other nice property about graft-points is this:

elementclass MyIncrediblyHairyObject {
...
}

miho :: MyIncrediblyHairyObject;
...

miho [0]<->  null :: { input ->  output }<->  [0] miho;
// miho [0]<->  dbg0 :: { IPPrint("Inspection 0", MAXLENGTH=64) }<->  [0] miho;


and by just moving the comment prefix around, I can turn on or off debugging, without having to disturb the body of the elementclass itself.




On 1/20/11 3:59 PM, Philip Prindeville wrote:
> I've been thinking about this some more...
>
> If I have the following:
>
> elementclass Foo {
>
>     stuff1 ->  external-object ->  stuff2;
>
> }
>
> then this can be rewritten as:
>
> elementclass Foo {
>     stuff1 ->  [N] output;
>     input [M] ->  stuff2;
> }
>
> f :: Foo;
>
> f [N] ->  external-object ->  [M] f;
>
> I'd like to propose a notational convenience called "graft" (as in a graft-point).
>
> graft[0] would be short-hand for 1+ the highest used input, and [0] graft would be 1+ the highest used input.
>
> (and so on for [1], [2], etc.)
>
> We'd need a new operator for graft-points.  Maybe:
>
> f [G]<->  [a] external-object [b]<->  [G] f;
>
> it would be a syntactic error to mismatch subscripts for the object being grafted to.
>
> The notation inside the elementclass would be:
>
> elementclass Foo {
>     stuff1 ->  graft [G] ->  stuff2;    // or ... [G] graft ...
> }
>
> Does that make sense?
>
> -Philip
>
>
> On 1/18/11 3:43 PM, Beyers Cronje wrote:
>> 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
>>>
>