[eiffel-users] Export status of closed_operands in class ROUTINE

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[eiffel-users] Export status of closed_operands in class ROUTINE

Finnian Reilly
I would like to know what the rational is for denying developers access to `closed_operands' in class ROUTINE. There are certain circumstance where being able to access `closed_operands'  is very useful such as in the routine `new_svg_pixmap' from class EL_APPLICATION_PIXMAP in Eiffel-Loop. At the moment I am having to resort to some very inelegant means to get access by using my own descendant of PROCEDURE.

If there is some good reason for discouraging access then a good compromise would be to export the attribute to an access class `ROUTINE_HANDLER', similar to the class STRING_HANDLER. The understanding is you are now accessing this attribute at your own risk.

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [eiffel-users] Export status of closed_operands in class ROUTINE

'Alexander Kogtenkov' via Eiffel Users
In general, `closed_operands` is an implementation detail that may (and most probably will) change in the future. In particular, internal implementation of the routine classes may change completely, and I'm not sure it would be possible to inherit them. I.e. they might become similar to the TUPLE class. Also, closed operands cannot be retrieved safely. I.e. their value can be anything unless you can make sure that a particular feature is used for agent creation. And if the implementation changes, there could be no closed operands anymore. There are already several issues caused by exposure of agent and tuple internals. The intermediate goal is to remove all uses of these internals. So, it's better to find some other way to achieve what you are looking for. As soon as the code does not depend on these implementation details, it will be more maintainable in long term.

Best regards,
Alexander Kogtenkov


Finnian Reilly <[hidden email]>:

I would like to know what the rational is for denying developers access to `closed_operands' in class ROUTINE. There are certain circumstance where being able to access `closed_operands'  is very useful such as in the routine `new_svg_pixmap' from class EL_APPLICATION_PIXMAP in Eiffel-Loop. At the moment I am having to resort to some very inelegant means to get access by using my own descendant of PROCEDURE.

If there is some good reason for discouraging access then a good compromise would be to export the attribute to an access class `ROUTINE_HANDLER', similar to the class STRING_HANDLER. The understanding is you are now accessing this attribute at your own risk.

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.