On Fri, Nov 01, 2002 at 05:41:36PM +1100, Peter Horan wrote:
> Arno Wagner wrote:
> >
> > On Wed, Oct 23, 2002 at 06:09:20PM +0000, Franck Arnaud wrote:
> > > Arno:
> > >
> > > > There is what I fear is a serious bug in Eiffel.
> > > > It manifests itself in the postcondition "symmetric" of
> > > > "is_equal" actually specifying a run-time type constraint.
> > >
> > > It's just one instance of a catcall. All routines taking
> > > "like current" as a parameter create a cat call when
> > > used polymorphically.
>
> It is not a catcall if availability is not changed.
>
> Can someone remind me of the technical reasons why we cannot say
>     a.is_equal(b: ANY) ?

My personal feeling would be that a test

      a.is_equal(b)

is far more intuitive then a test

      a.same_type(b) and then a.is_equal(b)

since the first should (from my feeling) have the semantics of the
second by default.  Perhaps the reason is simply that ETL defined the
argument of 'is_equal' to be 'like Current' and nobody dared change it
so far.

However, contradictory as it sounds, basic comparison (for equality
only) is not the business of COMPARABLE. This is a quation that has to
be addressed in GENERAL. For the moment we have to live with the
restrictions GENARAL imposes.

However, should there not be strong reasons not to, we can
make the the comparison operators in GENERAL the next subject
for dicussion. Since this group probably has a good insight into
the issue at the moment this would likely be a good thing.

What about this discussion schedule for the next weeks:

1. Provisionally finish the discussion on COMPARABLE with
    a vote that accepts it for now.

2. Discuss 'is_equal', 'standard_equal', 'standard_is_equal',
    'equal' of COMPARABLE and probably make them more general
    with respect to the argument types allowed.

3. Re-visit COMPARABLE if needed.

4. Re-visit comparison in STRING.

5. Proceed with the original schedule.


Of course if Peter and me are overlooking some strong arguments
against against widening the semantics of the comparison
operators it would be good to find out soon....

Arno

--
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
For every complex problem there is an answer that is clear, simple,
and wrong. -- H L Mencken

You should soon receive an automatically-generated message from the
YahooGroups polling system, inviting you to vote on the following
proposal:

Refine the specification of class COMPARABLE to the version of
30 October 2002.

The 30 October 2002 version is below.
A list of changes is at the end.

Voting options are:

Strongly accept the proposal
Accept the proposal
Reject the proposal
Strongly reject the proposal
Don't mind (happy either way)
Abstain (not happy either way)

Voting is open to all NICE members. The YahooGroups poll will run for
three working days. If you cannot vote within that time, or have problems
with the YahooGroups polling system, feel free to post your vote to this
list.

I hope I understand the polling interface correctly.
Please tell me if it does not work as expected.

Regards,
Arno

----------------------------------------------------------------------
indexing

      description: "Objects of this type are ordered with respect %
      %to a total order relation."
      Note: "The basic operation `<' is used to define all other %
      %operations. `is_equal' is redefined in terms of `<'."

deferred class interface

      COMPARABLE

feature -- Basic Specifiers

    infix "<" (other: like Current): BOOLEAN
       -- Is current object less than `other'?
       require
          other_not_void: other /= Void

feature -- Comparison

    infix "<=" (other: like Current): BOOLEAN
       -- Is current object less than or equal to `other'?
       require
          other_not_void: other /= Void
       ensure
          definition: Result = not (other < Current)


    infix ">=" (other: like Current): BOOLEAN
       -- Is current object greater than or equal to `other'?
       require
          other_not_void: other /= Void
       ensure
          definition: Result = not (Current < other)


    infix ">" (other: like Current): BOOLEAN
       -- Is current object greater than `other'?
       require
          other_not_void: other /= Void
       ensure
          definition: Result = (other < Current)


    is_equal (other: like Current): BOOLEAN
       -- Is `other' attached to an object considered equal
       -- to current object?
       -- (Redefined from GENERAL.)
       require
           other_not_void: other /= Void
       ensure
          definition: Result = (not (Current < other) and
                                not (other < Current))
          symmetric: Result implies other.is_equal (Current)
          consistent: standard_is_equal (other) implies Result
          same_type: Result implies same_type (other)

    three_way_comparison (other: like Current): INTEGER
       -- If current object equal to `other', 0; if smaller,
       -- -1; if greater, 1.
       -- Redundant postcondition included for clarity.
       require
          other_not_void: other /= Void
       ensure
          legal_result: Result = -1 or Result = 0 or Result = 1
          zero_on_equal: (Result = 0) =
                         (not (Current < other) and not (other < Current))
          positive_on_larger:  (Result = 1)  = (other < Current)
          negative_on_smaller: (Result = -1) = (Current < other)

feature -- Selection

    max (other: like Current): like Current
       -- The greater of current object and `other', implementers choice
       -- if they are equal.
       require
          other_not_void: other /= Void
       ensure
          current_or_other: (Result = Current) or (Result = other)
          result_is_other: Current < other implies Result = other
          result_is_current: other < Current implies Result = Current

    min (other: like Current): like Current
       -- The smaller of current object and `other', implementers choice
       -- if they are equal.
       require
          other_not_void: other /= Void
       ensure
          current_or_other: (Result = Current) or (Result = other)
          result_is_other: other < Current implies Result = other
          result_is_current: Current < other implies Result = Current


invariant

irreflexivity: not (Current < Current)

-- asymmetry: for_all other : like Current :
--     ((other < Current) implies not (Current < other))

-- transitivity: for_all second : like Current :
--               for all third  : like Current :
--     ((second < Current) and (Current < third) implies (second < third)

-- trichotomy: for_all other : like Current :
--     exactly_one_of(other < Current,  Current < other, is_equal(other))

end
------------------------------------------------------------------------

The previous version of COMPARABLE is the version from ELKS'95.
Changes made are

- Head comment: The philosophy is now that everything is denied in
   terms of '<'. Comment adjusted accordingly.

- Renamed precondition 'other_exists' globally to 'other_not_void'.

- '<': Postcondition 'asymmetric' was removed, as basic specifiers
   (here only '<') should not have postconditions. The invariant
   'assymetry' captures the meaning now.

- '<=': Postcondition 'definition' rewritten to use only '<'.

- '>=': Postcondition 'definition' rewritten to use only '<'.

- 'is_equal': Postcondition 'definition' added, that redefines
    'is_equal' in terms of '<'.
    Postcondition 'trichotomy' removed and added as invariant.
    Postcondition 'same_type' added.

- 'three_way_comparison': Completely new postcondition set that
    is slightly redundant, but deemd much clearer.

- 'min','max': Moved to their own feature section "Selection".
    Completely new postcondition that allows the implementor to
    choose between the two possibilities if they compare equal.

- Invariant: Renamed 'irreflexive_comparison' to 'irreflexivity'
   to better match common use in mathematics.
   Added 'asymmerty', 'transitivity' 'trichotomy, that are
   non-executable because of quantification over element sets,
   but do now (together with 'irreflexivuty') completely
   specify '<' to be a total stict order.

--
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
For every complex problem there is an answer that is clear, simple,
and wrong. -- H L Mencken

Enter your vote today!  A new poll has been created for the
eiffel-nice-library group:

Refine the specification of class
COMPARABLE to the version of
30 October 2002.


   o Strongly accept the proposal
   o Accept the proposal
   o Reject the proposal
   o Strongly reject the proposal
   o Don't mind (happy either way)
   o Abstain (not happy either way)


To vote, please visit the following web page:

http://groups.yahoo.com/group/eiffel-nice-library/surveys?id=997002

Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.

Thanks!

Arno Wagner wrote:
>
> - Head comment: The philosophy is now that everything is denied in
-----------------------------------------------------------^^^^^^
defined

>   Added 'asymmerty', 'transitivity' 'trichotomy, that are
-----------------^^------------------^-----------^
'asymmetry', 'transitivity', 'trichotomy',

>   but do now (together with 'irreflexivuty') completely
-----------------------------------------^
'irreflexivity'

--
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com


__________________________________________________________________
Haut Débit: Modem offert soit 150,92 euros remboursés sur le Pack eXtense de
Wanadoo !
Profitez du Haut Débit à partir de 30 euros/mois :
http://www.ifrance.com/_reloc/w

Thanks, I will try to remember to spell-check next time.

Arno

--- In eiffel-nice-library@y..., Eric Bezault <ericb@g...> wrote:
> Arno Wagner wrote:
> >
> > - Head comment: The philosophy is now that everything is denied
in
> -----------------------------------------------------------^^^^^^
> defined
>
> >   Added 'asymmerty', 'transitivity' 'trichotomy, that are
> -----------------^^------------------^-----------^
> 'asymmetry', 'transitivity', 'trichotomy',
>
> >   but do now (together with 'irreflexivuty') completely
> -----------------------------------------^
> 'irreflexivity'
>
> --
> Eric Bezault
> mailto:ericb@g...
> http://www.gobosoft.com
>
>
>
__________________________________________________________________
> Haut Débit: Modem offert soit 150,92 euros remboursés sur le Pack
eXtense de Wanadoo !
> Profitez du Haut Débit à partir de 30 euros/mois :
http://www.ifrance.com/_reloc/w

gweihir2 wrote:
>
> Thanks, I will try to remember to spell-check next time.

Yes, it's better to avoid typos in standardization documents
when possible.

--
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com


__________________________________________________________________
Haut Débit: Modem offert soit 150,92 euros remboursés sur le Pack eXtense de
Wanadoo !
Profitez du Haut Débit à partir de 30 euros/mois :
http://www.ifrance.com/_reloc/w

Hi,

I am new to Eiffel (started 3 weeks ago) and I have a multiple
inheritance problem which I am not quite sure how to implement in
Eiffel. Can any of you guys please help out?

Basically, I have the following classes:
(Please don't be put-off, it's very easy stuff! – nothing
complex)





deferred class WRITING_INSTRUMENT

feature
color : STRING
price : INTEGER

setPrice(aPrice : INTEGER) is
do
price := aPrice
end -- setPrice

setColor(aColor : STRING) is
do
color := clone(aColor)
end -- setColor

stats is -- display a writing instrument
do
io.putstring("Color : ")
io.putstring(color); io.new_line
io.putstring("Price : ")
io.putint(price); io.new_line
end -- stats

getdata is
do
io.putstring("Enter color : ")
io.readword
setColor(io.laststring)
io.putstring("Enter price : $")
io.readint
setPrice(io.lastint)
end -- getdata

end -- WRITING_INSTRUMENT






class PENCIL

inherit
WRITING_INSTRUMENT
redefine
stats,
getdata
end

feature
eraserSize : INTEGER
leadthickness : INTEGER

setEraserSize(size : INTEGER) is
do
eraserSize := size
end -- setEraserSize

setLeadThickness(thickness : INTEGER) is
do
leadThickness := thickness
end -- setLeadThickness

stats is
do
precursor -- calls stats from WRITING_INSTRUMENT

io.putstring("Eraser size : ")
io.putint(eraserSize); io.new_line
io.putstring("Lead thickness : ")
io.putint(leadThickness); io.new_line
end -- stats

getdata is
do
precursor -- calls getdata from WRITING_INSTRUMENT

io.putstring("Enter eraser size : ")
io.readint
setEraserSize(io.lastint)
io.putstring("Enter lead thickness : ")
io.readint
setLeadThickness(io.lastint)
end -- getdata

end -- PENCIL






deferred class PEN

inherit
WRITING_INSTRUMENT
redefine
stats,
getdata
end

feature
inkColor : STRING
pointThickness : INTEGER

setInkColor(aColor : STRING) is
do
inkColor := clone(aColor)
end -- setInkColor

setPointThickness(thickness : INTEGER) is
do
pointThickness := thickness
end -- setPointThickness

stats is
do
precursor -- calls stats from WRITING_INSTRUMENT

io.putstring("Ink color : ")
io.putstring(inkColor); io.new_line
io.putstring("Point thickness : ")
io.putint(pointThickness); io.new_line
end -- stats

getdata is
do
precursor -- calls getdata from WRITING_INSTRUMENT

io.putstring("Enter ink color : ")
io.readword
setInkColor(io.laststring)
io.putstring("Enter point thickness : ")
io.readint
setPointThickness(io.lastint)
end -- getdata

end -- PEN






class
BALLPOINT_PEN

inherit
PEN
redefine
stats,
getdata
end

feature
ballType : STRING

setBallType(ball : STRING) is
do
ballType := clone(ball)
end -- setBallType

stats is
do
precursor -- calls stats from PEN

io.putstring("Ball type : ")
io.putstring(ballType); io.new_line
end -- stats

getdata is
do
precursor -- calls getdata from PEN

io.putstring("Enter ball type : ")
io.readword
setBallType(io.laststring)
end -- getdata

end -- class BALLPOINT_PEN




With the above classes I want to create a new class called
NOVELTY_PENCIL. A novelty pencil not only functions as a pencil but
also has a ballpoint pen at the other end. It does of course have a
single 'color' and 'price', but it also has the functionality of
pencils and ballpoint pens. Thus, NOVELTY_PENCIL inherits from PENCIL
and BALLPOINT_PEN.

Has anyone got any ideas how I can make this work without clashing
with the attributes from the inherited hierarchy? Thank you for your
help.

Thank you.

On Friday, November 1, 2002, at 02:49  PM, Steve wrote:

> No this ain't HW. I'm a C# .NET guy but I've got this old Eiffel
> project to do - Just started learning Eiffel 3 weeks ago! I'm going
> to learn Eiffel .NET soon to integrate with the project, but I'm
> stuck on a few basics that new OO languages avoid like multiple
> inheritance.

The best help is to correct the above misconception (at the danger of
provoking a bunch of emotive responses). Multiple inheritance is a
necessary part of sophisticated OO design. The so-called new languages
could not implement it cleanly and/or efficiently so argued against it a
posteriory, of course the absolute proof being the mess in C++. Java
(and I think C#) does have MI of interfaces, and again not very
convincing arguments (and theoretical) for not having MI of
implementation, where in fact it is the most practical, especially in
inheriting default behaviour from multiple and possibly unrelated
sources.

The alternative in Java is to force every class to implement the same
behaviour just to satisfy the interface, instead of being able to put
the behaviour where you want it, thus being able to design things with
elegance and flexibilty. The supposed solution in Java is nested
classes, but this is messy and not very convincing.

Whether something is newer or not is also irrelevant. Eiffel may be
getting on for 20 years old, but nothing better in terms of cleanness of
syntax or concept has come along. We are still waiting for the world to
catch up. Since I am about to finish a very large and significant class
library, I can say that there just isn't any other commercial language
that can come close to implementing what I have done with such elegance.

You really need to study MI carefully and use a good implementation of
it, like Eiffel's in practice, and not think that because something has
come along later, it must be better, it just ain't true.

Ian

>
> Thanks for any help.
>
>
>
> --- In eiffel-nice-library@y..., James McKim <jcm@r...> wrote:
>> Um, can you assure us this isn't a HW assignment? Suuuuuure
>> looks like one....
>>
>> -- Jim
>>
>>
>>> From sentto-1180083-1497-1036031374-jcm=rh.edu@r... Wed Oct 30
> 21:30 EST 2002
>>> X-eGroups-Return: sentto-1180083-1497-1036031374-jcm=rh.edu@r...
>>> X-Sender: s_t_e_v_e_1981@y...
>>> X-Apparently-To: eiffel-nice-library@y...
>>> To: eiffel-nice-library@y...
>>> User-Agent: eGroups-EW/0.82
>>> X-Mailer: Yahoo Groups Message Poster
>>> X-Originating-IP: 172.182.23.221
>>> X-Yahoo-Profile: s_t_e_v_e_1981
>>> MIME-Version: 1.0
>>> Mailing-List: list eiffel-nice-library@y...; contact eiffel-nice-
> library-owner@y...
>>> Delivered-To: mailing list eiffel-nice-library@y...
>>> List-Unsubscribe: <mailto:eiffel-nice-library-unsubscribe@y...>
>>> Subject: [eiffel-nice-library] Newbie Multiple Inheritance
> Help !!!
>>> Reply-To: eiffel-nice-library@y...
>>> Content-Transfer-Encoding: 8bit
>>> X-MIME-Autoconverted: from quoted-printable to 8bit by
> mstr.rh.edu id VAA09016
>>> X-Lines: 229
>>>
>>> Hi,
>>>
>>> I am new to Eiffel (started 3 weeks ago) and I have a multiple
>>> inheritance problem which I am not quite sure how to implement in
>>> Eiffel. Can any of you guys please help out?
>>>
>>> Basically, I have the following classes:
>>> (Please don't be put-off, it's very easy stuff! – nothing
>>> complex)
>>>
>>>
>>>
>>>
>>>
>>> deferred class WRITING_INSTRUMENT
>>>
>>> feature
>>>  color : STRING
>>>  price : INTEGER
>>>
>>>  setPrice(aPrice : INTEGER) is
>>>  do
>>> 	 price := aPrice
>>>  end -- setPrice
>>>
>>>  setColor(aColor : STRING) is
>>>  do
>>> 	 color := clone(aColor)
>>>  end -- setColor
>>>
>>>  stats is -- display a writing instrument
>>>  do
>>> 	 io.putstring("Color : ")
>>> 	 io.putstring(color); io.new_line
>>> 	 io.putstring("Price : ")
>>> 	 io.putint(price);  io.new_line
>>>  end -- stats
>>>
>>>  getdata is
>>>  do
>>> 	 io.putstring("Enter color : ")
>>> 	 io.readword
>>> 	 setColor(io.laststring)
>>> 	 io.putstring("Enter price : $")
>>> 	 io.readint
>>> 	 setPrice(io.lastint)
>>>  end -- getdata
>>>
>>> end -- WRITING_INSTRUMENT
>>>
>>>
>>>
>>>
>>>
>>>
>>> class PENCIL
>>>
>>> inherit
>>>  WRITING_INSTRUMENT
>>>  redefine
>>> 	 stats,
>>> 	 getdata
>>>  end
>>>
>>> feature
>>>  eraserSize : INTEGER
>>>  leadthickness : INTEGER
>>>
>>>  setEraserSize(size : INTEGER) is
>>>  do
>>> 	 eraserSize := size
>>>  end -- setEraserSize
>>>
>>>  setLeadThickness(thickness : INTEGER) is
>>>  do
>>> 	 leadThickness := thickness
>>>  end -- setLeadThickness
>>>
>>>  stats is
>>>  do
>>> 	 precursor -- calls stats from WRITING_INSTRUMENT
>>>
>>> 	 io.putstring("Eraser size : ")
>>> 	 io.putint(eraserSize);  io.new_line
>>> 	 io.putstring("Lead thickness : ")
>>> 	 io.putint(leadThickness);  io.new_line
>>>  end -- stats
>>>
>>>  getdata is
>>>  do
>>> 	 precursor -- calls getdata from WRITING_INSTRUMENT
>>>
>>> 	 io.putstring("Enter eraser size : ")
>>> 	 io.readint
>>> 	 setEraserSize(io.lastint)
>>> 	 io.putstring("Enter lead thickness : ")
>>> 	 io.readint
>>> 	 setLeadThickness(io.lastint)
>>>  end -- getdata
>>>
>>> end -- PENCIL
>>>
>>>
>>>
>>>
>>>
>>>
>>> deferred class PEN
>>>
>>> inherit
>>>  WRITING_INSTRUMENT
>>>  redefine
>>> 	 stats,
>>> 	 getdata
>>>  end
>>>
>>> feature
>>>  inkColor : STRING
>>>  pointThickness : INTEGER
>>>
>>>  setInkColor(aColor : STRING) is
>>>  do
>>> 	 inkColor := clone(aColor)
>>>  end -- setInkColor
>>>
>>>  setPointThickness(thickness : INTEGER) is
>>>  do
>>> 	 pointThickness := thickness
>>>  end -- setPointThickness
>>>
>>>  stats is
>>>  do
>>> 	 precursor -- calls stats from WRITING_INSTRUMENT
>>>
>>> 	 io.putstring("Ink color : ")
>>> 	 io.putstring(inkColor); io.new_line
>>> 	 io.putstring("Point thickness : ")
>>> 	 io.putint(pointThickness); io.new_line
>>>  end -- stats
>>>
>>>  getdata is
>>>  do
>>> 	 precursor -- calls getdata from WRITING_INSTRUMENT
>>>
>>> 	 io.putstring("Enter ink color : ")
>>> 	 io.readword
>>> 	 setInkColor(io.laststring)
>>> 	 io.putstring("Enter point thickness : ")
>>> 	 io.readint
>>> 	 setPointThickness(io.lastint)
>>>  end -- getdata
>>>
>>> end -- PEN
>>>
>>>
>>>
>>>
>>>
>>>
>>> class
>>>  BALLPOINT_PEN
>>>
>>> inherit
>>>  PEN
>>>  redefine
>>> 	 stats,
>>> 	 getdata
>>>  end
>>>
>>> feature
>>>  ballType : STRING
>>>
>>>  setBallType(ball : STRING) is
>>>  do
>>> 	 ballType := clone(ball)
>>>  end -- setBallType
>>>
>>>  stats is
>>>  do
>>> 	 precursor -- calls stats from PEN
>>>
>>> 	 io.putstring("Ball type : ")
>>> 	 io.putstring(ballType); io.new_line
>>>  end -- stats
>>>
>>>  getdata is
>>>  do
>>> 	 precursor -- calls getdata from PEN
>>>
>>> 	 io.putstring("Enter ball type : ")
>>> 	 io.readword
>>> 	 setBallType(io.laststring)
>>>  end -- getdata
>>>
>>> end -- class BALLPOINT_PEN
>>>
>>>
>>>
>>>
>>> With the above classes I want to create a new class called
>>> NOVELTY_PENCIL. A novelty pencil not only functions as a pencil
> but
>>> also has a ballpoint pen at the other end. It does of course have
> a
>>> single 'color' and 'price', but it also has the functionality of
>>> pencils and ballpoint pens. Thus, NOVELTY_PENCIL inherits from
> PENCIL
>>> and BALLPOINT_PEN.
>>>
>>> Has anyone got any ideas how I can make this work without
> clashing
>>> with the attributes from the inherited hierarchy? Thank you for
> your
>>> help.
>>>
>>> Thank you.
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------
>>>
>>> http://www.eiffel-nice.org/
>>>
>>> --------------------------
>>>
>>> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>>>
>>>
>>>
>
>
>
> ---------------------------
>
> http://www.eiffel-nice.org/
>
> --------------------------
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
>
Ian

Well, it really smells like a homework assignment. Whether it is or not,
I can hint that you first assemble the NOVELTY_PEN class inheriting
BALLPOINT_PEN and PENCIL, compile it and see where the compiler
complains about clashes. Use renames/select clauses to disambiguate,
reading up about these in OOSC or Eiffel: The Language. Then when you
turn your assignment in, or turn it into a major project, use standard
Eiffel (and natural language) formatting. ':'s are not preceded by white
space (in both code and io routines), but '(' is (observe this in any
natural language book). Don't use upcase to delimit words in
identifiers, eg 'setPrice' should be 'set_price'. Then you have
consistency of underscore use in both upcase names (as in class names,
or #define names in C). A practice I have recently used is to call
parameters to 'set' routines 'to_'x, so name 'aPrice' 'to_price'. Use a
require clause:

	 set_price (to_price: INTEGER) is
		 require
			 to_price >= 0
		 do
			 price := to_price
		 ensure
			 price = to_price
		 end -- set_price

and get top marks! But better than that, this is just good programming,
using something useful, like design by contract, instead of useless junk
like UML.

Good luck.

Ian

On Saturday, November 2, 2002, at 01:39  PM, Steve wrote:

> Hi,
>
> I am new to Eiffel (started 3 weeks ago) and I have a multiple
> inheritance problem which I am not quite sure how to implement in
> Eiffel. Can any of you guys please help out?
>
> Basically, I have the following classes:
> (Please don't be put-off, it's very easy stuff! – nothing
> complex)
>
>
>
>
>
> deferred class WRITING_INSTRUMENT
>
> feature
> color : STRING
> price : INTEGER
>
> setPrice(aPrice : INTEGER) is
> do
> price := aPrice
> end -- setPrice
>
> setColor(aColor : STRING) is
> do
> color := clone(aColor)
> end -- setColor
>
> stats is -- display a writing instrument
> do
> io.putstring("Color : ")
> io.putstring(color); io.new_line
> io.putstring("Price : ")
> io.putint(price); io.new_line
> end -- stats
>
> getdata is
> do
> io.putstring("Enter color : ")
> io.readword
> setColor(io.laststring)
> io.putstring("Enter price : $")
> io.readint
> setPrice(io.lastint)
> end -- getdata
>
> end -- WRITING_INSTRUMENT
>
>
>
>
>
>
> class PENCIL
>
> inherit
> WRITING_INSTRUMENT
> redefine
> stats,
> getdata
> end
>
> feature
> eraserSize : INTEGER
> leadthickness : INTEGER
>
> setEraserSize(size : INTEGER) is
> do
> eraserSize := size
> end -- setEraserSize
>
> setLeadThickness(thickness : INTEGER) is
> do
> leadThickness := thickness
> end -- setLeadThickness
>
> stats is
> do
> precursor -- calls stats from WRITING_INSTRUMENT
>
> io.putstring("Eraser size : ")
> io.putint(eraserSize); io.new_line
> io.putstring("Lead thickness : ")
> io.putint(leadThickness); io.new_line
> end -- stats
>
> getdata is
> do
> precursor -- calls getdata from WRITING_INSTRUMENT
>
> io.putstring("Enter eraser size : ")
> io.readint
> setEraserSize(io.lastint)
> io.putstring("Enter lead thickness : ")
> io.readint
> setLeadThickness(io.lastint)
> end -- getdata
>
> end -- PENCIL
>
>
>
>
>
>
> deferred class PEN
>
> inherit
> WRITING_INSTRUMENT
> redefine
> stats,
> getdata
> end
>
> feature
> inkColor : STRING
> pointThickness : INTEGER
>
> setInkColor(aColor : STRING) is
> do
> inkColor := clone(aColor)
> end -- setInkColor
>
> setPointThickness(thickness : INTEGER) is
> do
> pointThickness := thickness
> end -- setPointThickness
>
> stats is
> do
> precursor -- calls stats from WRITING_INSTRUMENT
>
> io.putstring("Ink color : ")
> io.putstring(inkColor); io.new_line
> io.putstring("Point thickness : ")
> io.putint(pointThickness); io.new_line
> end -- stats
>
> getdata is
> do
> precursor -- calls getdata from WRITING_INSTRUMENT
>
> io.putstring("Enter ink color : ")
> io.readword
> setInkColor(io.laststring)
> io.putstring("Enter point thickness : ")
> io.readint
> setPointThickness(io.lastint)
> end -- getdata
>
> end -- PEN
>
>
>
>
>
>
> class
> BALLPOINT_PEN
>
> inherit
> PEN
> redefine
> stats,
> getdata
> end
>
> feature
> ballType : STRING
>
> setBallType(ball : STRING) is
> do
> ballType := clone(ball)
> end -- setBallType
>
> stats is
> do
> precursor -- calls stats from PEN
>
> io.putstring("Ball type : ")
> io.putstring(ballType); io.new_line
> end -- stats
>
> getdata is
> do
> precursor -- calls getdata from PEN
>
> io.putstring("Enter ball type : ")
> io.readword
> setBallType(io.laststring)
> end -- getdata
>
> end -- class BALLPOINT_PEN
>
>
>
>
> With the above classes I want to create a new class called
> NOVELTY_PENCIL. A novelty pencil not only functions as a pencil but
> also has a ballpoint pen at the other end. It does of course have a
> single 'color' and 'price', but it also has the functionality of
> pencils and ballpoint pens. Thus, NOVELTY_PENCIL inherits from PENCIL
> and BALLPOINT_PEN.
>
> Has anyone got any ideas how I can make this work without clashing
> with the attributes from the inherited hierarchy? Thank you for your
> help.
>
> Thank you.
>
>
>
>
> ---------------------------
>
> http://www.eiffel-nice.org/
>
> --------------------------
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
>
Ian

Ian Joyner <i.joyner@...> writes:

> catch up. Since I am about to finish a very large and significant class
> library, I can say that there just isn't any other commercial language
> that can come close to implementing what I have done with such
> elegance.

We hold our breath Ian, what are you up to? :-) Is it going to be EFL?


--
Live long and prosper,

Berend de Boer

Arno Wagner wrote:

I wrote:
> > Can someone remind me of the technical reasons why we cannot say
> >     a.is_equal(b: ANY) ?
>
> My personal feeling would be that a test
>
>      a.is_equal(b)
>
> is far more intuitive then a test
>
>      a.same_type(b) and then a.is_equal(b)
>
> since the first should (from my feeling) have the semantics of the
> second by default.  Perhaps the reason is simply that ETL defined the
> argument of 'is_equal' to be 'like Current' and nobody dared change it
> so far.

What crystalised it for me was the recognition that "like Current" implies
dynamic arguments and therefore, the precondition of the signature is
"dynamically, other is like current". So this precondition can be mapped to an
implication of the result in the postcondition and made static.

> However, contradictory as it sounds, basic comparison (for equality
> only) is not the business of COMPARABLE. This is a quation that has to
> be addressed in GENERAL. For the moment we have to live with the
> restrictions GENARAL imposes.

Yes. That thought flitted past without investigation because comparable is
really about "<", not is_equal. Perhaps we should be thinking about EQUATABLE or
EQUABLE for "is_equal".

> However, should there not be strong reasons not to, we can
> make the the comparison operators in GENERAL the next subject
> for dicussion. Since this group probably has a good insight into
> the issue at the moment this would likely be a good thing.
>
> What about this discussion schedule for the next weeks:
>
> 1. Provisionally finish the discussion on COMPARABLE with
>    a vote that accepts it for now.
>
> 2. Discuss 'is_equal', 'standard_equal', 'standard_is_equal',
>    'equal' of COMPARABLE and probably make them more general
>    with respect to the argument types allowed.
>
> 3. Re-visit COMPARABLE if needed.
>
> 4. Re-visit comparison in STRING.
>
> 5. Proceed with the original schedule.

This is a fine plan.
--
Peter Horan                     School of Information Technology
peter@...             Deakin University
+61-3-5227 1234 (Voice)         Geelong, Victoria 3217, AUSTRALIA
+61-3-5227 2028 (FAX)           http://www.cm.deakin.edu.au/~peter

-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)

----- Original Message -----

From: Steve

To: eiffel-nice-library@yahoogroups.com

Sent: Friday, November 01, 2002 9:39 PM

Subject: [eiffel-nice-library] C'mon guys, sort this out !

Hi,

I am new to Eiffel (started 3 weeks ago) and I have a multiple
inheritance problem which I am not quite sure how to implement in
Eiffel. Can any of you guys please help out?

Basically, I have the following classes:
(Please don't be put-off, it's very easy stuff! – nothing
complex)





deferred class WRITING_INSTRUMENT

feature
color : STRING
price : INTEGER

setPrice(aPrice : INTEGER) is
do
price := aPrice
end -- setPrice

setColor(aColor : STRING) is
do
color := clone(aColor)
end -- setColor

stats is -- display a writing instrument
do
io.putstring("Color : ")
io.putstring(color); io.new_line
io.putstring("Price : ")
io.putint(price); io.new_line
end -- stats

getdata is
do
io.putstring("Enter color : ")
io.readword
setColor(io.laststring)
io.putstring("Enter price : $")
io.readint
setPrice(io.lastint)
end -- getdata

end -- WRITING_INSTRUMENT






class PENCIL

inherit
WRITING_INSTRUMENT
redefine
stats,
getdata
end

feature
eraserSize : INTEGER
leadthickness : INTEGER

setEraserSize(size : INTEGER) is
do
eraserSize := size
end -- setEraserSize

setLeadThickness(thickness : INTEGER) is
do
leadThickness := thickness
end -- setLeadThickness

stats is
do
precursor -- calls stats from WRITING_INSTRUMENT

io.putstring("Eraser size : ")
io.putint(eraserSize); io.new_line
io.putstring("Lead thickness : ")
io.putint(leadThickness); io.new_line
end -- stats

getdata is
do
precursor -- calls getdata from WRITING_INSTRUMENT

io.putstring("Enter eraser size : ")
io.readint
setEraserSize(io.lastint)
io.putstring("Enter lead thickness : ")
io.readint
setLeadThickness(io.lastint)
end -- getdata

end -- PENCIL






deferred class PEN

inherit
WRITING_INSTRUMENT
redefine
stats,
getdata
end

feature
inkColor : STRING
pointThickness : INTEGER

setInkColor(aColor : STRING) is
do
inkColor := clone(aColor)
end -- setInkColor

setPointThickness(thickness : INTEGER) is
do
pointThickness := thickness
end -- setPointThickness

stats is
do
precursor -- calls stats from WRITING_INSTRUMENT

io.putstring("Ink color : ")
io.putstring(inkColor); io.new_line
io.putstring("Point thickness : ")
io.putint(pointThickness); io.new_line
end -- stats

getdata is
do
precursor -- calls getdata from WRITING_INSTRUMENT

io.putstring("Enter ink color : ")
io.readword
setInkColor(io.laststring)
io.putstring("Enter point thickness : ")
io.readint
setPointThickness(io.lastint)
end -- getdata

end -- PEN






class
BALLPOINT_PEN

inherit
PEN
redefine
stats,
getdata
end

feature
ballType : STRING

setBallType(ball : STRING) is
do
ballType := clone(ball)
end -- setBallType

stats is
do
precursor -- calls stats from PEN

io.putstring("Ball type : ")
io.putstring(ballType); io.new_line
end -- stats

getdata is
do
precursor -- calls getdata from PEN

io.putstring("Enter ball type : ")
io.readword
setBallType(io.laststring)
end -- getdata

end -- class BALLPOINT_PEN




With the above classes I want to create a new class called
NOVELTY_PENCIL. A novelty pencil not only functions as a pencil but
also has a ballpoint pen at the other end. It does of course have a
single 'color' and 'price', but it also has the functionality of
pencils and ballpoint pens. Thus, NOVELTY_PENCIL inherits from PENCIL
and BALLPOINT_PEN.

Has anyone got any ideas how I can make this work without clashing
with the attributes from the inherited hierarchy? Thank you for your
help.

Thank you.



---------------------------

http://www.eiffel-nice.org/

--------------------------

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Hello,

And sorry to start again the discussion, but

> Refine the specification of class COMPARABLE to the version
> of 30 October 2002.

I voted "not happy either way".

The problem I find with this spec is the same as the problem
with GENERAL.is_equal : the anchored argument.

The postconditions of is_equal, infix ">" and so on involve
some symmetric (or quite-symmetric) calls, and `other' being
like Current does not mean that Current is like `other' <grin>

What do you plan to do with that issue?
--
Cyril ADRIAN
mailto:cyril.adrian@...
http://www.chez.com/cadrian/eiffel.html
http://www.advogato.org/person/cadrian



Accédez au courrier électronique de La Poste : www.laposte.net ;
3615 LAPOSTENET (0,13 €/mn) ; tél : 08 92 68 13 50 (0,34€/mn)"

> > What about this discussion schedule for the next weeks:
> >
> > 1. Provisionally finish the discussion on COMPARABLE with
> >    a vote that accepts it for now.
> >
> > 2. Discuss 'is_equal', 'standard_equal',
> >    'standard_is_equal', 'equal' of COMPARABLE and probably
> >    make them more general with respect to the argument
> >    types allowed.
> >
> > 3. Re-visit COMPARABLE if needed.
> >
> > 4. Re-visit comparison in STRING.
> >
> > 5. Proceed with the original schedule.
>
> This is a fine plan.

Sorry I did not read that before. I agree with this "one-step-
after-another" plan.

Then I'll accept the COMPARABLE modification, provided that we
talk again about it soon.

Regards,
--
Cyril ADRIAN
mailto:cyril.adrian@...
http://www.chez.com/cadrian/eiffel.html
http://www.advogato.org/person/cadrian



Accédez au courrier électronique de La Poste : www.laposte.net ;
3615 LAPOSTENET (0,13 €/mn) ; tél : 08 92 68 13 50 (0,34€/mn)"

On Sat, Nov 02, 2002 at 09:09:58AM +0100, Cyril Adrian wrote:
> > > What about this discussion schedule for the next weeks:
> > > 1. Provisionally finish the discussion on COMPARABLE with
> > >    a vote that accepts it for now.
> > > 2. Discuss 'is_equal', 'standard_equal',
> > >    'standard_is_equal', 'equal' of COMPARABLE and probably
> > >    make them more general with respect to the argument
> > >    types allowed.
> > > 3. Re-visit COMPARABLE if needed.
> > > 4. Re-visit comparison in STRING.
> > > 5. Proceed with the original schedule.
>
> Sorry I did not read that before. I agree with this "one-step-
> after-another" plan.
>
> Then I'll accept the COMPARABLE modification,

Fine!

> provided that we talk again about it soon.

That was the idea. I will see whether I can modify your vote or
whether I will have to post a modified result.

Arno
---
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
For every complex problem there is an answer that is clear, simple,
and wrong. -- H L Mencken

> I will see whether I can modify your vote or
> whether I will have to post a modified result.

Thank you, I did it myself :o)

