certified attachment pattern and assertions

24 Messages Forum Options Options
Permalink
1 2
Helmut Brandl
certified attachment pattern and assertions
Reply Threaded More
Print post
Permalink
The ECMA standard defines

some_routine(a: ?A)
    require a /= Void
    do  
        a.some_feature
        ...
    end

as a certified attachment pattern for a. I.e. in the body of the routine
it can be safely assumed, that the argument a is attached to an object
of type A.

What happens, if precondition monitoring is not activated? Are void
calls only eradicated if assertion monitoring is on?

Helmut

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

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: certified attachment pattern and assertions
Reply Threaded More
Print post
Permalink
Helmut Brandl wrote:
>
> What happens, if precondition monitoring is not activated? Are void
> calls only eradicated if assertion monitoring is on?

Assertion monitoring occurs at run time.

Void-safety validity checks occur at compile time.

I don't see why turning off assertion monitoring would influence
void-safety.

- 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: certified attachment pattern and assertions
Reply Threaded More
Print post
Permalink
Peter,

the example I gave will pass the compiler validity checks, because it is
a certified attachment pattern. But nothing no validity rule will
inhibit, that I call the routine with a void target. E.g. the following
will pass the validity checks, but produce a call on a void target:

class B feature

        some_routine(a: ?A)
    require a /= Void
    do  
        a.some_feature
        ...
    end
...
end

class ROOT create make feature
        make
                local
                        v: ?A
                        b: B
                do
                        create b
                        b.some_routine(v)
                end
end

Do you get my point. The feature "b.some_routine(v)" will call
"a.some_feature" with a void targe a. This call on void target will only
be detected at runtime, if assertion (in this case precondition)
monitoring is on.

Helmut

Peter Gummer wrote:

> Helmut Brandl wrote:
>  
>> What happens, if precondition monitoring is not activated? Are void
>> calls only eradicated if assertion monitoring is on?
>>    
>
> Assertion monitoring occurs at run time.
>
> Void-safety validity checks occur at compile time.
>
> I don't see why turning off assertion monitoring would influence
> void-safety.
>
> - Peter Gummer
>
>
>
> ------------------------------------
>
> 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/

ardjussi
Re: certified attachment pattern and assertions
Reply Threaded More
Print post
Permalink
--- In eiffel_software@..., Helmut Brandl
<helmut.brandl@...> wrote:
>
> Peter,
>
> the example I gave will pass the compiler validity checks, because
it is
> a certified attachment pattern. But nothing no validity rule will
> inhibit, that I call the routine with a void target. E.g. the
following

> will pass the validity checks, but produce a call on a void target:
>
> class B feature
>
> some_routine(a: ?A)
>     require a /= Void
>     do  
>         a.some_feature
>         ...
>     end
> ...
> end
>
> class ROOT create make feature
> make
> local
> v: ?A
> b: B
> do
> create b
> b.some_routine(v)
> end
> end
>
> Do you get my point. The feature "b.some_routine(v)" will call
> "a.some_feature" with a void targe a. This call on void target will
only
> be detected at runtime, if assertion (in this case precondition)
> monitoring is on.

In pre-voidsafe Eiffel the result was a void target exception.
Voidsafe Eiffel differs here by emitting a precondition exception,
not void target exception. Reason is void target, but exception is
precondition violation, thus no void target exceptions. No?

br Jussi
>
> Helmut
>
> Peter Gummer wrote:
> > Helmut Brandl wrote:
> >  
> >> What happens, if precondition monitoring is not activated? Are
void

> >> calls only eradicated if assertion monitoring is on?
> >>    
> >
> > Assertion monitoring occurs at run time.
> >
> > Void-safety validity checks occur at compile time.
> >
> > I don't see why turning off assertion monitoring would influence
> > void-safety.
> >
> > - Peter Gummer
> >
> >
> >
> > ------------------------------------
> >
> > 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/

Helmut Brandl
Re: Re: certified attachment pattern and assertions
Reply Threaded More
Print post
Permalink
But  what, if precondition monitoring is not switched on? How will you
get a precondition exception if monitoring is not switched on?

