Eiffel

›

standardization of ELKS

54 Messages

1 2 3

Helmut Brandl

standardization of ELKS

Reply Threaded

Does anybody know if there is an effort to standardize the kernel
library? If "yes", what is the status?

Regards
Helmut Brandl

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Bernd Schoeller

Re: standardization of ELKS

Reply Threaded

On Sun, 15 Jun 2008 17:40:24 -0000, Helmut Brandl <helmut.brandl@...>
wrote:

> Does anybody know if there is an effort to standardize the kernel
> library? If "yes", what is the status?
>
> Regards
> Helmut Brandl

http://sourceforge.net/projects/freeelks

The kernel library is well maintained and is shared between the GOBO and
the EiffelStudio projects.

Bernd

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Helmut Brandl

Re: standardization of ELKS

Reply Threaded

Thanks for the response Bernd.

It is good to know, that free elks is at least maintained and compatible
between two compilers. However free elks obviously has not yet been
updated to reflect the ECMA standard. E.g. is_equal in ANY still has the
signature

is_equal ( other: like Current ): BOOLEAN

as opposed to ECMA which requires the signature

is_equal ( other: ANY ): BOOLEAN

The same applies to copy.

It exports copy to all instead of making it secret as default.

Also it still refers to INTEGER_REF, ... etc.

In order to have a real "Standard Eiffel", a specification of the kernel
library is required. Otherwise it is impossible to write Eiffel programs
which do not depend on a specific implementation of the kernel library.

Since ISE Eiffel is committed to comply to the ECMA Eiffel standard, I
would expect a roadmap to reach the goal also for the kernel library.

Or will the kernel library be a thing which depend on a specific compiler?

No standard kernel library at all? I.e. no standard Eiffel at all?

Regards
Helmut

Bernd Schoeller wrote:

> On Sun, 15 Jun 2008 17:40:24 -0000, Helmut Brandl <helmut.brandl@...>
> wrote:
>
>
>> Does anybody know if there is an effort to standardize the kernel
>> library? If "yes", what is the status?
>>
>> Regards
>> Helmut Brandl
>>
>
> http://sourceforge.net/projects/freeelks
>
> The kernel library is well maintained and is shared between the GOBO and
> the EiffelStudio projects.
>
> Bernd
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Emmanuel Stapf [ES]

RE: standardization of ELKS

Reply Threaded

> updated to reflect the ECMA standard. E.g. is_equal in ANY still has the
> signature
>
> is_equal ( other: like Current ): BOOLEAN
>
> as opposed to ECMA which requires the signature
>
> is_equal ( other: ANY ): BOOLEAN

Actually this is being revisited by ECMA and most likely it will be kept the way it is in FreeELKS. The reason being that `is_equal' should be gradually replaced by the ~ operator which ensures that the argument is of the right type.

> The same applies to copy.
> It exports copy to all instead of making it secret as default.

This is a backward compatibility issue and the goal of FreeELKS or of Eiffel Software is not to break code, so this changes will eventually be done but not right now. My guess is that we will provide 2 versions at some point of the library so that people can try to compile against the new version but still have the opportunity to use the old code as well.

> Also it still refers to INTEGER_REF, ... etc.

Those are not specified by ECMA and FreeELKS is actually free to use them. Again they are used for backward compatibility issue.

> Since ISE Eiffel is committed to comply to the ECMA Eiffel standard, I
> would expect a roadmap to reach the goal also for the kernel library.
> Or will the kernel library be a thing which depend on a specific
> compiler?
> No standard kernel library at all? I.e. no standard Eiffel at all?

The people behind FreeELKS are also in the ECMA committee and the goal of FreeELKS is that eventually it will become the ELKS standard.

Hope this helps,
Manu

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Bernd Schoeller

Re: standardization of ELKS

Reply Threaded

On Wed, 18 Jun 2008 04:04:43 -0000, Emmanuel Stapf [ES] <manus@...>
wrote:

>> is_equal ( other: ANY ): BOOLEAN
>
> Actually this is being revisited by ECMA and most likely it will be kept
> the way it is in FreeELKS. The reason being that `is_equal' should be
> gradually replaced by the ~ operator which ensures that the argument is
> of the right type.
>

If that is so: How do we treat objects that should be considered equal
even when they use different classes?

Bernd

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Helmut Brandl

Re: standardization of ELKS

Reply Threaded

Now I am a little bit astonished.

If ECMA is going to allow is_equal ( other: like Current ): BOOLEAN, it
also has to revise the feature declaration rule 8.5.25, which states
that a feature declaration is valid if and only if any anchored type for
an argument is detachable.