Regards,
--
Cyril ADRIAN
mailto:cyril.adrian@...
http://www.chez.com/cadrian/eiffel.html
http://www.advogato.org/person/cadrian



Accédez au courrier électronique de La Poste : www.laposte.net ;
3615 LAPOSTENET (0,13 €/mn) ; tél : 08 92 68 13 50 (0,34€/mn)"

> It is not a catcall if availability is not changed.

That's limited to classes with no descendants
in the system, for calls correctly statically typed
with those descendant-free types, because with
'like Current' availability is always (implicitely
if not explicitely) changed when descendants exist.

> Can someone remind me of the technical reasons why we cannot say
>     a.is_equal(b: ANY) ?

We could I guess. It does not remove the catcalls, but
restricts them to cases where there are explicit
redefinitions, so allows more valid scenarios (often not
statically type checked of course).

On the other hand, it allows creating new broken cases,
e.g. in PARENT, one could redefine

  is_equal(other:CHILD)

making a catcall of:
  a_parent.is_equal(another_parent)

and even:
  a_parent.is_equal (a_parent)

which becomes a (run-time) type error for
a PARENT dynamic type, while this would be
correct in the 'like Current' case.

(Actually, I'm not really sure such an explicit redefinition
is not allowed with 'like Current' in the ancestor, but it's
clearly against the aim of 'like Current', while it's a
perfectly valid covariant redefinition of an ANY parameter.)

