Recent modification in HASH_TABLE.valid_key

[Eric Bezault-4]

In feature `valid_key' from HASH_TABLE, the following line:

    create l_cell

has been recently replaced by:

    create l_cell.put (Void)

But gelint is rightly complaining that if we have a
HASH_TABLE [..., INTEGER] then we end up inserting
a Void in a cell of integer. Well, in fact I'm not
quite sure what a CELL [?INTEGER] is supposed to mean.
Anyway, would it be possible to replace that line by:

    create l_cell.put (l_default_key)

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Alexander Kogtenkov [ES]-2]

Eric Bezault wrote:

> But gelint is rightly complaining that if we have a
> HASH_TABLE [..., INTEGER] then we end up inserting
> a Void in a cell of integer. Well, in fact I'm not
> quite sure what a CELL [?INTEGER] is supposed to mean.
> Anyway, would it be possible to replace that line by:
>
>     create l_cell.put (l_default_key)

It makes perfect sense.

As to `?INTEGER', expanded types are always attached and
attachment mark cannot change this property. We could have
a rule that this is prohibited, but then we should also prohibit
`?G' for a formal generic `G', and `?like Current' as the current
class can be expanded, etc. So, for the time being it might be
easier to let the things be as they are.

Regards,
Alexander Kogtenkov

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[helmut.brandl]

Alexander Kogtenkov wrote:

> Eric Bezault wrote:
>
>  
>> But gelint is rightly complaining that if we have a
>> HASH_TABLE [..., INTEGER] then we end up inserting
>> a Void in a cell of integer. Well, in fact I'm not
>> quite sure what a CELL [?INTEGER] is supposed to mean.
>> Anyway, would it be possible to replace that line by:
>>
>>     create l_cell.put (l_default_key)
>>    
>
> It makes perfect sense.
>
> As to `?INTEGER', expanded types are always attached and
> attachment mark cannot change this property. We could have
> a rule that this is prohibited, but then we should also prohibit
> `?G' for a formal generic `G', and `?like Current' as the current
> class can be expanded, etc. So, for the time being it might be
> easier to let the things be as they are.
>
> Regards,
> Alexander Kogtenkov
>  

Hi Alexander,

the standard is not quite clear about the possibility of having
?INTEGER. But as you stated, for a formal generic or `like Current' it
is not known if it is an expanded or a reference type. Therefore the
more generic solution is to allow ?T for any type T. E.g.

local
     i: INTEGER
     di: ?INTEGER
do
     i := 6
     di := Void
     ...
     if di /= Void and then di ~ i then
          ...
     end
end

To the best of my knowledge there is no reason to forbid ?T on expanded
types T. ?T is detachable, an entity declared with type ?T is a
reference entity and can be void or attached, before use a void test or
obect test is required, ....

What is your opinion?

Regards
Helmut

The Eiffel Compiler: http://tecomp.sourceforge.net
http://www.sourceforge.net/projects/tecomp


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Alexander Kogtenkov [ES]-2]

Helmut Brandl wrote:

> ?T is detachable, an entity declared with type ?T is a
> reference entity and can be void or attached, before use a void test or
> obect test is required, ....

It means that we'll have a way to change the status of a type
from expanded to reference, like it was possible earlier with a
"reference" keyword: `t: reference T'. However the latter was
not adopted in the standard. Moreover, the previously allowed
`e: expanded T' was removed.

The rationale behind is that the expanded vs. reference semantics
is selected at the class level, because usually it involves redefinition
of `copy', `is_equal', etc. and ensures the designer that the objects
of this type are never shared.

If you mean that this is only an entity definition, where the type
is treated as a reference one, but any creation causes the expanded
object to be created, this is a possible solution, but I guess,
it would involve other changes in the language specification.

Regards,
Alexander Kogtenkov

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[helmut.brandl]

Hello Alexander,

comments see below.

A general remark:

ECMA Eiffel is a great step forward in introducing void safety to the
language. For void safety attached/detachable types are crucial. However
some details have been forgotten to think through thoroughly. One is the
issue of ?INTEGER.

If you want allow formal generics to be attached or detachable you have
to allow the '?' mark on expandeds as well, because an actual generic
can be expanded or reference. So you can have ?INTEGER implicitely anyhow.