If this is going to happen all the stuff with catcall avoidance by
forbidding covariant redeclarations with attached types breaks down.
Remember that declaring an argument of type like Current is an implicit
covariant redeclaration.

Are you really saying this or did I get something wrong?

Regards
Helmut

Emmanuel Stapf [ES] wrote:

>> updated to reflect the ECMA standard. E.g. is_equal in ANY still has the
>> signature
>>
>> is_equal ( other: like Current ): BOOLEAN
>>
>> as opposed to ECMA which requires the signature
>>
>> is_equal ( other: ANY ): BOOLEAN
>>
>
> Actually this is being revisited by ECMA and most likely it will be kept the way it is in FreeELKS. The reason being that `is_equal' should be gradually replaced by the ~ operator which ensures that the argument is of the right type.
>
>
>> The same applies to copy.
>> It exports copy to all instead of making it secret as default.
>>
>
> This is a backward compatibility issue and the goal of FreeELKS or of Eiffel Software is not to break code, so this changes will eventually be done but not right now. My guess is that we will provide 2 versions at some point of the library so that people can try to compile against the new version but still have the opportunity to use the old code as well.
>
>
>> Also it still refers to INTEGER_REF, ... etc.
>>
>
> Those are not specified by ECMA and FreeELKS is actually free to use them. Again they are used for backward compatibility issue.
>
>
>> Since ISE Eiffel is committed to comply to the ECMA Eiffel standard, I
>> would expect a roadmap to reach the goal also for the kernel library.
>> Or will the kernel library be a thing which depend on a specific
>> compiler?
>> No standard kernel library at all? I.e. no standard Eiffel at all?
>>
>
> The people behind FreeELKS are also in the ECMA committee and the goal of FreeELKS is that eventually it will become the ELKS standard.
>
> Hope this helps,
> Manu
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Helmut Brandl

Re: standardization of ELKS

Reply Threaded

Bernd,

I think you hit the nail no the head. is_equal ( other: ANY ) : BOOLEAN
is a wise choice. It allows you to redefine is_equal for sequences with
the semantics that 2 sequences are considered equal if they contain an
equal sequence of elements, regardless of its implementation (linked or
arrayed, for example). That is, what the user would expect. Making the
argument anchored disallows that possibility.

Bernd Schoeller wrote:

> On Wed, 18 Jun 2008 04:04:43 -0000, Emmanuel Stapf [ES] <manus@...>
> wrote:
>
>
>>> is_equal ( other: ANY ): BOOLEAN
>>>
>> Actually this is being revisited by ECMA and most likely it will be kept
>> the way it is in FreeELKS. The reason being that `is_equal' should be
>> gradually replaced by the ~ operator which ensures that the argument is
>> of the right type.
>>
>>
>
> If that is so: How do we treat objects that should be considered equal
> even when they use different classes?
>
> Bernd
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Eric Bezault

Re: standardization of ELKS

Reply Threaded

Bernd Schoeller wrote:

> On Wed, 18 Jun 2008 04:04:43 -0000, Emmanuel Stapf [ES] <manus@...>
> wrote:
>
>>> is_equal ( other: ANY ): BOOLEAN
>> Actually this is being revisited by ECMA and most likely it will be kept
>> the way it is in FreeELKS. The reason being that `is_equal' should be
>> gradually replaced by the ~ operator which ensures that the argument is
>> of the right type.
>>
>
> If that is so: How do we treat objects that should be considered equal
> even when they use different classes?

What do you have in mind? What criteria would you use?
Do you consider that a point and a colored_point are equal
because they have the same coordinates? Do you consider
that a colored_point and a colored_car are equal because
they have the same color. In either case you should introduce
a feature with the expected behavior in the appropriate
class (`same_coordinates' in class POINT, `same_color'
in COLORED_OBJECT). I don't think that it is appropriate
to expect `is_equal' from ANY to capture all kinds of equality
criteria between any kind of objects. Or we should introduce
multiple dispatch in Eiffel first.

ECMA considered the change of signature of `is_equal' for the
sole purpose of avoiding numerous CAT-calls. With more experience
in that domain, it appears that the problem is not so much related
to the signature of the routine (one could explicitly redefine
the routine covariantly anyway) but more to the use of it, especially
in the EiffelBase containers.

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

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Eric Bezault

Re: standardization of ELKS

Reply Threaded