Another point is that if "like Current" is not useful
for is_equal, it's hard to think it could be useful for
anything else, at least as a type for a routine parameter
(as opposed to function or attribute type). This brings
us back to the language issue: is_equal is an instance of
a binary method, and what is the correct idiom or language
feature to support binary methods is a language question,
once that question is answered generally, it's easy to
apply the answer to is_equal (and COMPARABLE).

Franck Arnaud wrote:
>
> > It is not a catcall if availability is not changed.
>
> That's limited to classes with no descendants
> in the system, for calls correctly statically typed
> with those descendant-free types, because with
> 'like Current' availability is always (implicitely
> if not explicitely) changed when descendants exist.

Thanks. I'll have to take a look at the catcall definitions again.
--
Peter Horan                     School of Information Technology
peter@...             Deakin University
+61-3-5227 1234 (Voice)         Geelong, Victoria 3217, AUSTRALIA
+61-3-5227 2028 (FAX)           http://www.cm.deakin.edu.au/~peter

-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)

Peter Horan wrote:
>
> Franck Arnaud wrote:
> >
> > > It is not a catcall if availability is not changed.
> >
> > That's limited to classes with no descendants
> > in the system, for calls correctly statically typed
> > with those descendant-free types, because with
> > 'like Current' availability is always (implicitely
> > if not explicitely) changed when descendants exist.
>
> Thanks. I'll have to take a look at the catcall definitions again.

