taskLiberty Eiffel - Tasks: task #13318, TUPLE argument in feature 'call'...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #13318: TUPLE argument in feature 'call' of class PROCEDURE

Submitter:  Raphael Mack <ramack>
Submitted:  Wed 10 Sep 2014 07:32:14 PM UTC
   
 
Should Start On:  Tue 09 Sep 2014 10:00:00 PM UTC Should be Finished on:  Fri 09 Sep 2016 10:00:00 PM UTC
Category:  SmartEiffel Priority:  5 - Normal
Status:  Done Assigned to:  cadrian
Percent Complete:  100% Open/Closed:  Closed
Fixed Release:  None Planned Release:  None
Effort:  0.00

Sun 14 Sep 2014 06:28:45 AM UTC, comment #1: 

Already done.

Cyril Adrian <cadrian>
Group administrator
Wed 10 Sep 2014 07:32:14 PM UTC, original submission:  

From the good old SmartEiffel Wiki "Wish List":

a_tuple: TUPLE [X, Y, Z]; a_agent: PROCEDURE [TUPLE [X, Y, Z]]

Invalid: a_agent.call (a_tuple) Valid: a_agent.call ([a_tuple.item_1, a_tuple.item_2, a_tuple.item_3])

I don't know the reason for this decision. Probably you carefully though about it because there is a detailed error message as one compiles the first version. (Is type-safety or performance the reason?)

If you allow calls of the first form, one could implement a class SIGNAL that replaces all SIGNAL_X classes. --Interested SmartEiffel user

The main problem is type safety. Here is the rationale (or in PDF). It means that writing a_agent.call(a_tuple) would be only syntactic sugar and a short hand for a_agent.call([a_tuple.item_1, a_tuple.item_2, a_tuple.item_3]).

But you cannot get rid of the SIGNAL_* classes because of the conformance rules: PROCEDURE[TUPLE[A,B]] does not conform to PROCEDURE[TUPLE[A,B,C]], but the opposite (see details p.136 and p.140 in the PDF file). It means that SIGNAL_4, for example, handles any agent that has up to 4 arguments. It can take less, but the given tuple cannot give less (see the `emit' feature in each SIGNAL_* class).

So, in summary, the short-hand could be implemented (maybe it will, some day); but no, it does not free us of the SIGNAL_* classes.

--Cyril 14:52, 30 Nov 2005 (CET)

Sorry, I don't think so. For me, PROCEDURE[TUPLE[A,B]] does conform to PROCEDURE[TUPLE[A,B,C]]. -- Philippe Ribet

What did I miss? Philippe, please fix my argument. Maybe I'm wrong. You know the topic better than me. --Cyril 11:34, 21 Dec 2005 (CET)

Well, TUPLE[A,B,C] conforms to TUPLE[A,B] (no special rule here), so PROCEDURE[TUPLE[A,B]] conforms to PROCEDURE[TUPLE[A,B,C]] (because of the reversal you mentionned). A procedure can discard extra-arguments, but you have to give it enough arguments so it can do its work.--FM 17:26, 17 Jan 2006 (CET)

---

I would like such agent calls: It would be possible to have a type-safe class SIGNAL[E_ -> TUPLE]. The callback would look like this callback: PROCEDURE[E_] (I don't use an array of callbacks here because of readability). This is type-safe for any actual generic. A set_callback (a_callback: like callback) feature would be safe as well... And the important point, the emit feature that is currently not valid:

emit (argument: E_) is
 do
  callback.call(argument)
 end

This kind of agent call is not syntactic sugar. It is impossible to write such a class without it. The number of arguments is the only information one has, and this of course only at run-time. The types of the arguments are not known and thus it is impossible to implement such a class from my point of view.

With such an implementation the following is possible: If a class contains a SIGNAL_2[INTEGER, STRING] it could be replaced by SIGNAL[TUPLE[INTEGER, STRING]].--Andy

Raphael Mack <ramack>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by _92048 (Updated the item)
  • -email is unavailable- added by ramack (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-02-03 _92048 StatusCancelled Done
    2014-09-14 cadrian CategoryNone SmartEiffel
        StatusNone Cancelled
        Percent Complete0% 100%
        Assigned toNone cadrian
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code