Helmut Brandl wrote:
> Bernd,
>
> I think you hit the nail no the head. is_equal ( other: ANY ) : BOOLEAN
> is a wise choice. It allows you to redefine is_equal for sequences with
> the semantics that 2 sequences are considered equal if they contain an
> equal sequence of elements, regardless of its implementation (linked or
> arrayed, for example). That is, what the user would expect. Making the
> argument anchored disallows that possibility.

I'd rather have a routine `same_items' in class SEQUENCE for that.

Also one thing that should not be forgotten is that `is_equal' is
part of the postcondition of `copy' and should define what `copy'
does.

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

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Eric Bezault

Re: standardization of ELKS

Reply Threaded

Helmut Brandl wrote:

> Now I am a little bit astonished.
>
> If ECMA is going to allow is_equal ( other: like Current ): BOOLEAN, it
> also has to revise the feature declaration rule 8.5.25, which states
> that a feature declaration is valid if and only if any anchored type for
> an argument is detachable.
>
> If this is going to happen all the stuff with catcall avoidance by
> forbidding covariant redeclarations with attached types breaks down.
> Remember that declaring an argument of type like Current is an implicit
> covariant redeclaration.

I'd be so glad if everything related to attached/detachable types
be removed from the standard. In my opinion it brings more problems
than it solves and it makes the language definition much more
complicated. And this is still a research topic, so in my opinion
it was too early to have it in the standard. We should not put
the car before the horses. We should implement and play with the
mechanism first, and then put it in the standard if it really works.
At least that's my opinion.

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

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Bernd Schoeller

Re: standardization of ELKS

Reply Threaded

On Wed, 18 Jun 2008 05:15:56 -0000, Eric Bezault <ericb@...>
wrote:

> Bernd Schoeller wrote:
> What do you have in mind? What criteria would you use?
> Do you consider that a point and a colored_point are equal
> because they have the same coordinates? Do you consider
> that a colored_point and a colored_car are equal because
> they have the same color. In either case you should introduce
> a feature with the expected behavior in the appropriate
> class (`same_coordinates' in class POINT, `same_color'
> in COLORED_OBJECT). I don't think that it is appropriate
> to expect `is_equal' from ANY to capture all kinds of equality
> criteria between any kind of objects. Or we should introduce
> multiple dispatch in Eiffel first.

For "real" object-orientation, having a universal concept of equality
beyond reference equality is plain wrong and 'is_equal' should be removed
from ANY.

But not all classes implement OO concepts. Example: STRINGs, even though
they are reference objects, are much more mathematical values than
objects. Not technically, but the way that most people see them
conceptually. Most of the time they are considered immutable. Object
identity is completely irrelevant.

As a pragmatic programming language, Eiffel supports "mathematical value
classes" by providing `is_equal' in ANY, introducing a concept of
user-defined universal equality different from reference equality. Such a
universal non-reference equality is also necessary for expanded types,
because here reference equality is not available.

Bernd

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Peter Gummer-2

Re: standardization of ELKS

Reply Threaded

Helmut Brandl wrote:
>
> If ECMA is going to allow is_equal ( other: like Current ): BOOLEAN, it
> also has to revise the feature declaration rule 8.5.25, which states
> that a feature declaration is valid if and only if any anchored type for
> an argument is detachable.

Are you assuming, Helmut, that "other: like Current" is not detachable?

(Yes, there's no detachment marker, and it arguably ought to be written as
"other: ?like Current", but I can envisage that the standard might specify
that the detachment marker is redundant in this case, given that anchored
arguments are always detachable.)

- Peter Gummer

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Peter Gummer-2

Re: standardization of ELKS

Reply Threaded

Eric Bezault wrote:
>
> I'd rather have a routine `same_items' in class SEQUENCE for that.

Is this why we already have STRING.same_string, which at first glance looks
redundant?

As far as strings are concerned, I often wish I could simply write "string1
= string2" and get expanded semantics, simply because I prefer to think of
strings as expanded, even though I know they are not. Whenever I wish this,
I regret that '=' was given different meanings for expanded and reference
types.

- Peter Gummer

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Helmut Brandl

Re: standardization of ELKS

Reply Threaded

In the current version of the standard (jun 2006) I think that "other:
like Current" is attached.

It might be possible, to revise the standard and defining that each
anchored type is detachable. But this would have other negative impacts.
If you define an attribute or local variable as anchored it would also
be detachable. Since they are not read only, you would have to write an
object test before beeing able to use them. Would you accept that?

Helmut

Peter Gummer wrote:

> Helmut Brandl wrote:
>
>> If ECMA is going to allow is_equal ( other: like Current ): BOOLEAN, it
>> also has to revise the feature declaration rule 8.5.25, which states
>> that a feature declaration is valid if and only if any anchored type for
>> an argument is detachable.
>>
>
> Are you assuming, Helmut, that "other: like Current" is not detachable?
>
> (Yes, there's no detachment marker, and it arguably ought to be written as
> "other: ?like Current", but I can envisage that the standard might specify
> that the detachment marker is redundant in this case, given that anchored
> arguments are always detachable.)
>
> - Peter Gummer
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Helmut Brandl

Re: standardization of ELKS

Reply Threaded

see below.

Eric Bezault wrote:

> Helmut Brandl wrote:
>
>> Bernd,
>>
>> I think you hit the nail no the head. is_equal ( other: ANY ) : BOOLEAN
>> is a wise choice. It allows you to redefine is_equal for sequences with
>> the semantics that 2 sequences are considered equal if they contain an
>> equal sequence of elements, regardless of its implementation (linked or
>> arrayed, for example). That is, what the user would expect. Making the
>> argument anchored disallows that possibility.
>>
>
> I'd rather have a routine `same_items' in class SEQUENCE for that.
>
> Also one thing that should not be forgotten is that `is_equal' is
> part of the postcondition of `copy' and should define what `copy'
> does.
>

Thats not a problem. copy should make is_equal true at the end. That can
be done even if you copy from one implementation of a sequence to another.

The important thing is that both sequences contain the same elements
after performing copy.

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Helmut Brandl

Re: standardization of ELKS

Reply Threaded

see below:

Eric Bezault wrote:

> Helmut Brandl wrote:
>
>> Now I am a little bit astonished.
>>
>> If ECMA is going to allow is_equal ( other: like Current ): BOOLEAN, it
>> also has to revise the feature declaration rule 8.5.25, which states
>> that a feature declaration is valid if and only if any anchored type for
>> an argument is detachable.
>>
>> If this is going to happen all the stuff with catcall avoidance by
>> forbidding covariant redeclarations with attached types breaks down.
>> Remember that declaring an argument of type like Current is an implicit
>> covariant redeclaration.
>>
>
> I'd be so glad if everything related to attached/detachable types
> be removed from the standard. In my opinion it brings more problems
> than it solves and it makes the language definition much more
> complicated. And this is still a research topic, so in my opinion
> it was too early to have it in the standard. We should not put
> the car before the horses. We should implement and play with the
> mechanism first, and then put it in the standard if it really works.
> At least that's my opinion.
>
>

In my opinion the attached/detachable types are a good and sound
concept. It has already been proven in other languages (e.g. Java has
"definitely assigned") that it works.

But I am still struggling with the effort to mix attached/detachable
types and catcall avoidance (forbidding covariant redefinition witch
attached types). In that regard I completely agree with you. It is not
yet mature enough and all consequences are not yet thought through
completely.

By the way. Catcall avoidance by forbidding covariant redefinition on
attached types solves the problem only partly. With generic types you
still can produce catcalls. I think we do not loose a lot, if we allow
covariant redefinitions with attached types and leaving the catcall
detection problem to global analysis or runtime checks. Keep in mind
that catcalls occur rather seldom. We should not make the language more
complicate in order to improve something very very marginal.

Regards
Helmut

P.S. I am convinced that it is very important for the spread of the
Eiffel language to standardize the kernel library independant of a
specific implementation. That is what C did in the seventies and look at
the success ...

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Peter Gummer-2

Re: standardization of ELKS

Reply Threaded

Helmut Brandl wrote:
>
> It might be possible, to revise the standard and defining that each
> anchored type is detachable. But this would have other negative impacts.
> If you define an attribute or local variable as anchored it would also
> be detachable. Since they are not read only, you would have to write an
> object test before beeing able to use them. Would you accept that?

Good point. No, I wouldn't like that ;-)

Perhaps ECMA should specify is_equal as:

is_equal (other: ?like Current): BOOLEAN

This is the same semantics that it already has today, so this shouldn't
break any existing client code. Even if an attached actual argument is
passed, this is compatible. What about existing redefinitions, which of
course have no marker? In non-void-safe builds, "?like Current" is the same
as "like Current", so there shouldn't be a problem. In void-safe builds,
redefinition from detachable ("?like Current") to attached ("like Current")
is tantamount to strengthening the precondition, i.e. it is covariant, so I
imagine the compiler would happily accept it in void-safe mode too.

- Peter Gummer

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

<