Re: [Liberty-eiffel] Inline agent

[Raphael Mack]

Assume a procedure a parameter of static type IUP_WIDGET:
do_something(widget: IUP_WIDGET)
   do
      use(widget.title)
   end

can never know whether the call is ok or not, because depending on the
actual type of the passed object the feature title might or might NOT be
available.

Arguments that the user know what they do are not really good. With
those we can all program in assembly (which IS fun of course) but we
always need abstraction to be able to grasp a complex system, and this
is where higher languages come into the game.

To not only talk about bad practice, but also make some suggestion:
Have you ever though of splitting IUP_WIDGET into two classes?
IUP_WIDGET and IUP_WIDGET_WRAPPER or something alike? With IUP_WIDGET
being the conforming superclass of all widgets and coming only with
those features, that are available and meaningful to ALL widgets (which
makes the code above valid) and the wrapper to bring the code for the
functionality which is needed in some (but not all) as non-conforming
parent? (aka insert this class instead of inherit from it)?

If necessary you can even have multiple conforming IUP_WIDGET-like
abstractions: IUP_TITLED_WIDGET (bringing the title feature),
IUP_RESIZEABLE_WIDGET (for max_size, min_size, etc.)...

Cheers,
Rapha

Am Montag, den 22.02.2016, 01:12 -0600 schrieb Germán Arias:
> Hi
> 
> El dom, 21-02-2016 a las 11:05 +0100, Raphael Mack escribió:
> > Mh. I am not sur for this one. Do you have concrete example in the IUP
> > wrapper you ca Show us? Maybe we ca suggest some change to solve the
> > root cause of the warnings...
> > 
> > 
> > Rapha
> > 
> 
> IUP widgets have some commons attributes, like maxsize, minsize, title,
> etc. "Common" in the sense that are used by many widgets, but an
> specific widget not necessarily responds to all of them. 
> 
> All these attributes are implemented at IUP_WIDGET and almost all the
> widgets inherits from this class. And I change the export status
> according to each widget. 
> 
> At IUP level there isn't problem if you request for an attribute which
> is not implemented in a widget. But I don't want have features for
> attributes that don't have sense for an specific widget. So I change the
> export status for these.
> 
> I don't see a problem with this. If a user have, for example, an object
> of clase IUP_BUTTON, I guess he has read the documentation and he knows
> what he's doing.
> 
> Germán
> 
>