For some reason, I have always thought of the acronym CAT standing for Changed
Availabilty AND Type, whereas it is Changed Availablity OR Type. So, because the
type changes dynamically because of "like Current" it is a catcall.
--
Peter Horan                     School of Information Technology
peter@...             Deakin University
+61-3-5227 1234 (Voice)         Geelong, Victoria 3217, AUSTRALIA
+61-3-5227 2028 (FAX)           http://www.cm.deakin.edu.au/~peter

-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)

Please to to the newsgroup comp.lang.eiffel with such issues.

On 1 Nov 2002 at 3:49, Steve wrote:

> No this ain't HW. I'm a C# .NET guy but I've got this old Eiffel
> project to do - Just started learning Eiffel 3 weeks ago! I'm going
> to learn Eiffel .NET soon to integrate with the project, but I'm
> stuck on a few basics that new OO languages avoid like multiple
> inheritance.
>
> Thanks for any help.
>
>
>
> --- In eiffel-nice-library@y..., James McKim <jcm@r...> wrote:
> > Um, can you assure us this isn't a HW assignment? Suuuuuure
> > looks like one....
> >
> > -- Jim
> >
> >
> > > From sentto-1180083-1497-1036031374-jcm=rh.edu@r... Wed Oct 30
> 21:30 EST 2002
> > > X-eGroups-Return: sentto-1180083-1497-1036031374-jcm=rh.edu@r...
> > > X-Sender: s_t_e_v_e_1981@y...
> > > X-Apparently-To: eiffel-nice-library@y...
> > > To: eiffel-nice-library@y...
> > > User-Agent: eGroups-EW/0.82
> > > X-Mailer: Yahoo Groups Message Poster
> > > X-Originating-IP: 172.182.23.221
> > > X-Yahoo-Profile: s_t_e_v_e_1981
> > > MIME-Version: 1.0
> > > Mailing-List: list eiffel-nice-library@y...; contact eiffel-nice-
> library-owner@y...
> > > Delivered-To: mailing list eiffel-nice-library@y...
> > > List-Unsubscribe: <mailto:eiffel-nice-library-unsubscribe@y...>
> > > Subject: [eiffel-nice-library] Newbie Multiple Inheritance
> Help !!!
> > > Reply-To: eiffel-nice-library@y...
> > > Content-Transfer-Encoding: 8bit
> > > X-MIME-Autoconverted: from quoted-printable to 8bit by
> mstr.rh.edu id VAA09016
> > > X-Lines: 229
> > >
> > > Hi,
> > >
> > > I am new to Eiffel (started 3 weeks ago) and I have a multiple
> > > inheritance problem which I am not quite sure how to implement in
> > > Eiffel. Can any of you guys please help out?
> > >
> > > Basically, I have the following classes:
> > > (Please don't be put-off, it's very easy stuff! – nothing
> > > complex)
> > >
> > >
> > >
> > >
> > >
> > > deferred class WRITING_INSTRUMENT
> > >
> > > feature
> > >  color : STRING
> > >  price : INTEGER
> > >
> > >  setPrice(aPrice : INTEGER) is
> > >  do
> > > 	 price := aPrice
> > >  end -- setPrice
> > >
> > >  setColor(aColor : STRING) is
> > >  do
> > > 	 color := clone(aColor)
> > >  end -- setColor
> > >
> > >  stats is -- display a writing instrument
> > >  do
> > > 	 io.putstring("Color : ")
> > > 	 io.putstring(color); io.new_line
> > > 	 io.putstring("Price : ")
> > > 	 io.putint(price);  io.new_line
> > >  end -- stats
> > >
> > >  getdata is
> > >  do
> > > 	 io.putstring("Enter color : ")
> > > 	 io.readword
> > > 	 setColor(io.laststring)
> > > 	 io.putstring("Enter price : $")
> > > 	 io.readint
> > > 	 setPrice(io.lastint)
> > >  end -- getdata
> > >
> > > end -- WRITING_INSTRUMENT
> > >
> > >
> > >
> > >
> > >
> > >
> > > class PENCIL
> > >
> > > inherit
> > >  WRITING_INSTRUMENT
> > >  redefine
> > > 	 stats,
> > > 	 getdata
> > >  end
> > >
> > > feature
> > >  eraserSize : INTEGER
> > >  leadthickness : INTEGER
> > >
> > >  setEraserSize(size : INTEGER) is
> > >  do
> > > 	 eraserSize := size
> > >  end -- setEraserSize
> > >
> > >  setLeadThickness(thickness : INTEGER) is
> > >  do
> > > 	 leadThickness := thickness
> > >  end -- setLeadThickness
> > >
> > >  stats is
> > >  do
> > > 	 precursor -- calls stats from WRITING_INSTRUMENT
> > >
> > > 	 io.putstring("Eraser size : ")
> > > 	 io.putint(eraserSize);  io.new_line
> > > 	 io.putstring("Lead thickness : ")
> > > 	 io.putint(leadThickness);  io.new_line
> > >  end -- stats
> > >
> > >  getdata is
> > >  do
> > > 	 precursor -- calls getdata from WRITING_INSTRUMENT
> > >
> > > 	 io.putstring("Enter eraser size : ")
> > > 	 io.readint
> > > 	 setEraserSize(io.lastint)
> > > 	 io.putstring("Enter lead thickness : ")
> > > 	 io.readint
> > > 	 setLeadThickness(io.lastint)
> > >  end -- getdata
> > >
> > > end -- PENCIL
> > >
> > >
> > >
> > >
> > >
> > >
> > > deferred class PEN
> > >
> > > inherit
> > >  WRITING_INSTRUMENT
> > >  redefine
> > > 	 stats,
> > > 	 getdata
> > >  end
> > >
> > > feature
> > >  inkColor : STRING
> > >  pointThickness : INTEGER
> > >
> > >  setInkColor(aColor : STRING) is
> > >  do
> > > 	 inkColor := clone(aColor)
> > >  end -- setInkColor
> > >
> > >  setPointThickness(thickness : INTEGER) is
> > >  do
> > > 	 pointThickness := thickness
> > >  end -- setPointThickness
> > >
> > >  stats is
> > >  do
> > > 	 precursor -- calls stats from WRITING_INSTRUMENT
> > >
> > > 	 io.putstring("Ink color : ")
> > > 	 io.putstring(inkColor); io.new_line
> > > 	 io.putstring("Point thickness : ")
> > > 	 io.putint(pointThickness); io.new_line
> > >  end -- stats
> > >
> > >  getdata is
> > >  do
> > > 	 precursor -- calls getdata from WRITING_INSTRUMENT
> > >
> > > 	 io.putstring("Enter ink color : ")
> > > 	 io.readword
> > > 	 setInkColor(io.laststring)
> > > 	 io.putstring("Enter point thickness : ")
> > > 	 io.readint
> > > 	 setPointThickness(io.lastint)
> > >  end -- getdata
> > >
> > > end -- PEN
> > >
> > >
> > >
> > >
> > >
> > >
> > > class
> > >  BALLPOINT_PEN
> > >
> > > inherit
> > >  PEN
> > >  redefine
> > > 	 stats,
> > > 	 getdata
> > >  end
> > >
> > > feature
> > >  ballType : STRING
> > >
> > >  setBallType(ball : STRING) is
> > >  do
> > > 	 ballType := clone(ball)
> > >  end -- setBallType
> > >
> > >  stats is
> > >  do
> > > 	 precursor -- calls stats from PEN
> > >
> > > 	 io.putstring("Ball type : ")
> > > 	 io.putstring(ballType); io.new_line
> > >  end -- stats
> > >
> > >  getdata is
> > >  do
> > > 	 precursor -- calls getdata from PEN
> > >
> > > 	 io.putstring("Enter ball type : ")
> > > 	 io.readword
> > > 	 setBallType(io.laststring)
> > >  end -- getdata
> > >
> > > end -- class BALLPOINT_PEN
> > >
> > >
> > >
> > >
> > > With the above classes I want to create a new class called
> > > NOVELTY_PENCIL. A novelty pencil not only functions as a pencil
> but
> > > also has a ballpoint pen at the other end. It does of course have
> a
> > > single 'color' and 'price', but it also has the functionality of
> > > pencils and ballpoint pens. Thus, NOVELTY_PENCIL inherits from
> PENCIL
> > > and BALLPOINT_PEN.
> > >
> > > Has anyone got any ideas how I can make this work without
> clashing
> > > with the attributes from the inherited hierarchy? Thank you for
> your
> > > help.
> > >
> > > Thank you.
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------
> > >
> > > http://www.eiffel-nice.org/
> > >
> > > --------------------------
> > >
> > > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> > >
> > >
> > >
>
>
>
> ---------------------------
>
> http://www.eiffel-nice.org/
>
> --------------------------
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

