EiffelStudio Wish List

• Easy queriable
• Much more appropriate to use a database to store relations (dependencies) between objects.
• Easier for using a shared repository amongst multiple users

• Sophisticated collaboration tools already exist for sharing project source e.g. SVN, CVS

• Would be a smart idea implementing this in a similar way as IP (Intentional Programming) does (storing source files as Abstract Syntax Tree, representable in different representations, and using a smart versioning system). More info: see [1]

• The best practice way to get a value that only needs to be defined once is by using the "once" keyword in combination with a feature.

Objects that are hashable should implement HASHABLE

The `redefine' clause cannot be used to effect a inherited deferred feature. This code should be rejected:

deferred class A feature
 
    do_something
        deferred end
 
end
 
class B inherit
    A
        redefine
            do_something
        end
 
feature
 
        do_something
            deferred end
 
end

renaming in ancestor and descendant versions of the feature.

You should be able to just press <CR> at end of line and type. E.G. if you are in a do block and type ensure it should unindent. |Badly indented should be an earlt indication of some syntax errors.

Better for begginers: Resurch has shown that begginers see these questions as asking for permition, and do not feal qualified to give it. Most begginers press No the first time. Then later wonder where there work went.

Or even better just save it.

See: The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity (http://www.cooper.com/insights/books/)

For example:

apply
		-- Call procedure with `args' as last set.
	do
		call (operands)
	end

Throws a warning for nonexistent `args' feature. This check could be a part of Inspector Eiffel.

sometimes it is diffult to distinguish this two codes:

some_target.feature_of_some_type.feature_of_some_type_2

some_target_feature_of_some_type.feature_of_some_type_2

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

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

e.g.

class A feature
    something: ANY
        note
            what: "Documentation."
            option: stable
        do end
end
 
class B inherit A redefine something end feature
    something: ANY
        note
            what: "New documentation."
        do end
end

The `what' clause is not inheried since it is redefined. However the `option' clause is inherited.

class A feature
    something: ANY
        note
            obsolete: "Use another instead."
        do end
end

instead of:

class A feature
    something: ANY
        obsolete
            "Use another instead."
        do end
end

 Add procedures until_do_and_remove and its brothers.

where (test: PREDICATE [ANY, TUPLE [G]]): like Current
        -- Items satisfying `test'
    ...

slice_until, slice_after, ... (test: PREDICATE [ANY, TUPLE [G]]): like Current
    ...

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.