Subject: [forces] Inheritance dilema

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 19 Jun 2014 09:37:35 -0400

I have  come across an interesting issue with an LFB we are trying to implement
that inherits from a parent LFB.

Assume LFB class A which has:
 a) datatype struct foo = {...}
 b) component id 1 footab which is an indexed table of struct foos.
 c) an event id 61/1 which is generated anytime footab changes

Assume LFB class B which inherits from LFB class A. It does:
a) augment  struct foo to create a new struct newfoo which adds two
new fields goo and gah
b) It overrides component Id 1(footab) to a new table that uses struct
newfoo as table row.
Lets change this to a new name newfootab.

The interesting part:
class B *does not* want to define any events.
What rules make sense to enforce that?

So far everything we've come across has fallen under simple rules:
Because we changed the name of component ID 1 - we have to redefine
(cutnpaste from parent)
the events. Which is Ok.
If we didnt change the name and kept it as footab, then not redefining
means we are using the same
events the parent had.

cheers,
jamal

PS: I think the same question applies to "what if i didnt need a
parent's components"

---

From: Joel <[email-masked]>
Date: Mon, 23 Jun 2014 19:32:09 -0400

My own reading is that the events from A would still apply.
The ID it applies to still exists.
The fields it applies to still exists.
Any conditions it defines are still well-defined.
So the event is inherited.
In fact, the rules of inheritance in ForCES are such that you can not 
invalidate an event.
And the rule of substitutability (a child should always be useable as a 
parent) seem to require that the event exist and be well-defined.  (This 
is important, for example, if the FE implements B but the CE thinks in 
terms of A.

Note, the FE is always free to say "sorry, I won't accept registration 
for that event."

Yours,
Joel

On 6/19/14, 9:37 AM, Jamal Hadi Salim wrote:
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 24 Jun 2014 11:53:52 -0400

> In fact, the rules of inheritance in ForCES are such that you can not

I did a little a little reading on general OO inheritance (and played
around with python
for a few hours) and it seems what we have with ForCES in "implicit inheritance
and explicit override" is a common theme.

> parent) seem to require that the event exist and be well-defined.  (This is
> important, for example, if the FE implements B but the CE thinks in terms of
> A.

I didnt get your last sentence (why would the CE think of LFB B in terms of A?);
regardless you are making sense and  i dont think we are far off from what the
rest of the OO world does.

This is more philosophical:
It seems such a waste - I have to inherit all attributes my mother gave me
whether i use them or not (and i have to have DNA code that handles them).
I can add new attributes for my children to inherit and pass on all the things
i inherited, but my children can not get rid of them ;->
At some point this becomes high maintanance. Humans not so bad, there
are about 10-15 useless organs we have, but for LFBs - could we do better? ;->
It is solvable with a rebirth of a new LFB to purge old attributes but
would it not
be useful if we could add an explicit "null override" to purge an attribute?

> Note, the FE is always free to say "sorry, I won't accept registration for
> that event."
>

Yes, this should be enough.
Could we introduce an event property for this?
The FE sets it (and may reject the subscriptions) but if the CE reads
it and knows
then it wont bother subscribing.

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Tue, 24 Jun 2014 23:31:26 -0400

Yes, we could add an event property for "I don't actually support this." 
  I would prefer not to bother, as I think it will be relatively rare 
that the CE will actually want to subscribe to the event, but the FE 
won't support it.  So having to go read the status may be more work than 
just subscribing and getting the error.

Yours,
Joel

> On Mon, Jun 23, 2014 at 7:32 PM, Joel <[email-masked]> wrote:
...

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 25 Jun 2014 07:18:44 -0400

On Tue, Jun 24, 2014 at 11:31 PM, Joel <[email-masked]> wrote:
> Yes, we could add an event property for "I don't actually support this."  I
> would prefer not to bother, as I think it will be relatively rare that the
> CE will actually want to subscribe to the event, but the FE won't support
> it.  So having to go read the status may be more work than just subscribing
> and getting the error.
>

At this point with current experience - I agree.
It was good to discuss it. Thanks Joel.

cheers,
jamal