Re: [Liberty-eiffel] Problem with agents

[Germán Arias]

Hi

El mié, 23-12-2015 a las 11:18 +0100, Raphael Mack escribió:
> 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 ;-)

Sure, I will work on this.

> 
> > > 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!

I understand your feeling about the Eiffel experience through all the
development process. And definitely this would be the best.

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

Thanks
Germán