Full class checking violates principles?

3 messages Options
Embed this post
Permalink
Jimmy Johnson

Full class checking violates principles?

Reply Threaded More More options
Print post
Permalink
I found an answer to my previous question at docs.eiffel.com "Converting existing software to void-safety".  The example shows a problem just like mine:
1.  an ancestor has an entity `val' declared "attached like Current".
2.  there is a call "create val.some_creation_feature".

This works fine for this class but doesn't this *force* descendents to add `some_creation_feature' to its list of creation features whether it wants to or not?  This *has* to violate some principle, perhaps "information hiding" since I can no longer hide `some_creation_feature'.

Also, why did that pattern work in the past but now is being rejected?

Jimmy J. Johnson

Paul Bates [ES]

Re: Full class checking violates principles?

Reply Threaded More More options
Print post
Permalink
Not at all. In fact you code could have had a serious bug because the "hidden" creation routine gets forgotten and some attributes may not be initialized correctly.

The solution is to declare the creation routine exported to the containing class only.

...

create
  make

create {SOME_CLASS}
  some_creation_feature

...

This will also satisfy compiler when using Void-Safe when checking all attached attributes have been correctly set.

Paul.

--- In [hidden email], "Jimmy Johnson" <boxer41a@...> wrote:

>
> I found an answer to my previous question at docs.eiffel.com "Converting existing software to void-safety".  The example shows a problem just like mine:
> 1.  an ancestor has an entity `val' declared "attached like Current".
> 2.  there is a call "create val.some_creation_feature".
>
> This works fine for this class but doesn't this *force* descendents to add `some_creation_feature' to its list of creation features whether it wants to or not?  This *has* to violate some principle, perhaps "information hiding" since I can no longer hide `some_creation_feature'.
>
> Also, why did that pattern work in the past but now is being rejected?
>
> Jimmy J. Johnson
>


Jimmy Johnson

Re: Full class checking violates principles?

Reply Threaded More More options
Print post
Permalink
Thanks, didn't know I could do that.



--- In [hidden email], "pa_bates80" <paul.bates@...> wrote:

>
> Not at all. In fact you code could have had a serious bug because the "hidden" creation routine gets forgotten and some attributes may not be initialized correctly.
>
> The solution is to declare the creation routine exported to the containing class only.
>
> ...
>
> create
>   make
>
> create {SOME_CLASS}
>   some_creation_feature
>
> ...
>
> This will also satisfy compiler when using Void-Safe when checking all attached attributes have been correctly set.
>
> Paul.
>
> --- In [hidden email], "Jimmy Johnson" <boxer41a@> wrote:
> >
> > I found an answer to my previous question at docs.eiffel.com "Converting existing software to void-safety".  The example shows a problem just like mine:
> > 1.  an ancestor has an entity `val' declared "attached like Current".
> > 2.  there is a call "create val.some_creation_feature".
> >
> > This works fine for this class but doesn't this *force* descendents to add `some_creation_feature' to its list of creation features whether it wants to or not?  This *has* to violate some principle, perhaps "information hiding" since I can no longer hide `some_creation_feature'.
> >
> > Also, why did that pattern work in the past but now is being rejected?
> >
> > Jimmy J. Johnson
> >
>