Re: [Liberty-eiffel] Problem with agents

[Raphael Mack]

Hello,

Am Dienstag, den 22.12.2015, 18:19 -0600 schrieb Germán Arias:
> El mar, 22-12-2015 a las 23:23 +0100, Raphael Mack escribió:
> > What is the use of this function / Why not rename widget_pointer to
> > widget and remove this one here?
> 
> Are you saying I don't need queries to the attributes? I thought the
> principle of Hidden information in Eiffel don't allow this? This is if I
> have an attribute "bar" at class "foo", then "object_foo.bar" is enough?

Yes, this is what I say. Actually in Eiffel the idea is, that a client
doens't need to know whether it accesses an attribute or a
(parameterless) function. Generally it is bad design to allow access to
attributes from outside the class, but the problem here is only about
writing and in Eiffel this is generally not allowed. - Ok, with the
assign keyword this is a bit relaxed, as for the client it looks like
the attribute would be writable, even though it is just syntactic sugar
to call a different procedure...

Nevertheless, in Eiffel it is recommended to not have query-features for
attributes, while for write access it is necessary.

> > Have you chosen the client list really wise or is this just a simplified
> > example? - The same for contracts and handling an uninitialized (= Void)
> > cb_action in execute_action?
> 
> Right, but for the moment I want see this working. And (see below) if no
> agent is associated to a widget, I don't expect calls to
> "execute_action"

So it would be good, to formalize this expectation in a precondition and
maybe set the export rules for execute_action to a small set of classes,
which you have under control, while you still remember this
expectation ;-)

> > Again: exporting to ANY doesn't look very nice e. g.
> > IUP.iup_set_callback should probably be exported to the widgets, only
> > and in client code the callback should better be set on the widget (e.
> > g. IUP_BUTTON.set_action(cb: ROUTINE[TUPLE]))
> 
> Maybe, but I would like keep things close to IUP, so the end users will
> be able to use (almost) the same tutorials, with some minor changes.

I understand. There are always pros and cons for nice designed object
oriented wrappers for such libraries... As you might have guessed, I
personally prefer the wrapper to also wrap between the two worlds and
have the Eiffel-side Eiffel-like, especially, as I - as a potential user
of the wrapper - don't care about the details and the implementation of
the underlaying library, I like using a high level abstracted thing,
which smoothly fits the methodology of the language I use for the
complete application. But: It's up to you!

Cheers,
Rapha

BTW: Merry Christmas, for all of you, caring about this event!