On 1 Nov 2002 at 15:59, Arno Wagner wrote:

> - Head comment: The philosophy is now that everything is denied in
>   terms of '<'. Comment adjusted accordingly.
>

"denied"?
"defined"!

;-)

Ulrich

Arno:

> Actually I was surprised when I found out this not well
> documented behaviour. Now it seems obvious, but having an
> implicit precondition 'same_type(other)' is not good from the
> point of view of self-documentation.

Yes, right. Thinking about it, it is indeed very poorly
documented for an Eiffel user (when I earlier said "well
documented" I thought about "well documented in the
research literature on type systems" which is indeed no
good for typical users). Maybe we should either as part
of ELKS or as an appendix or some form of NICE-approved
explanatory note write some user-friendly document for
ordinary users documenting the problem as it stands,
pending a solution from Bertrand/ECMA.

--
franck@...

On Tue, Nov 05, 2002 at 01:37:08PM +0000, Franck Arnaud wrote:
> Arno:
>
> > Actually I was surprised when I found out this not well
> > documented behaviour. Now it seems obvious, but having an
> > implicit precondition 'same_type(other)' is not good from the
> > point of view of self-documentation.
>
> Yes, right. Thinking about it, it is indeed very poorly
> documented for an Eiffel user (when I earlier said "well
> documented" I thought about "well documented in the
> research literature on type systems" which is indeed no
> good for typical users). Maybe we should either as part
> of ELKS or as an appendix or some form of NICE-approved
> explanatory note write some user-friendly document for
> ordinary users documenting the problem as it stands,
> pending a solution from Bertrand/ECMA.

