[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Liberty-eiffel] Problem with agents
From: |
Raphael Mack |
Subject: |
Re: [Liberty-eiffel] Problem with agents |
Date: |
Wed, 23 Dec 2015 11:18:27 +0100 |
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!
- Re: [Liberty-eiffel] Problem with agents, (continued)
Re: [Liberty-eiffel] Problem with agents, Raphael Mack, 2015/12/22
Re: [Liberty-eiffel] Problem with agents, Raphael Mack, 2015/12/22