Difference between revisions of "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

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

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]

 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

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