Helmut

ardjussi wrote:

> --- In eiffel_software@..., Helmut Brandl
> <helmut.brandl@...> wrote:
>  
>> Peter,
>>
>> the example I gave will pass the compiler validity checks, because
>>    
> it is
>  
>> a certified attachment pattern. But nothing no validity rule will
>> inhibit, that I call the routine with a void target. E.g. the
>>    
> following
>  
>> will pass the validity checks, but produce a call on a void target:
>>
>> class B feature
>>
>> some_routine(a: ?A)
>>     require a /= Void
>>     do  
>>         a.some_feature
>>         ...
>>     end
>> ...
>> end
>>
>> class ROOT create make feature
>> make
>> local
>> v: ?A
>> b: B
>> do
>> create b
>> b.some_routine(v)
>> end
>> end
>>
>> Do you get my point. The feature "b.some_routine(v)" will call
>> "a.some_feature" with a void targe a. This call on void target will
>>    
> only
>  
>> be detected at runtime, if assertion (in this case precondition)
>> monitoring is on.
>>    
>
> In pre-voidsafe Eiffel the result was a void target exception.
> Voidsafe Eiffel differs here by emitting a precondition exception,
> not void target exception. Reason is void target, but exception is
> precondition violation, thus no void target exceptions. No?
>
> br Jussi
>  
>> Helmut
>>
>> Peter Gummer wrote:
>>    
>>> Helmut Brandl wrote:
>>>  
>>>      
>>>> What happens, if precondition monitoring is not activated? Are
>>>>        
> void
>  
>>>> calls only eradicated if assertion monitoring is on?
>>>>    
>>>>        
>>> Assertion monitoring occurs at run time.
>>>
>>> Void-safety validity checks occur at compile time.
>>>
>>> I don't see why turning off assertion monitoring would influence
>>> void-safety.
>>>
>>> - Peter Gummer
>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>      
>
>
>
> ------------------------------------
>
> 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/

ardjussi
Re: certified attachment pattern and assertions
Reply Threaded More
Print post
Permalink
--- In eiffel_software@..., Helmut Brandl
<helmut.brandl@...> wrote:
>
> But  what, if precondition monitoring is not switched on? How will
you
> get a precondition exception if monitoring is not switched on?

This is how the compiler works on this CAP: void target detection
fakes by emitting precondition violation exception. Notice that there
is no detection of precondition violation. This is an exception
situation anyway, but there does not appear a VOID TARGET exception.
Thus voidsafe...

br Jussi

>
> Helmut
>
> ardjussi wrote:
> > --- In eiffel_software@..., Helmut Brandl
> > <helmut.brandl@> wrote:
> >  
> >> Peter,
> >>
> >> the example I gave will pass the compiler validity checks,
because
> >>    
> > it is
> >  
> >> a certified attachment pattern. But nothing no validity rule
will
> >> inhibit, that I call the routine with a void target. E.g. the
> >>    
> > following
> >  
> >> will pass the validity checks, but produce a call on a void
target:

> >>
> >> class B feature
> >>
> >> some_routine(a: ?A)
> >>     require a /= Void
> >>     do  
> >>         a.some_feature
> >>         ...
> >>     end
> >> ...
> >> end
> >>
> >> class ROOT create make feature
> >> make
> >> local
> >> v: ?A
> >> b: B
> >> do
> >> create b
> >> b.some_routine(v)
> >> end
> >> end
> >>
> >> Do you get my point. The feature "b.some_routine(v)" will call
> >> "a.some_feature" with a void targe a. This call on void target
will
> >>    
> > only
> >  
> >> be detected at runtime, if assertion (in this case precondition)
> >> monitoring is on.
> >>    
> >
> > In pre-voidsafe Eiffel the result was a void target exception.
> > Voidsafe Eiffel differs here by emitting a precondition
exception,
> > not void target exception. Reason is void target, but exception
is

> > precondition violation, thus no void target exceptions. No?
> >
> > br Jussi
> >  
> >> Helmut
> >>
> >> Peter Gummer wrote:
> >>    
> >>> Helmut Brandl wrote:
> >>>  
> >>>      
> >>>> What happens, if precondition monitoring is not activated? Are
> >>>>        
> > void
> >  
> >>>> calls only eradicated if assertion monitoring is on?
> >>>>    
> >>>>        
> >>> Assertion monitoring occurs at run time.
> >>>
> >>> Void-safety validity checks occur at compile time.
> >>>
> >>> I don't see why turning off assertion monitoring would
influence

> >>> void-safety.
> >>>
> >>> - Peter Gummer
> >>>
> >>>
> >>>
> >>> ------------------------------------
> >>>
> >>> Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>>
> >>>      
> >
> >
> >
> > ------------------------------------
> >
> > 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/

Helmut Brandl
Re: Re: certified attachment pattern and assertions
Reply Threaded More
Print post
Permalink
OK. Got your point at least in principle.

However, the void target can be encountered much further down in the
call stack. How is the correlation to the violated precondition done?
The precondition exception might be very confusing, if the void target
is encountered far away. But I understand, that it can work the way you
described.

This gives me another issue. The CAP could be done by an object test
local also. e.g.

class B feature

        some_routine(a: ?A)
    require {o:A}
    do  
        o.some_feature
        ...
    end
...
end

class ROOT create make feature
        make
                local
                        v: ?A
                        b: B
                do
                        create b
                        b.some_routine(v)
                end
end


Now the object test local will not get initialized, if precondition
monitoring is switched off. So you will get a void target even if the
target is attached? (assertion with side effect).


ardjussi wrote:

> --- In eiffel_software@..., Helmut Brandl
> <helmut.brandl@...> wrote:
>  
>> But  what, if precondition monitoring is not switched on? How will
>>    
> you
>  
>> get a precondition exception if monitoring is not switched on?
>>    
>
> This is how the compiler works on this CAP: void target detection
> fakes by emitting precondition violation exception. Notice that there
> is no detection of precondition violation. This is an exception
> situation anyway, but there does not appear a VOID TARGET exception.
> Thus voidsafe...
>
> br Jussi
>  
>> Helmut
>>
>> ardjussi wrote:
>>    
>>> --- In eiffel_software@..., Helmut Brandl
>>> <helmut.brandl@> wrote:
>>>  
>>>      
>>>> Peter,
>>>>
>>>> the example I gave will pass the compiler validity checks,
>>>>        
> because
>  
>>>>    
>>>>        
>>> it is
>>>  
>>>      
>>>> a certified attachment pattern. But nothing no validity rule
>>>>        
> will
>  
>>>> inhibit, that I call the routine with a void target. E.g. the
>>>>    
>>>>        
>>> following
>>>  
>>>      
>>>> will pass the validity checks, but produce a call on a void
>>>>        
> target:
>  
>>>> class B feature
>>>>
>>>> some_routine(a: ?A)
>>>>     require a /= Void
>>>>     do  
>>>>         a.some_feature
>>>>         ...
>>>>     end
>>>> ...
>>>> end
>>>>
>>>> class ROOT create make feature
>>>> make
>>>> local
>>>> v: ?A
>>>> b: B
>>>> do
>>>> create b
>>>> b.some_routine(v)
>>>> end
>>>> end
>>>>
>>>> Do you get my point. The feature "b.some_routine(v)" will call
>>>> "a.some_feature" with a void targe a. This call on void target
>>>>        
> will
>  
>>>>    
>>>>        
>>> only
>>>  
>>>      
>>>> be detected at runtime, if assertion (in this case precondition)
>>>> monitoring is on.
>>>>    
>>>>        
>>> In pre-voidsafe Eiffel the result was a void target exception.
>>> Voidsafe Eiffel differs here by emitting a precondition
>>>      
> exception,
>  
>>> not void target exception. Reason is void target, but exception
>>>      
> is
>  
>>> precondition violation, thus no void target exceptions. No?
>>>
>>> br Jussi
>>>  
>>>      
>>>> Helmut
>>>>
>>>> Peter Gummer wrote:
>>>>    
>>>>        
>>>>> Helmut Brandl wrote:
>>>>>  
>>>>>      
>>>>>          
>>>>>> What happens, if precondition monitoring is not activated? Are
>>>>>>        
>>>>>>            
>>> void
>>>  
>>>      
>>>>>> calls only eradicated if assertion monitoring is on?
>>>>>>    
>>>>>>        
>>>>>>            
>>>>> Assertion monitoring occurs at run time.
>>>>>
>>>>> Void-safety validity checks occur at compile time.
>>>>>
>>>>> I don't see why turning off assertion monitoring would
>>>>>          
> influence
>  
>>>>> void-safety.
>>>>>
>>>>> - Peter Gummer
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------
>>>>>
>>>>> Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>      
>>>>>          
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>      
>
>
>
> ------------------------------------
>
> 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/

Peter Gummer-2
Re: certified attachment pattern and assertions
Reply Threaded More
Print post
Permalink
In reply to this post by Helmut Brandl
Helmut Brandl wrote:
>
> the example I gave will pass the compiler validity checks, because it is
> a certified attachment pattern. But nothing no validity rule will
> inhibit, that I call the routine with a void target. ...
> Do you get my point. The feature "b.some_routine(v)" will call
> "a.some_feature" with a void targe a. This call on void target will only
> be detected at runtime, if assertion (in this case precondition)
> monitoring is on.

Sure, that's normal design by contract as we've always known it. If
precondition checking is enabled, then at run time you get a precondition
violation; else if preconditions are discarded, then at run time you get a
void target call. Either way, it's a bug detected at run time; the
precondition violation just catches the bug earlier and more explicitly, and
is therefore easier to fix. (Although Jussi in a later email has indicated
that ECMA specifies that the latter case should also raise some kind of
precondition violation, rather than the old familiar void target call
exception, it doesn't really change the fact that both cases result in
run-time errors.)

If you use a detachable entity in void-safe Eiffel, then my understanding is
that such an entity is not void-safe. That entity suffers the same risk of
run-time exceptions that we have been used to forever in non-void-safe
Eiffel. Void-safety is a compile-time characteristic, applicable only to
attached types, isn't it?

- 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: certified attachment pattern and assertions
Reply Threaded More
Print post
Permalink
I wrote:
>
> If you use a detachable entity in void-safe Eiffel, then my understanding
> is
> that such an entity is not void-safe. That entity suffers the same risk of
> run-time exceptions that we have been used to forever in non-void-safe
> Eiffel. Void-safety is a compile-time characteristic, applicable only to
> attached types, isn't it?

I failed to mention that Certified Attachment Patterns can endow detachable
entities with a degree of void-safety.

I think I understand now what is bothering you, Helmut. You are worried by
the fact that not all CAPs endow void-safety.

One day, when we've turned on the void-safety switch in all of our projects,
I imagine that assertions that check for void will become "code smells":
examples of bad code that will set alarm bells ringing in the heads of
experienced Eiffel programmers, because we'll have learned that each such
assertion carries with it the possibility of a run-time exception, a risk
that might be avoided by refactoring the relevant classes to used attached
types. Gradually, use of this CAP will fade away from well-written Eiffel
code.

- 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: certified attachment pattern and assertions
Reply Threaded More
Print post
Permalink
In reply to this post by Peter Gummer-2

> If you use a detachable entity in void-safe Eiffel, then my understanding is
> that such an entity is not void-safe. That entity suffers the same risk of
> run-time exceptions that we have been used to forever in non-void-safe
> Eiffel. Void-safety is a compile-time characteristic, applicable only to
> attached types, isn't it?
>
> - Peter Gummer
>
>  
 From what you said it follows that neither detachable types nor
attached types are void safe. By using "require a /= Void ..." or check
"a /= Void", the compiler seem to trust you. From now on the entity a of
detachable type is converted to an attached type (like a type cast in
C/C++) and you can pass it to another routine as an attached type
object. In this other routine the type of the corresponding argument is
attached (but it is still a void reference).

Farewell void safety ....  :-(

I don't want to be negative. I am convinced that attached types are a
great invention. But lets try to understand clearly what they achieve
and what they don't. 100% void safety is *not* achieved by attached
types. It is a slight exaggeration, if the ECMA standard promises
"eradicating void calls". CAPs based on assertions can give you a false
illusion. Therefore I like your expression of "code smells".

I admit, that my examples don't reflect the common use. However extreme
examples help to understand the nitty gritties.


Regards
Helmut


P.S.: I was hoping, that the compiler could use CAPs to eliminate void
target checks and improve the runtime performance. If it did, ....
segmentation fault might happen.


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

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: certified attachment pattern and assertions
Reply Threaded More
Print post
Permalink
Helmut Brandl wrote:
> ... By using "require a /= Void ..." or check
> "a /= Void", the compiler seem to trust you. From now on the entity a of
> detachable type is converted to an attached type (like a type cast in
> C/C++) and you can pass it to another routine as an attached type
> object. In this other routine the type of the corresponding argument is
> attached (but it is still a void reference).

Ok, Helmut, I see what you're getting at.

Maybe ECMA Eiffel should disallow such "/= Void" assertions. Off the top of
my head, I can't think of any reason why you would write this:

    f (a: ?X) require a /= Void

Rather than this:

    f (a: X)
        -- equivalent to f (a:!X) in a non-void-safe system

Similarly, it's hard to imagine why anyone in the future would write "ensure
Result /= Void" instead of just declaring the function with an attached
type.

Modifying existing routines to be void-safe is sometimes difficult,
especially with routine arguments, although eradicating "ensure Result /=
Void" is usually very easy. Those of us who have tried have already
discovered this. Because of this, EiffelStudio would not want to treat such
assertions as errors yet -- possibly not until long into the future, and
even then it would have to be a project option. But it might be useful to
have a project option to treat them as warnings. Maybe several options would
be good, one for each kind of assertion.

- 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/

Colin LeMahieu
Re: certified attachment pattern and assertions
Reply Threaded More
Print post
Permalink
In reply to this post by Helmut Brandl
You are right, this would not ensure void safety at runtime.

I would wager that this CAP will be removed eventually.

The old way to ensure void safety was to use the precondition:
variable /= void

The new way to ensure void safety is to use attachment semantics.

More than likely this CAP was made to bridge old-ways to new-ways.
Without having to instantly modify existing code since most existing
code has been tested thoroughly already.

--- In eiffel_software@..., Helmut Brandl
<helmut.brandl@...> wrote:

>
> The ECMA standard defines
>
> some_routine(a: ?A)
>     require a /= Void
>     do  
>         a.some_feature
>         ...
>     end
>
> as a certified attachment pattern for a. I.e. in the body of the
routine
> it can be safely assumed, that the argument a is attached to an object
> of type A.
>
> What happens, if precondition monitoring is not activated? Are void
> calls only eradicated if assertion monitoring is on?
>
> Helmut
>



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

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: certified attachment pattern and assertions
Reply Threaded More
Print post
Permalink
In reply to this post by Peter Gummer-2

> Maybe ECMA Eiffel should disallow such "/= Void" assertions. Off the top of
>
>  
If I get your point right you are saying that assertion based CAPs are
just a transitional vehicle.

I agree, that without using assertion based CAPs, Eiffel programs can be
100% void safe. But I am not so shure that it is really possible to
"eradicate" assertion based CAPs. If I get my reservations more precise,
I will post another message.


Helmut

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

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/

Nguyen Thi Mai Trang
error - EiffelStudio 6.2
Reply Threaded More
Print post
Permalink
In reply to this post by Colin LeMahieu
Hello,

I'm a novice to Eiffel. I installed EiffelStudio 6.2 (GPL) under Windows
Vista to try the first Eiffel program which should only print out "Hello
world!".

After successfully compiling the project by pressing F7, I cannot run
the program by pressing F5. An EiffelStudio warning "You must compile a
project first.".

Have you ever encounter this problem? Could you give me some hints? Thanks.

Best regards,
Mai Trang


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

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: error - EiffelStudio 6.2
Reply Threaded More