If you can declare ?INTEGER it must be possible to assign Void to that
entity. Otherwise it would not be detachable.

Introducing expanded and reference at the class level is a good thing in
general. But attaching reference/copy semantics to the object and not to
the entity has some strange consequences. E.g.

local
   a,b: ANY
do
  a := 1
  b := a  --  has to create an new object of type INTEGER
end

This does not convince me. b:=a should attach b to the same object as a.
I don't see any bad consequences because of this, but a better
performance. Do you see any bad consequences? If yes, can you give an
example?

Regards
Helmut

The Eiffel Compiler: http://tecomp.sourceforge.net
http://www.sourceforge.net/projects/tecomp
 

Alexander Kogtenkov wrote:

> Helmut Brandl wrote:
>
>  
>> ?T is detachable, an entity declared with type ?T is a
>> reference entity and can be void or attached, before use a void test or
>> obect test is required, ....
>>    
>
> It means that we'll have a way to change the status of a type
> from expanded to reference, like it was possible earlier with a
> "reference" keyword: `t: reference T'. However the latter was
> not adopted in the standard. Moreover, the previously allowed
> `e: expanded T' was removed.
>
> The rationale behind is that the expanded vs. reference semantics
> is selected at the class level, because usually it involves redefinition
> of `copy', `is_equal', etc. and ensures the designer that the objects
> of this type are never shared.
>
> If you mean that this is only an entity definition, where the type
> is treated as a reference one, but any creation causes the expanded
> object to be created, this is a possible solution, but I guess,
> it would involve other changes in the language specification.
>  

What other language specifications do you see. If there are some, I am
afraid we have to bite the bullet, because we must give ?INTEGER a
meaning. There is no way out, because of generics.

> Regards,
> Alexander Kogtenkov
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> freeelks-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freeelks-devel
>
>  

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Alexander Kogtenkov [ES]-2]

Helmut Brandl wrote:

> If you can declare ?INTEGER it must be possible to assign Void to that
> entity. Otherwise it would not be detachable.

On the other hand, expanded types are attached, so one interpretation
is to consider them as being such regardless of an attachment mark.

> This does not convince me. b:=a should attach b to the same object as a.
> I don't see any bad consequences because of this, but a better
> performance. Do you see any bad consequences? If yes, can you give an
> example?

If the class is designed in a way that prevents sharing objects of its type,
why do we have to allow it? Air pressure is not shared among vehicle tires.
Allowing to share it would lead to a strange consequence that changing
it in one wheel causes the change in the others.

Regards,
Alexander Kogtenkov

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[helmut.brandl]

Alexander Kogtenkov wrote:

> Helmut Brandl wrote:
>
>  
>> If you can declare ?INTEGER it must be possible to assign Void to that
>> entity. Otherwise it would not be detachable.
>>    
>
> On the other hand, expanded types are attached, so one interpretation
> is to consider them as being such regardless of an attachment mark.
>  

You can do this for explicitely expanded types (just ignore the
attachment mark '?'), but not for implicitely expanded types like formal
generics, because you never know, if the actual generic will be expanded
or reference.

>  
>> This does not convince me. b:=a should attach b to the same object as a.
>> I don't see any bad consequences because of this, but a better
>> performance. Do you see any bad consequences? If yes, can you give an
>> example?
>>    
>
> If the class is designed in a way that prevents sharing objects of its type,
> why do we have to allow it? Air pressure is not shared among vehicle tires.
> Allowing to share it would lead to a strange consequence that changing
> it in one wheel causes the change in the others.
>  

To stick to your example: The question is not, whether AIR_PRESSURE can
be shared, the question is whether ?AIR_PRESSURE can be shared. Remember:

   local
      ap: AIR_PRESSURE
      apd: ?AIR_PRESSURE
  do
     ...
     adp := ap -- will attach a boxed copy of ap to apd

Objects of type AIR_PRESSURE will never be shared.

What is the advantage that objects attached to an entity ?EXPANDED_TYPE
will not be shared? Try to find a strange consequence with objects
attached to detachable entities being shared and keep in mind that
objects attached to expanded type entities will never become shared.

Regards
Helmut

The Eiffel Compiler/Interpreter: http://tecomp.sourceforge.net
http://www.sourceforge.net/projects/tecomp

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel