Loading ...
Sorry, an error occurred while loading the content.

RE: [eiffel_software] Re: CLASS[reference G]

Expand Messages
  • rfo@amalasoft.com
    I ve found that using what it does gets me in trouble and try instead to use what it is . It s a fine line for sure, but it has helped in the past. It
    Message 1 of 1 , Dec 1, 2008
    • 0 Attachment
      I've found that using 'what it does' gets me in trouble and try instead
      to use 'what it is'. It's a fine line for sure, but it has helped in
      the past.
      It sounds like a HANDLE to me.
      If it is indeed limited (i.e. 'what it does') to comparisons, then it
      could be a comparator I suppose (but then we're back to doing and not
      being).
      Just my .02.

      R
      ==================================================
      Roger F. Osmond
      ----------------------------------------
      Amalasoft Corporation
      273 Harwood Avenue
      Littleton, MA 01460

      > -------- Original Message --------
      > Subject: Re: [eiffel_software] Re: CLASS[reference G]
      > From: Helmut Brandl <helmut.brandl@...>
      > Date: Sun, November 30, 2008 11:23 pm
      > To: eiffel_software@yahoogroups.com
      > Hi Simon,
      > I agree that the name of CELL_OF does not convey the intention very
      > well. A class name like REFERENCE documents better your intention.
      > But may be we can find a better name. The basic idea behind
      > CELL_OF/REFERENCE[G] is that is stores an item of type G and it does
      > comparison by using the "=" operator and not the "~" operator. The fact
      > whether the item is a reference type is not the important one, the use
      > of the "=" operator is the key.
      > Unfortunately I have not yet been able to come up with a name that shows
      > that intention. IDENTITY_TESTER or IDENTITY_CELL is the best I can come
      > up. But I don't like it.
      > Regards
      > Helmut
      > The Eiffel Compiler/Interpreter: http://tecomp.sourceforge.net
      > http://www.sourceforge.net/projects/tecomp
      > cipher1024 wrote:
      > > Hi Helmut,
      > >
      > > The behavior of our REFERENCE class is indeed the same as that of your CELL_OF class:
      > > Instantiating it with an expanded type does object comparison instead of reference
      > > comparison. The problem is that a programmer should be entitled to expect reference
      > > comparison when instantiating a collection with REFERENCE [SOMETHING] as an actual
      > > parameter and it is not the case with expanded actuals (of REFENCE). Therefore, it may be
      > > an important nuisance in trying to learn/teach the usage of the library.
      > >
      > > In short, we would want that the information carried by ML_SET [REFERENCE [SOMETHING]]
      > > to be simple and direct. Looking at that type, we should be able to say without any doubt
      > > that we are talking about a set of references.
      > >
      > > Best regards,
      > >
      > > Simon
      > >
      > > --- In eiffel_software@yahoogroups.com, Helmut Brandl <helmut.brandl@...> wrote:
      > >
      > >> Hello Jonathan,
      > >>
      > >> I understand your requirements for modelling library. I will prepare a
      > >> similar library with tecomp in the near future (maybe we can join our
      > >> efforts). Modelling libraries are very important to specify contracts
      > >> completely. I agree, that they are indispensable for proofing SW.
      > >>
      > >> However I don't see the necessity of having a constraint of formal
      > >> generics which allows substitution only with reference or expanded types.
      > >>
      > >> If you use instead of the mentioned class REFERENCE[reference G] ... the
      > >> following class
      > >>
      > >> expanded class
      > >> CELL_OF[G]
      > >> inherit
      > >> ANY redefine is_equal end
      > >> create
      > >> put
      > >> feature
      > >> item: G
      > >> put(e:G) do item := e end
      > >>
      > >> is_equal(o: like Current): BOOLEAN
      > >> do
      > >> Result := item = o.item
      > >> end
      > >> end
      > >>
      > >> then your ML_SET[CELL_OF[PERSON]] will do the required reference
      > >> comparison and ML_SET[CELL_OF[INTEGER]] will continue to do object
      > >> comparison. There is no harm in using CELL_OF[INTEGER].
      > >>
      > >> I hope I didn't miss anything important.
      > >>
      > >> Regards
      > >> Helmut
      > >>
      > >> The Eiffel Compiler/Interpreter: http://tecomp.sourceforge.net
      > >> http://www.sourceforge.net/projects/tecomp
      > >>
      > >>
      > >>
      > >>
      > >> Jonathan S. Ostroff wrote:
      > >>
      > >>> Helmut:
      > >>>
      > >>> I am writing a class ML_SET[G] that encapsulates mathematical sets as part
      > >>> of a Mathematical Modelling Library (ML or MML) for use in contracts.
      > >>>
      > >>> The class represents mathematical sets so must be immutable (i.e. there are
      > >>> no commands that change the state of a set object, only queries such as
      > >>> "union" or "extended" that return new sets with the required set-theoretic
      > >>> property).
      > >>>
      > >>> How do we compare two sets? Usually via object equality (a call to
      > >>> {G}.is_equal, for example, at the level of elements of the set). What if we
      > >>> want to support reference equality (for non expanded types obviously). One
      > >>> way, is to define a class REFERENCE[reference G] that contains a reference
      > >>> to a G object (and {REFERENCE}.is_equal does a reference comparison).
      > >>>
      > >>> For example,
      > >>>
      > >>> contacts: ML_SET[PERSON]
      > >>>
      > >>> can be used to represent a set of contacts, where two person objects are
      > >>> equal if they have the same name, id, etc (object equality). This is useful
      > >>> in contracts because we can now write a postcondition such as
      > >>>
      > >>> add (p: PERSON)
      > >>> -- add person `p' to `contacts'
      > >>> ensure contacts ~ old contacts |+ p
      > >>>
      > >>> for a feature that adds person 'p' to contacts where "|+" is an alias for
      > >>> the {ML_SET}.extended operation.
      > >>>
      > >>> If I want to compare contacts in the set by reference then I would write
      > >>>
      > >>> contacts: ML_SET[REFERENCE[PERSON]]
      > >>>
      > >>> What I would like the compiler to catch is the following error:
      > >>>
      > >>> numbers: ML_SET[REFERENCE[INTEGER]]
      > >>>
      > >>> This would be a misuse of the REFERENCE notation because INTEGER is expanded
      > >>> and there is no reference comparison of integers.
      > >>>
      > >>> We hope that libraries such as ML will play an important part (in future) in
      > >>> complete specifications of Eiffel code at a level close to mathematical
      > >>> specifications found in languages such as Z or B. In the past, we have
      > >>> experimented with tying ML specifications to theorem provers so that we can
      > >>> verify at compile time that the code implementation satisfies the
      > >>> mathematical specification.
      > >>>
      > >>> Thanks for your help.
      > >>>
      > >>> JSO
      > >>>
      > >>>
      > >>>
      > >>> -----Original Message-----
      > >>> From: eiffel_software@yahoogroups.com
      > >>> [mailto:eiffel_software@yahoogroups.com] On Behalf Of Helmut Brandl
      > >>> Sent: Sunday, November 30, 2008 6:15 PM
      > >>> To: eiffel_software@yahoogroups.com
      > >>> Subject: Re: [eiffel_software] CLASS[reference G]
      > >>>
      > >>> Jonathan S. Ostroff wrote:
      > >>>
      > >>>
      > >>>> Thanks, Peter, for this informative answer. I wonder what the ECMA
      > >>>>
      > >>>>
      > >>> solution
      > >>>
      > >>>
      > >>>> was?
      > >>>>
      > >>>> Instead of the CLASS[reference G] mechanism, what construct can we use
      > >>>> instead, to ensure that that we get a compile time error if an expanded
      > >>>> class is substituted for the parameter G?
      > >>>>
      > >>>>
      > >>>>
      > >>>>
      > >>> To the best of my knowledge this type of constraint is not possible in
      > >>> any of the the up to now documented language versions of Eiffel. The
      > >>> only possibility I know is to write class C[G->CONSTRAINT] requiring any
      > >>> actual generic to conform to CONSTRAINT. You cannot rule out all
      > >>> expanded type actual generics or all reference type actual generics. You
      > >>> have to define a constraining base class and derive all the allowed
      > >>> actual generics which can be substituted for the formal generic from
      > >>> that base.
      > >>>
      > >>> Why do you want to forbid an expanded type to be used as an actual
      > >>> generic to substitute some formal. If you want to write class
      > >>> C[reference G], what constructs used in class C do you want to use that
      > >>> require that constraint? The reason for usual constraints or the
      > >>> constraint to accept only self initializing types are clear to me.
      > >>>
      > >>> Regards
      > >>> Helmut
      > >>>
      > >>> The Eiffel Compiler/Interpreter: http://tecomp.sourceforge.net
      > >>> http://www.sourceforge.net/projects/tecomp
      > >>>
      > >>>
      > >>>
      > >>>
      > >>>
      > >>>> JSO
      > >>>>
      > >>>> -----Original Message-----
      > >>>> From: eiffel_software@yahoogroups.com
      > >>>> [mailto:eiffel_software@yahoogroups.com] On Behalf Of Peter Gummer
      > >>>> Sent: Tuesday, November 25, 2008 9:48 PM
      > >>>> To: eiffel_software@yahoogroups.com
      > >>>> Subject: Re: [eiffel_software] CLASS[reference G]
      > >>>>
      > >>>> Jonathan S. Ostroff wrote:
      > >>>>
      > >>>>
      > >>>>
      > >>>>> CLASS[reference G]
      > >>>>>
      > >>>>> is not in the ECMA specification as far as I can see.
      > >>>>>
      > >>>>> However, it seems useful and is accepted by the current Eiffel 6.3
      > >>>>>
      > >>>>>
      > >>>>>
      > >>>> compiler
      > >>>>
      > >>>>
      > >>>> The "reference" keyword was added in one release of EiffelStudio (5.5, I
      > >>>> think), after a decision by the ECMA committee to add it to Eiffel. But
      > >>>> shortly after the release of that version of EiffelStudio the committee
      > >>>> decided on a better solution. So almost as soon as "reference" was
      > >>>> added, it became obsolete.
      > >>>>
      > >>>> I remember this because it prevented me from building Paul Crismer's
      > >>>> EPOM library at the time, and I had to qualify lots of formal generic
      > >>>> parameters with "reference". I don't know the details, however, of the
      > >>>> ECMA committee's decisions.
      > >>>>
      > >>>> So "reference" is not part of the Eiffel standard. It remains part of
      > >>>> EiffelStudio, presumably for the sake of backward compatibility.
      > >>>>
      > >>>> - Peter Gummer
      > >>>>
      > >>>>
      > >>>> ------------------------------------
      > >>>>
      > >>>> Yahoo! Groups Links
      > >>>>
      > >>>>
      > >>>>
      > >>>>
      > >>>>
      > >>>> ------------------------------------
      > >>>>
      > >>>> Yahoo! Groups Links
      > >>>>
      > >>>>
      > >>>>
      > >>>>
      > >>>>
      > >>>>
      > >>> ------------------------------------
      > >>>
      > >>> Yahoo! Groups Links
      > >>>
      > >>>
      > >>>
      > >>>
      > >>>
      > >>> ------------------------------------
      > >>>
      > >>> Yahoo! Groups Links
      > >>>
      > >>>
      > >>>
      > >>>
      > >>>
      > >
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
    Your message has been successfully submitted and would be delivered to recipients shortly.