gobo-eiffel-develop

[gobo-eiffel-develop] Bug in GEC ?

[Wolfgang J. <wj...@so...>]

Hi Eric,

lets consider the program splitter

   p1 := $ref_attr
   p2 := $int_attr

where `p1',`p2' are POINTERS, `ref_attr' is
an attribute of a reference type,
and `int_attr' is an INTEGER attribute.

The effect is that `p2' is set with the address
of `int_attr' within `Current'. But `p1' is not
set with the address of `ref_attr', instead `p1'
is set with the value of `ref_attr' itself.

Is this a bug, or did I misunderstand the
definition of the `$' operator ?

WJ

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Bug in GEC ?

[Howard T. <how...@di...>]

Hi Wolfgang and Eric,

According to ETL, the '$' operator applied to a non-constant feature should 
provide its POINTER address, such that when the pointer is passed to an 
external routine, that routine can modify the feature, probably returning a 
previously supplied value.

Unfortunately, EiffelStudio (I think) does not follow ETL and uses, for a 
reference feature, the '$' operator as an equivalent of SmartEiffel's 
to_external concept to return the POINTER equivalent of the address of the 
referred-to object, which is what Eric has implemented to be compatible with 
ES -- which in my opionion is a pain for both implementations.

Eric will no doubt expound on it.

Just my .0.2c ...

Howard

On Thursday 09 August 2007 15:40, Wolfgang Jansen wrote:
> Hi Eric,
>
> lets consider the program splitter
>
>    p1 := $ref_attr
>    p2 := $int_attr
>
> where `p1',`p2' are POINTERS, `ref_attr' is
> an attribute of a reference type,
> and `int_attr' is an INTEGER attribute.
>
> The effect is that `p2' is set with the address
> of `int_attr' within `Current'. But `p1' is not
> set with the address of `ref_attr', instead `p1'
> is set with the value of `ref_attr' itself.
>
> Is this a bug, or did I misunderstand the
> definition of the `$' operator ?
>
> WJ

-- 
Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

Re: [gobo-eiffel-develop] Bug in GEC ?

[Wolfgang J. <wj...@so...>]

Howard Thomson wrote:
> Hi Wolfgang and Eric,
>
> According to ETL, the '$' operator applied to a non-constant feature should 
> provide its POINTER address, such that when the pointer is passed to an 
> external routine, that routine can modify the feature, probably returning a 
> previously supplied value.
>
> Unfortunately, EiffelStudio (I think) does not follow ETL and uses, for a 
> reference feature, the '$' operator as an equivalent of SmartEiffel's 
> to_external concept to return the POINTER equivalent of the address of the 
> referred-to object, which is what Eric has implemented to be compatible with 
> ES -- which in my opionion is a pain for both implementations.
>
> Eric will no doubt expound on it.
>
> Just my .0.2c ...
>
> Howard
>
> On Thursday 09 August 2007 15:40, Wolfgang Jansen wrote:
>   
>> Hi Eric,
>>
>> lets consider the program splitter
>>
>>    p1 := $ref_attr
>>    p2 := $int_attr
>>
>> where `p1',`p2' are POINTERS, `ref_attr' is
>> an attribute of a reference type,
>> and `int_attr' is an INTEGER attribute.
>>
>> The effect is that `p2' is set with the address
>> of `int_attr' within `Current'. But `p1' is not
>> set with the address of `ref_attr', instead `p1'
>> is set with the value of `ref_attr' itself.
>>
>> Is this a bug, or did I misunderstand the
>> definition of the `$' operator ?
>>
>> WJ
>>     
>
>   
Thanks for clarifying the point.
So, I will have to live with it.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Bug in GEC ?

[Eric B. <er...@go...>]

Howard Thomson wrote:
> Hi Wolfgang and Eric,
> 
> According to ETL, the '$' operator applied to a non-constant feature should 
> provide its POINTER address, such that when the pointer is passed to an 
> external routine, that routine can modify the feature, probably returning a 
> previously supplied value.
> 
> Unfortunately, EiffelStudio (I think) does not follow ETL and uses, for a 
> reference feature, the '$' operator as an equivalent of SmartEiffel's 
> to_external concept to return the POINTER equivalent of the address of the 
> referred-to object, which is what Eric has implemented to be compatible with 
> ES 

Yes. I think that the idea is that $ does not return the
address of the attribute entity in the enclosing object,
but the address of the attribute object. So if the attribute
is expanded, the address of the object is indeed the same
as the address of the attribute entity in the enclosing
object. But for reference attributes, the address of the
object is what is stored in the attribute entity. So, in
a sense it is consistent between expanded and reference.
It's just that it is returning the address of the attribute
object and not the address of the attribute entity.

I think that ISE gives access to the attribute entity
address through its class INTERNAL. Because I want to
implement features of INTERNAL in terms of features of
class TYPE, I think that I will make this functionality
available in class TYPE.

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

Re: [gobo-eiffel-develop] Bug in GEC ?

[Wolfgang J. <wj...@so...>]

Eric Bezault wrote:
> Howard Thomson wrote:
>   
>> Hi Wolfgang and Eric,
>>
>> According to ETL, the '$' operator applied to a non-constant feature should 
>> provide its POINTER address, such that when the pointer is passed to an 
>> external routine, that routine can modify the feature, probably returning a 
>> previously supplied value.
>>
>> Unfortunately, EiffelStudio (I think) does not follow ETL and uses, for a 
>> reference feature, the '$' operator as an equivalent of SmartEiffel's 
>> to_external concept to return the POINTER equivalent of the address of the 
>> referred-to object, which is what Eric has implemented to be compatible with 
>> ES 
>>     
>
> Yes. I think that the idea is that $ does not return the
> address of the attribute entity in the enclosing object,
> but the address of the attribute object. So if the attribute
> is expanded, the address of the object is indeed the same
> as the address of the attribute entity in the enclosing
> object. But for reference attributes, the address of the
> object is what is stored in the attribute entity. So, in
> a sense it is consistent between expanded and reference.
> It's just that it is returning the address of the attribute
> object and not the address of the attribute entity.
>
> I think that ISE gives access to the attribute entity
> address through its class INTERNAL. Because I want to
> implement features of INTERNAL in terms of features of
> class TYPE, I think that I will make this functionality
> available in class TYPE.
>
>   
Hmm, besides the definition of `$' there is another
argument in favour of the address of the entity.
If `$' yields the entity address then
the object address can be obtained via C code
    *(void**)addr
The other way around, obtaining the entity address
from the object address is not possible.
Thus, the entity address carries more information.

The unreferencing might be done by a feature of TYPE,
but how can the reverse operation be accomplished?
I do not know ISE's INTERNAL class very well
but I doubt that there is a function that yields
the entity address of a given reference object:
the best what the function can do is to return
the address of the object (as function argument) on stack.
This is quite meaningless after returning from
the function.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Bug in GEC ?

[Eric B. <er...@go...>]

Wolfgang Jansen wrote:
> Hmm, besides the definition of `$' there is another
> argument in favour of the address of the entity.
> If `$' yields the entity address then
> the object address can be obtained via C code
>    *(void**)addr

Not if the attribute is expanded.

> The other way around, obtaining the entity address
> from the object address is not possible.
> Thus, the entity address carries more information.

I think that we need both forms.

> The unreferencing might be done by a feature of TYPE,
> but how can the reverse operation be accomplished?
> I do not know ISE's INTERNAL class very well
> but I doubt that there is a function that yields
> the entity address of a given reference object:

I want the entity address of the attribute "foo"
in object `x':

    $x + internal.field_offset (i, x)

where `i' is the index of the attribute `foo' in `x'
(`i' can be computed by other means in INTERNAL).
I agree that it ought to be easier to get this information
(with less computation), but it is possible to get it.

Anyway, as Howard mentioned, the goal of Gobo is not to make
things better but to be compatible with ISE.

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