Difference between revisions of "EiffelStudio Wish List"

foo: STRING assign set_key_value ("foo", ?)
     do
         Result := values.item ("foo")
     end
 
 values: HASH_TABLE [STRING, STRING]
 
 set_key_value (k, v: STRING)
     do
         values.force (v, k)
     end

foo( a : B): C
     exceptions
         Net_Unreachable, Net_Timeout
     do
         Result := values.item ("foo")
     end

Could this be included only on generated views. Not in typed in code, as this can cause a maintinance problem having to propogate changes.

a_routine
     do
         across 1 |..| 10
         loop
              -- do something
         end
     end

class
    CONVERSION_PROPOSAL
 
create
    make_from
 
convert
    make_from,
    something
 
feature
    make_from (v: A_TYPE)
        do end
 
    something: ANOTHER_TYPE
        do end
 
end

equivalent to:

class
    CURRENT_CONVERSION
 
create
    make_from
 
convert
    make_from ({A_TYPE}),
    something: {ANOTHER_TYPE}
 
feature
    make_from (v: A_TYPE)
        do end
 
    something: ANOTHER_TYPE
        do end
 
end

class
    PROPOSITION
 
feature {}
    internal_something: A_TYPE
        do end
 
end

equivalent to:

class
    CURRENT_STANDARD
 
feature {NONE}
    internal_something: A_TYPE
        do end
 
end

• Liberty Eiffel uses this syntax.
• NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)

• The proposal {} is less explicit, so it is arguably harder to read than the current standard {NONE}.
• The proposal {} is likely to cause confusion between unexported features and features exported to {ANY}. Empty braces look very similar to braces omitted entirely.
• The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
• What about inherit {NONE}?
• What would the type of Void be?

Bertrand MEYER described that in this article : [here][3]

Proposition:

• Assigner Commands are not droped when the procedure is renamed or redefined.
• When a query is renamed the assigner may be changed. If there is no assigner command specified then it is removed. (similar to 'alias' behavior).
• Assigner command exportation is equivalent to the procedure.

However, if the exportation of the request is restricted then there is no sense to use the assigner command in the non-exported classes. The previous rule could be replaced with :

• The assigner command is exported to the set of classes resulting of the intersection betwen the exported set of the request and of the command.

example:

class
	A
 
feature {B, C} -- Access
	q: A assign c
 
feature {C, D} -- Chnage
	c (v: A)
		do
			q := v
		end
 
end

-- o: A
o.q := v

is allowed in classes conforms to 'C'.

"[]", "<>", "{}"

target := source
check target = source end

(Except for some cases such as NaN). Therefore the postcondition of assigner commands should verify it.

class interface 
	A 
 
feature
	q (...): T assign c
 
	c (a_q: T; ...)
		ensure
			q (...) = a_q
end

This code should be rejected:

class A feature
 
    do_something
        require else
            True
        do
        ensure then
            True
        end
 
end

if boolean_expression then expression end

is equivalent to:

if boolean_expression then expression else Void end

Since a feature documentation is a part of the note clause (`what' tag), it is also inherited (simple -- <Precursor> is not longer required).

 Add procedures until_do_and_remove and its brothers.

 where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
 		--returns container like current, for items satisfying test
 	deferred
 	end 

 slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
 	deferred
 	end

abs: NATURAL_32
  			-- (from INTEGER_32_REF)
  		...

factorial: like Current
  		...
 
  	even: BOOLEAN
  		...
 
  	odd: BOOLEAN
  		...

• Unused features are already eliminated in the dead code removal step when finalizing a system.