For the moment the most current problem concerning
this is the "symmetric" postcondition on "is_equal",
which might be dealt with by modifying the signature,
we will see what the result of the discussion here is.

However as this is a general problem with "like Current"
features, having a warning, or even a precondition
"same_type" in the affected features (depends on the
individual postconditions) would be good.

Something like

    -- Note: Because of the postcondition  xyz, argument a has
    --       to be of the same type as Current.

or alternatively

    same_type: same_type(a)

to replace the run-time type error with a precondition
failure and also make it explicit.

I am not sure a document that describes this in general is
really necessary, but I feel individual warnings at the
affected features would be very helpful.

Arno
--
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
For every complex problem there is an answer that is clear, simple,
and wrong. -- H L Mencken

Dear group!

With the somewhat delayed poll result we can move on to the
next step. (Delayed because of my set-up: I was not sure
whether "close on the 7th" meant including or excluding
the day itself. Apparently it includes the day.)

There is indication that the comparison features in ANY could
benefit from more general argument types. The main advantage
would be that equality testing could be done on every pair of
objects, consistent with the (my?) intuitive semantics of
equality, namely that it is a total operation. Furthermore not so
intuitive run-time type errors would be replaced by clear
postcondition violations.

After we have dealt with this issue we will reconsider COMPARABLE
in light of the changes made to ANY. At some point we will
have to go over ANY in detail, but for the next steps, I propose
that visit ANY whenever we notice a problem when dealing with
other classes.

The current version of ANY seems to be the draft ELKS 2003
proposal (which we would update) found at
http://www.eiffel-nice.org/standards/wip/any/any2003proposal.html

(Roger: Can I get access to these pages, so I can update and
  add what is being voted on here?)

----------------
feature -- Comparison

    frozen deep_equal (some: GENERAL; other: like some): BOOLEAN
      -- Are `some' and `other' either both void
      -- or attached to isomorphic object structures?
      ensure
         shallow_implies_deep: standard_equal (some, other)
          implies Result
         same_type: Result implies some.same_type (other)
         symmetric: Result implies deep_equal (other, some)

    frozen equal (some: GENERAL; other: like some): BOOLEAN
      -- Are `some' and `other' either both void or attached
      -- to objects considered equal?
      ensure
         definition: Result = (some = Void and other = Void) or
          else ((some /= Void and other /= Void) and then
          some.is_equal (other))

   is_equal (other: like Current): BOOLEAN
      -- Is `other' attached to an object considered equal
      -- to current object?
      require
         other_not_void: other /= Void
      ensure
         consistent: standard_is_equal (other) implies Result
         same_type: Result implies same_type (other)
         symmetric: Result implies other.is_equal (Current)

    frozen standard_equal (some: GENERAL; other: like some): BOOLEAN
      -- Are `some' and `other' either both void or attached to
      -- field-by-field identical objects of the same type?
      -- Always uses the default object comparison criterion.
      ensure
         definition: Result = (some = Void and other = Void) or
          else ((some /= Void and other /= Void) and then
          some.standard_is_equal (other))

    frozen standard_is_equal (other: like Current): BOOLEAN
      -- Is `other' attached to an object of the same type as
      -- current object, and field-by-field identical to it?
      require
         other_not_void: other /= Void
      ensure
         same_type: Result implies same_type (other)
         symmetric: Result implies other.standard_is_equal (Current)

----------------

The basic, most general definition of equality is embodied by
"standard_is_equal". "is_equal" might be more specific, but things
classified as equal by "is_equal" always have to be equal by
"standard_is_equal" too. So the first step is to refine
"standard_is_equal", and then "is_equal". "standard_equal" and
"equal" are just derived from the other two features and
do not carry different semantics, just a different signature.
I think for this discussion "deep_equal" can be treaded mostly like
"equal".

The first refinement step could be (signature not yet changed):

   frozen standard_is_equal (other: like Current): BOOLEAN
         -- Is other attached to an object of the same type as
         -- current object, and field-by-field identical to it?
     require
         other_not_void: other /= Void
     ensure
         same_type: Result implies same_type (other)
         symmetric: (Result and same_type (other)) implies
                    other.standard_is_equal (Current)

The postcondition basically has the original semantics, but a
call with an argument that is a child of "Current" together with a
faulty implementation will not result in a run-time type error when
the second postcondition is checked. Instead it will result
in the first postcondition failing, even when the second condition
is checked first. Since "standard_is_equal" is frozen, it is
not really an issue here, but the same argument applies to
"is_equal" which can be redefined.


If the argument type is generalized to ANY, it becomes
simpler again:

   frozen standard_is_equal (other: ANY): BOOLEAN
         -- Is `other' attached to an object of the same type as
         -- `Current', and field-by-field identical to it?
     require
         other_not_void: other /= Void
     ensure
         same_type: Result implies same_type (other)
         symmetric: Result implies other.standard_is_equal (Current)

since "symmetric" now has a defined value in case of different
types for "Current" and "other".


Now for "is_equal":

is_equal (other: ANY): BOOLEAN
         -- Is `other' attached to an object of same type as
         -- `Current' and considered equal to `Current'?
     require
         other_not_void: other /= Void
     ensure
         consistent: standard_is_equal (other) implies Result
         same_type: Result implies same_type (other)
         symmetric: Result implies other.is_equal (Current)

No problem with the more general argument. A wrong
implementation can fail on "same_type" or "symmetric", but
not with a run-time type error.


"standard_equal" and "equal" do not change, except that
the arguments would both be changed to type "ANY".
"deep_equal" seems to be problematic in general, but
I think we could just adjust the signature accordingly
without getting into trouble.


From the point of view of the semantics, not much would
change. The proposed versions ensure postcondition violation
on wrong implementations instead of type errors. Furthermore
a Result of "false" for all calls with different argument
types is ensured, again instead of type errors.

All in all more general arguments are allowed, but add no
cases where the result is "true". All the additionally
allowed arguments caused run-time or compile-time type
errors before. My intuition is that this makes the impact
on existing software unproblematic.

Please discuss!

Regards,
Arno

--
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
For every complex problem there is an answer that is clear, simple,
and wrong. -- H L Mencken

Arno Wagner wrote:
>
> The first refinement step could be (signature not yet changed):
>
>   frozen standard_is_equal (other: like Current): BOOLEAN
>         -- Is other attached to an object of the same type as
>         -- current object, and field-by-field identical to it?
>     require
>         other_not_void: other /= Void
>     ensure
>         same_type: Result implies same_type (other)
>         symmetric: (Result and same_type (other)) implies
>                    other.standard_is_equal (Current)
>
> The postcondition basically has the original semantics, but a
> call with an argument that is a child of "Current" together with a
> faulty implementation will not result in a run-time type error when
> the second postcondition is checked. Instead it will result
> in the first postcondition failing, even when the second condition
> is checked first.

According to ETL2 page 120, the assertions are checked in the
order they appear in the class text, and their semantics is as
if they were separated by "and then". Therefore adding `same_type'
in the "symmetric" assertion is technically useless and the
postcondition is equivalent to this simpler one:

   same_type: Result implies same_type (other)
   symmetric: Result implies other.standard_is_equal (Current)

which as a matter of fact is nothing else than the original
version.

--
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com


__________________________________________________
Modem offert : 150,92 euros remboursés sur le Pack eXtense de Wanadoo !
Haut débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w

On Fri, Nov 08, 2002 at 02:34:30PM +0100, Eric Bezault wrote:
> Arno Wagner wrote:
> >
> > The first refinement step could be (signature not yet changed):
> >
> >   frozen standard_is_equal (other: like Current): BOOLEAN
> >         -- Is other attached to an object of the same type as
> >         -- current object, and field-by-field identical to it?
> >     require
> >         other_not_void: other /= Void
> >     ensure
> >         same_type: Result implies same_type (other)
> >         symmetric: (Result and same_type (other)) implies
> >                    other.standard_is_equal (Current)
> >
> > The postcondition basically has the original semantics, but a
> > call with an argument that is a child of "Current" together with a
> > faulty implementation will not result in a run-time type error when
> > the second postcondition is checked. Instead it will result
> > in the first postcondition failing, even when the second condition
> > is checked first.
>
> According to ETL2 page 120, the assertions are checked in the
> order they appear in the class text, and their semantics is as
> if they were separated by "and then".

I did not find that. O.k., so that is not a problem.
My true proposal is further down in the text.

However this is important to keep in mind, as this group has
just (provisionaly) accepted a version of COMPARABLE where
the postconditions of "is_equal" are not in the same order
as in ANY. Something to fix when we return to COMPARABLE and
to be careful about in the future.

Was this also in ETL 1 or is this new?

> Therefore adding `same_type'
> in the "symmetric" assertion is technically useless and the
> postcondition is equivalent to this simpler one:
>
>   same_type: Result implies same_type (other)
>   symmetric: Result implies other.standard_is_equal (Current)
>
> which as a matter of fact is nothing else than the original
> version.

Indeed. Same when the argument is generalizeed to ANY, only then
postcondition order does not matter anymore.

regards,
Arno

--
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
For every complex problem there is an answer that is clear, simple,
and wrong. -- H L Mencken

Arno Wagner wrote:
>
> Was this also in ETL 1 or is this new?

ETL1 and ETL2 are mostly the same (published in 1991 and 1992).
You might be confused by ETL3, which is still a work in progress
by BM and ECMA.

--
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

__________________________________________________
Modem offert : 150,92 euros remboursés sur le Pack eXtense de Wanadoo !
Haut débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w

Arno Wagner wrote:
>
> My true proposal is further down in the text.

Yes, I understood that, I just wanted to correct this imprecision
in your reasoning, but your proposal is still valid.

--
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

__________________________________________________
Modem offert : 150,92 euros remboursés sur le Pack eXtense de Wanadoo !
Haut débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w

On Fri, Nov 08, 2002 at 03:14:07PM +0100, Eric Bezault wrote:
> Arno Wagner wrote:
> >
> > Was this also in ETL 1 or is this new?
>
> ETL1 and ETL2 are mostly the same (published in 1991 and 1992).
> You might be confused by ETL3, which is still a work in progress
> by BM and ECMA.

Indeed, I am. Sorry.

O.k., close attention to postcondition order in the future.

Arno

--
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
For every complex problem there is an answer that is clear, simple,
and wrong. -- H L Mencken

On Fri, Nov 08, 2002 at 03:17:30PM +0100, Eric Bezault wrote:
> Arno Wagner wrote:
> >
> > My true proposal is further down in the text.
>
> Yes, I understood that, I just wanted to correct this imprecision
> in your reasoning, but your proposal is still valid.

You where perfectly right. Otherwise I would still be ignorant
about the significance of postcondition order.

Since I am the person that found ETL "boring and hard to read"
(some discussion here last year), I need this kind of help ;-)

Arno

--
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
For every complex problem there is an answer that is clear, simple,
and wrong. -- H L Mencken