EiffelStudio: an EiffelSoftware project - User contributions [en]

User:Colin-adams

2013-03-22T07:08:13Z

Colin-adams: Removing all content from page

Talk:Agents in SCOOP

2013-03-22T07:02:53Z

Colin-adams:

I use the first parameter in ROUTINE as a documentation hint, to specify the contract an agent is expected to fulfill.

That is, I declare the callback agent as having type ROUTINE [MY_CLASS, TUPLE [....]]

Then in MY_CLASS I declare a single deferred routine that conforms to the expected signature of the callback.
This routine is then equipped with contracts.

This serves as a hint to the user as to what the requirements of the callback actually are. If the user follows the hint by inheriting from MY_CLASS to implement the call back, then the contract is actually checked at runtime, and so provides an early warning of what the bug is.

So I find it usefull.

--[[User:Colin-adams|Colin-adams]] 07:37, 21 March 2013 (UTC)

''[[User:Alexander Kogtenkov|Alexander Kogtenkov]] 07:45, 21 March 2013 (UTC):'' Could you provide an example? Isn't it too restrictive to require an agent to be based on a specific target?

It isn't restrictive, because a deferred class with a single deferred routine can be inherited as many times as you need, renaming the routine.

I don't have an example that I can post publicly, but I'll send one by email.
--[[User:Colin-adams|Colin-adams]] 07:02, 22 March 2013 (UTC)

Talk:Agents in SCOOP

2013-03-21T07:43:39Z

Colin-adams:

Talk:Agents in SCOOP

2013-03-21T07:37:28Z

Colin-adams: New page: I use the first parameter in ROUTINE as a documentation hint in deferred classes with a single routine. --~~~~

I use the first parameter in ROUTINE as a documentation hint in deferred classes with a single routine.

--[[User:Colin-adams|Colin-adams]] 07:37, 21 March 2013 (UTC)

Talk:EiffelBase2

2012-10-20T11:13:14Z

Colin-adams: /* {PREDICATE}.precondition */ new section

'''[[User:Alexander Kogtenkov|Alexander Kogtenkov]] 17:51, 23 April 2010 (UTC):'''
Changing indexable structures to use 1 everywhere for lower index looks like a good idea. The summary mentions the corresponding modification to the class <e>ARRAY</e>. There is one more class that does not fit "start at 1" rule: <e>SPECIAL</e>. Is it planned to change it to start at 1 as well?

'''[[User:Alexander Kogtenkov|Alexander Kogtenkov]] 14:01, 5 April 2012 (UTC):'''
An iterator is usually seen as a passive handle that can be operated by some other code to access elements in turn. On the other hand it can naturally provide <e>do_all</e> and similar iteration features. Such features are quite similar to the previous case, but the loop structure is reused and the code to process elements is wrapped in agents. The third variation covers the case when no external handling is required. Everything is performed by the redefined feature <e>forth</e>. In this case the iterator becomes an active rather than a passive object, because it exhibits some meaningful behaviour itself, without any additional code. In both the second and the third cases the associated loop can be abstrated by some higher-level iterator-like class. Are there any provisions for such abstractions in the proposed class hierarchy?

== Style guidelines for creation procedure names ==

--[[User:Colin-adams|Colin-adams]] 11:09, 12 April 2012 (UTC) with_object_equality doesn't sound like the name of a command, as recommended in the OOSC2 style guidelines. Make_with_object_equality is what I would expect to see.

== {PREDICATE}.precondition ==

--[[User:Colin-adams|Colin-adams]] 11:13, 20 October 2012 (UTC) Features such as {V_CONTAINER}.for_all have preconditions which make use of {PREDICATE}.precondition. In ES 7.1 this is still implemented as always True. Are there plans for a more accurate implementation?

Talk:Main Page

2012-10-06T13:41:09Z

Colin-adams: /* Browse source link doesn't work */ new section

'''--[[User:Juliant|Juliant]] 23:22, 28 November 2006 (CET)'''

Just that it doesn't get forgotten and since someone of the admins has to change navigation I post this here again (From [[Talk:New Main Page]]):

Also a new page logo (at least withouth the white border) and a new navigation would look better. I would split the navigation to a 'normal navigation' part and a 'developers' part (see below).

Navigation proposal:

* Navigation
** Home (not sure if this is needed because the logo alredy points to the main page)
** Categories
** Downloads
** Version history
** FAQ
** Mailing lists
** Eiffel links

* Developement
** Recent changes
** Changelog of 6.x
** SVN repository
** Compiling
** How to contribute

'''--[[User:Seilerm|Seilerm]] 18:35, 4 December 2006 (CET)'''

I think this wiki, as this is the home of EiffelStudio, should be customized.
How others do it:
http://www.mono-project.com

'''--[[User:Manus|manus]] 22:47, 4 December 2006 (CET)'''
I agree with Martin. Does anyone have the experience for doing the customization?

== Browse source link doesn't work ==

It's pointing to origo.
--[[User:Colin-adams|Colin-adams]] 13:41, 6 October 2012 (UTC)

Talk:Migration to Unicode

2012-09-26T08:45:40Z

Colin-adams: /* Where is UTF_CONVERTER? */ new section

'''[[User:Peter gummer|Peter gummer]] 22:25, 25 September 2012 (UTC)''' These are interesting guidelines. Is this recommended already in EiffelStudio 7.1?

Our code currently uses <e>STRING</e> almost everywhere; the ECF maps <e>STRING</e> to <e>STRING_8</e>. Do the guidelines mean that we can change the ECF mapping from <e>STRING</e> to <e>STRING_32</e>? This would be much faster than editing every class individually.

The guidelines recommend using some <e>*_FILE_32</e> classes. Most of our files are UTF-8, not UTF-32. Will using the <e>*_FILE_32</e> classes work?

'''[[User:Alexander Kogtenkov|Alexander Kogtenkov]] 04:07, 26 September 2012 (UTC)'''
This is a work in progress. Specifying mapping for the strings in an ECF might not work if application classes redefine features from the library classes.

As to using <e>*_FILE_32</e> classes, the only difference is the support of file names that use non-ASCII characters. Reading and writing the files is not affected.

== Where is UTF_CONVERTER? ==

In which library is this class to be found? Is it available in 7.0?
--[[User:Colin-adams|Colin-adams]] 08:45, 26 September 2012 (UTC)

2010-02-04T12:42:29Z

Colin-adams: /* Numeric equality */ new section

Most probably C compilers inline functions, but just to be sure, I'd convert them into the macros:
<c>
#define to_raw_bits(d) *((EIF_NATURAL_64*)&(d))

#define eif_is_nan_bits(value) ((value & ~RTU64C(0x8000000000000000)) > RTU64C(0x7ff0000000000000))

#define eif_is_nan(v) ((*((EIF_NATURAL_64 *)&(v)) & ~RTU64C(0x8000000000000000)) > RTU64C(0x7ff0000000000000))
</c>
Does it affect the benchmarks?
:'''--[[User:Manus|manus]] 17:59, 3 February 2010 (UTC)''' Actually it does not on Windows for sure, I've verified that it was inlined. But you are right that those could be simply defined as macros.
::'''--[[User:Manus|manus]] 20:25, 3 February 2010 (UTC)''' I've done again some of the benchmarks and on windows at least, some of them are slower when I use a macro. I'm no sure why I haven't looked at the generated assembly code.

'''--[[User:Colin-adams|Colin-adams]] 14:48, 3 February 2010 (UTC)'''
'''Not IEEE arithmetic, nor maths''', NaN = NaN is never true. And placing NaNs in a sort order isn't write either - REAL_32/64 are not totally ordered types.

:'''--[[User:Manus|manus]] 17:57, 3 February 2010 (UTC)''' How do you solve the problem of assertions then in ARRAY.put for example?

'''--[[User:Alexander Kogtenkov|Alexander Kogtenkov]] 20:01, 3 February 2010 (UTC)'''
* Does it mean that <e>REAL_GENERAL</e> should inherit <e>PART_COMPARABLE</e> rather than <e>COMPARABLE</e>?
* Do we need 2 equality queries: one that tells two objects represent the same value (it is used to ensure <e>copy</e> does what is expected, and it is used to implement <e>~</e>) and the other one that tells that the numbers are equal in terms of ordering relation of <e>(PART_)COMPARABLE</e>?

== Postcondition for put ==

the postcondition for {ARRAY}.put should read:

inserted: v = v implies (item (i) = v)
undefined_case: v /= V implies (item (i) /= item (1))
--[[User:Colin-adams|Colin-adams]] 12:37, 4 February 2010 (UTC)

== Numeric equality ==

I have previously suggested separating the notion of numerical equality and object equality. Eric said that we use = for three different notions, i think, but I don't remember what these were.

Certainly PART_COMPARABLE is better than COMPARABLE for IEEE math types. I'm not sure if that is sufficient or not.
--[[User:Colin-adams|Colin-adams]] 12:42, 4 February 2010 (UTC)

Talk:Ieee arithmetic

2010-02-04T12:37:55Z

Colin-adams: /* Postcondition for put */ new section

Talk:Ieee arithmetic

2010-02-03T14:48:16Z

Colin-adams: /* Not IEEE arithmetic, nor maths */ new section

Talk:Debug generated C code

2009-06-08T15:41:59Z

Colin-adams: Please, not just MS-Windows

This is for MS-Windows only.

It would be nice to have the instructions for Linux, and Mac OSX.
--[[User:Colin-adams|Colin-adams]] 15:41, 8 June 2009 (UTC)

Talk:Using CDD

2009-03-09T15:15:21Z

Colin-adams: New page: Is the CDD branch integrated into the regular EiffelStudio delivery yet? Where are test cases extracted to? Do you define a directory in the ECF or something? --~~~~

Is the CDD branch integrated into the regular EiffelStudio delivery yet?

Where are test cases extracted to? Do you define a directory in the ECF or something?
--[[User:Colin-adams|Colin-adams]] 15:15, 9 March 2009 (UTC)

Talk:EiffelStudio Internationalization

2008-07-07T06:20:15Z

Colin-adams:

'''--[[User:Patrickr|Patrickr]] 17:31, 9 November 2006 (CET)'''

The location for the mo files should be setup in the environment library, on Unix those files go under
/usr/share/locale

e.g.
/usr/share/locale/en/LC_MESSAGES/eiffelstudio.mo
/usr/share/locale/de/LC_MESSAGES/eiffelstudio.mo
/usr/share/locale/de_CH/LC_MESSAGES/eiffelstudio.mo

'''--[[User:Juliant|Juliant]] 19:53, 10 November 2006 (CET)'''

Is it really necessary that the language can be changed while running EiffelStudio? I would say this is set once (even during installation). It wouldn't be a problem to just restart EiffelStudio.

'''--[[User:Ted|Ted]] 03:20, 13 November 2006 (CET)'''
<pre>
What are the advantages of putting mo files under /usr/share/locale? mo files are not shared between applications and normally users do not need to change mo files.
All mo files are put in ES installation directory, we only need to store the locale id as a preference.
More over, mo files are implemented to be accepted by the library only with names of locale id.
</pre>
<pre>
We need to decide whether the language can be switched at runtime. Of course, not doing this as most applications definitely reduces a lot of time.
</pre>

'''--[[User:Patrickr|Patrickr]] 17:13, 13 November 2006 (CET)'''

On Unix there are rules where which part of an application belongs to. Standardising this locations makes various things easier.
I also think changing the language during runtime is not necessary.

== Dont use UTF-16 ==

UTF-16 is an abomination - it should never be used.
--[[User:Colin-adams|Colin-adams]] 09:03, 1 August 2007 (CEST)

I agree. -- [[User:Ted|Ted]] 08:04, 2 July 2008 (PDT)

== Auto-encoding detection ==

Do you have a scheme in mind?

This is, in general, impossible, but special circumstances can make it tractable. The starting possibilities
for an Eiffel source text are quite limited, so at first glance it looks possible.

However, I note that if an Eiffel source text uses ASCII characters for everything except the contents of STRING_8 literals, and no STRING_32 or CHARACTER_32 literals are present, then it will be impossible to distinguish between ISO-8859-1 (or most other subsets of ISO-8859) and UTF-8, unless the UTF-8 file starts with a BOM. But the latter practise is reprehensible, and many editors do not support it.

--[[User:Colin-adams|Colin-adams]] 09:09, 1 August 2007 (CEST)

Yes, one can not tell the encoding accurately. I thought this could be possible done by combination of means. I knew firefox and IE has encoding detection library, but they seem only give the most possible results, not accurate ones.
This part maybe implemented as just "encoding detection" in the end.
--[[User:Ted|Ted]] 08:13, 2 July 2008 (PDT)

== Notes term ==

The problem becomes much simpler if you add the following restriction:

Source codings other than ISO-646 (US-ASCII) and ISO-8859-1 (Latin-1) are only allowed if the class contains an encoding term in the notes (indexing, in pre-ECMA) clause whose value names the encoding.

So a UTF-8 source file would start something like:

<eiffel>
indexing

description: "My latest class writen in Unicode"
encoding: "UTF-8"

class MY_LATEST

end
</eiffel>
--[[User:Colin-adams|Colin-adams]] 09:17, 1 August 2007 (CEST)

This is one way we are thinking of. But ideally this needs parsing. Maybe specifying encoding as compiler argument is good enough, or make it into .ecf files.
--[[User:Ted|Ted]] 08:18, 2 July 2008 (PDT)

== All XML files support all of Unicode ==

The line that says ECF files, etc., will need a Unicode encoding is not true. All XML files, no matter what their encoding, support the entire Unicode character set.
--[[User:Colin-adams|Colin-adams]] 22:41, 1 July 2008 (PDT)

What I mean is specific to EiffelStudio in which we only put iso-8859-1 as encoding of ecfs. This char set is not sufficient, since users will be able to put any Unicode chars in project settings, for example, descriptions. And other internal implementations using XML, like diagram storage, metrics storage may not even take encoding into account. These parts need to be adapted. --[[User:Ted|Ted]] 08:25, 2 July 2008 (PDT)

One thing I am not so sure is whether Gobo XML parser has supported encodings rather than Unicode ones. For example, GB2312. (This implies ability to convert between GB2312 and UTF8 etc.) --[[User:Ted|Ted]] 08:29, 2 July 2008 (PDT)

It IS sufficient.
No matter what the encoding, all Unicode characters (within the limits of the XML version - which means 1.0 for Gobo) can be represented. That is what character references are for. E.g. ŋ is outside the range of Latin-1, but you can still specify it in an XML file with encoding="ISO8859-1".
And no, Gobo does not support GB2312, but it does support UTF-8 (all XML parsers must support UTF-8 and UTF-16). But this is not very relevant.
--[[User:Colin-adams|Colin-adams]] 07:13, 3 July 2008 (PDT)

I see what you mean. It is good to know Gobo takes them as what they are (no information lose). But I am a little surprised that knowing the encoding Gobo doesn't return meaningful strings (in UTF8), but simply the stream taken directly from byte sequence. (Correct me if I am wrong.) So EiffelStudio still needs to handle conversions manually because UTF-32 is used internally and only with known encoding strings can be correctly rendered.
This means we need to convert strings into an encoding the XML file specifies (none implies UTF8). Then converting most Unicode chars to iso-8859-1 is not correct anymore. And can only be safe converting the byte sequence read from XML from the encoding it specifies to UTF32. In any case, I prefer to use UTF8 for all XML files as default.
I am also afraid that using "iso-8859-1" to carry strings in other encoding would make some XML editors incorrectly render them.
--[[User:Ted|Ted]] 09:13, 3 July 2008 (PDT)

Why do you think Gobo doesn't return meaningful strings? Of course it does.
You don't have to worry about any of this. The XML specification, written oer 10 years ago, sorted all this out.

And it is quite safe to serialize as ISO-8859-1 if you wish. No XML editor can render it incorrectly.
--[[User:Colin-adams|Colin-adams]] 23:20, 6 July 2008 (PDT)

Talk:EiffelStudio Internationalization

2008-07-03T14:13:31Z

Colin-adams:

2007-10-04T16:44:35Z

Colin-adams: Class for serialization

--[[User:Alexander Kogtenkov|Alexander Kogtenkov]] 21:21, 3 October 2007 (CEST)
It would be nice to extend the example to see where the <e>gadget.id</e> attribute is serialized (given that the attribute <e>gadget</e> is not serialized at all).

== Transformation at store time ==

--[[User:Alexander Kogtenkov|Alexander Kogtenkov]] 21:49, 3 October 2007 (CEST)
The proposed scheme assumes that some attributes need to be stored and some - not. However, it's possible that the object model is changed over time, but backward compatibility as well as interoperability with other applications is still required. For example, the original program used the RGB color model with the attributes corresponding to the main colors. Over time it turned out that another model, say, HSV one, is more approriate for the associated algorithms and the attributes were replaced by the new ones. Both models cover the same range of spectrum but use different attribute sets.

For example, the systems A and B use the original RGB coding scheme and the new system A' uses new HSV scheme. For interoperability between all these products (given that they are used on multiple machines and cannot be immediately updated, or even worse, the system B is no longer maintained), it's essential to stick to the original storable format. It means that there should be a way to store new attributes of HSV model using the old RGB style.

: On the other hand, the new development can go on and new systems are designed to use HSV model from the beginning. There is no need to use the old format anymore, given that the new systems A' are able to store the data in a new format as well. As far as I can see, this can be achieved by the predicate on the corresponding attributes that tell whether they need to be stored "as is" or not. This behaviour is easily achieved using the proposed technique with predicates if there is also a way to store data in the old format.

The incompleteness of the example is why the page is still marked as under construction.

As for the long-term issue, I explicitly said I was not addressing this in the article. Using storables for a short-to-medium term cache is good. For longer term persistence, a proper database schema is needed, I think (I shall be interested to see what comes out of the persistence project).
--[[User:Colin-adams|Colin-adams]] 08:31, 4 October 2007 (CEST)

== Agent keyword was missing ==

I just noticed your point about <e>gadget.id</e> - I had missed out the keyword <e>agent</e> following the <e>body:</e> tag.
This produces a closed agent (and therefore incorporates the id value). The idea was that somehow the closed agent gets stored in the storable. But maybe this is not possible and/or desirable (if the code for the agent has changed in the meantime, then it is must be better to use the updated code). In which case the storing mechanism can infer the need to store <e>gadget.id</e>, but only for the purpose of closing the agent built at restore time. Does that make sense?

Anyway, I still have to provide a more comprehensive example.
--[[User:Colin-adams|Colin-adams]] 09:05, 4 October 2007 (CEST)

== Examples added ==

I have now filled out a more complete example, and so I have removed the "under construction" label.

Alexander, your RGB -> HSV example is quite interesting, now I think about it a bit more.

I suppose the scenario goes a bit like this:

1) There are three attributes, red, green and blue, which are persistent.

2) New variables, hue, saturation and value are added. To initialize these from an old-format storable, a restoration routine would be needed.
I'm not sure how the routine is supposed to know whether or not restoration must be performed, given that default values would be reasonable. Perhaps restoration routines must be restricted to having detachable reference arguments.

If red, green and blue were re-defined as routines in terms of hue, saturation and value, then a mis-match would occur, so this is no better than the current situation with mismatch-correctors. So they have to still be (redundant) attributes, and must still be persistent so that new storables can be used on the old system.
--[[User:Colin-adams|Colin-adams]] 11:26, 4 October 2007 (CEST)

== Necessity ==
Is this type of functionality needed? If a serialized object of a class A contains more information than what is needed to be serialized, wouldn't it be easier to create a class B that has a creation feature that accepts a parameter of type A, copies the needed information out of A and then serialized the new object of B? When deserializing, A has a creation procedure accepting a parameter of type B and the process is reversed and caches are recreated?

This would seem a lot easier in my opinion.
--[[User:Clemahieu|Clemahieu]] 17:59, 4 October 2007 (CEST)

== Class for serialization ==

Creating a separate class for serialization was my first thought too when I encountered the problem.

That is fine if you only face the problem once. It becomes very tedious as soon as you reached the second or third class, never mind the rest.

--[[User:Colin-adams|Colin-adams]] 18:44, 4 October 2007 (CEST)

Talk:Persistence predicates

2007-10-04T09:26:49Z

Colin-adams: Examples added

Persistence predicates

2007-10-04T07:58:44Z

Colin-adams: Spelling correction

[[Category:Persistence]]
{{Research}}
==Introduction==

Using <e>STORABLE</e>s in an application has at least two significant disadvantages.

One is that using them for long-term persistence is vulnerable to changes in the class.

Another is that too much data may be stored, resulting in large files (or database occupancy, or whatever) and slow reload times. Some data, such as internal caches, are probably best not serialized at all. For other data, it may be better just to store a shorthand identifier to enable the data to be rebuilt (maybe on demand) at retrieval time.

This article explores ways to address the second problem. The first problem is best tackled by only using <e>STORABLE</e>s as a medium-term caching mechanism.

==Transient data==

Java tackles this problem with the keyword <java>transient</java>. An attribute so marked is not stored at serialization time. When the object is retrieved the attribute will be void.

This seems rather limited to me. It can't be used if the class invariant constrains the attribute to be non-void. And I don't think there is a way for a descendant class to override this behaviour (it's a long time since I've written any Java, so I could be very wrong here).

My thinking is that there should be a way to specify whether or not a particular attribute should be stored on any given occaision, and a way to specify what to do at retrieval time.

===Persistence predicates===

A persistence predicate is a routine of type <e>PREDICATE [ANY, TUPLE [!<attribute_type>]]</e> associated with an attribute of type <attribute_type>.
At storage time, the predicate will be called with the instance of the attribute as its argument (if the attribute is non-Void). If it returns <e>True</e> then the attribute is stored. If it returns <e>False</e> then the attribute is not stored, but it may be re-created at retrieval time.

===Restoration routines===

If a persistence predicate returns <e>False</e>, it may be that the programmer does not need this data at all (such as the case of an internal cache). But in some cases the programmer will want the data to be recreated at restoration time (this may be necessary to restore the class invariant), rather than retrieved from the persistence mechanism.

Take an example of a class which has an attribute named <e>`gadget'</e> of type <e>GADGET_FROM_DATABASE</e> having an attribute named <e>`id'</e> of type <e>INTEGER</e>. The class invariant requires that<e>`gadget'</e> is not <e>Void</e>, but the size required to store <e>`gadget'</e> is very large. The class also has a secret routine <e>`create_gadget_from_identifier (a_id: INTEGER)</e> which can be used to create a <e>GADGET_FROM_DATABASE</e> given its <e>`id'</e> value. In such a case, rather than store <e>`gadget'</e> it is probably better to just store the <e>`id'</e> value, and then call <e>`create_gadget_from_identifier'</e> at retrieval time.

A restoration routine is similar to a creation procedure, in as much as it cannot reply on the class invariant holding. It can rely on attributes for which the persistence predicate evaluates to <e>True </e> as having been restored, though.

==Syntax==

One new keyword <e>restore</e> will be required. This can occur in several places:

<ul>
<li>After the <e>create</e> clause in the class prolog. What follows is a list of restoration routines, just like the list of creation procedures. Typically this will occur in the form:
<e>
restore {STORABLE}
recreate_attributes
</e>
</li>
<li>After the <e>attribute</e> keyword and optional body. What follows is:

1. The tag <e>persistence_predicate:</e> followed by one of:

a) <e>True</e> meaning always persist.
b) <e>False</e> meaning never persist.
c) The keyword <e>agent</e> followed by a declaration of a <e>PREDICATE</e>.

2. An optional body (introduced by the tag <e>body:</e>) like the attribute body, and this is code that is executed only if the attribute was not persisted. These routines run after all persisted attributes have been restored, but before the restoration procedure is run. It is only used for initialization of attributes that do not depend
upon other restoration attribute bodies having been run.

</li>
<li>
Within a restoration routine as an instruction. Here it is used analagously to a <e>create</e> instruction, to run one of the named restoration routines specified in the class of one of the attributes that was not persisted.
</li>
</ul>

===Example===

<e>
class A

create
make, make_from_db

restore {STORABLE}
initialize_attributes, recreate_attributes

feature {NONE} -- Initialization

make is
-- Initialize `Current' with a new gadget.
do
initialize_attributes
gadget.save_to_database
-- other stuff ...
end

make_from_db (a_gadget_id: INTEGER; ...) is
-- Initialize `Current' using `a_gadget_id' to create `gadget' from database.
do
recreate_attributes (a_gadget_id, ...)
-- other stuff
end

initialize_attributes is
-- Initialize `gadget' and ...
do
create gadget.make_new
-- other stuff ...
end

recreate_attributes (a_gadget_id: INTEGER; ...) is
-- Recreate certain attributes.
do
create_gadget_from_identifier (a_gadget_id)
-- other stuff
end

feature -- Access

gadget: GADGET
-- Gadget retrieved from DB via its `id' attribute
attribute
restore
persistance_predicate: agent is_gadget_persisted (attribute.id) -- `True' and `False' would also be acceptable values,
-- with `True' being the default
body: agent create_gadget_from_identifier (attribute.id)
end

end

class B

inherit

A
redefine
make
rename
gadget as gadget_from_a
end

create

make

restore {STORABLE}

restore_gadgets

feature {NONE} -- Initialization

make is
-- Initialize `Current' with a new gadget.
do
Precursor
create gadget.make_new
end

restore_gadgets (a_id, a_other_id: INTEGER; ...is
-- Restore `gadget' and `gadget_from_a' from database.
do
restore recreate_attributes (a_other_id, ...)
create gadget.make_from_databse (a_id)
end

feature -- Access

gadget: MY_GADGET
-- Gadget createable from database.
attribute
restore
persistance_predicate: False
end

end
</e>

Here the ECMA <e>attribute</e> keyword is reused to denote the instance of `gadget'. This is only available within the attribute restore clause, not in a restoration routine.

Now here are some scenarios in which objects of classes A and B are stored:

<e>
local
a: A
b: B
do
create a.make
create b.make

-- Save a to a storable, using defaults for retrieval
a.independent_store (a_medium)

-- Assuming `a.is_gadget_persisted (a.gadget.id)' returns `False', `a.gadget' will not be saved, but `a.gadget.id' will be saved
-- for use in the local (attribute-specified) restoration routine `create_gadget_from_identifier.

-- Save b to a storable specifying a restoration routine
b.independent_store (a_medium, agent b.restore_gadgets (b.gadget.id, b.gadget_from_a.id, ...))

-- Assuming `b.is_gadget_persisted (b.gadget_from_a.id)' returns `False', then neither gadget will be stored, but their identifiers
-- will be recorded so they can be passed to `restore_gadgets' at retrieval time.
</e>

==Redefinition==

The open/closed principle is honoured (I think). The author of the class can determine that an attribute must always be stored (this is the default, and is the current situation), or that it is never stored (for a pure cache attribute), or provide flexibility by specifying an agent.

The agent's routine could be deferred, frozen (yuk!) or just a normal routine, in which case descendant classes can redefine it.

The actual instance data that is passed to the persistance_predicate and the restoration_routine could be specified via an agent, which allows for further flexibility. For restoration, it might even involve an <e>EV_DIALOG</e> (heaven forfend)!

==Class correctness conditions==

The possibility of the persistance_predicate evaluating to (or statically specified as) <e>False</e> on an attribute that is required to be non-Void (or non-default for an expanded attribute) implies that either inline restoration code must be supplied, or the restoration routine has an appropriate postcondition clause.

Persistence predicates

2007-10-04T07:56:25Z

Colin-adams: Completed examples

[[Category:Persistence]]
{{Research}}
==Introduction==

Using <e>STORABLE</e>s in an application has at least two significant disadvantages.

One is that using them for long-term persistence is vulnerable to changes in the class.

Another is that too much data may be stored, resulting in large files (or database occupancy, or whatever) and slow reload times. Some data, such as internal caches, are probably best not serialized at all. For other data, it may be better just to store a shorthand identifier to enable the data to be rebuilt (maybe on demand) at retrieval time.

This article explores ways to address the second problem. The first problem is best tackled by only using <e>STORABLE</e>s as a medium-term caching mechanism.

==Transient data==

Java tackles this problem with the keyword <java>transient</java>. An attribute so marked is not stored at serialization time. When the object is retrieved the attribute will be void.

This seems rather limited to me. It can't be used if the class invariant constrains the attribute to be non-void. And I don't think there is a way for a descendant class to override this behaviour (it's a long time since I've written any Java, so I could be very wrong here).

My thinking is that there should be a way to specify whether or not a particular attribute should be stored on any given occaision, and a way to specify what to do at retrieval time.

===Persistence predicates===

A persistence predicate is a routine of type <e>PREDICATE [ANY, TUPLE [!<attribute_type>]]</e> associated with an attribute of type <attribute_type>.
At storage time, the predicate will be called with the instance of the attribute as its argument (if the attribute is non-Void). If it returns <e>True</e> then the attribute is stored. If it returns <e>False</e> then the attribute is not stored, but it may be re-created at retrieval time.

===Restoration routines===

If a persistence predicate returns <e>False</e>, it may be that the programmer does not need this data at all (such as the case of an internal cache). But in some cases the programmer will want the data to be recreated at restoration time (this may be necessary to restore the class invariant), rather than retrieved from the persistence mechanism.

Take an example of a class which has an attribute named <e>`gadget'</e> of type <e>GADGET_FROM_DATABASE</e> having an attribute named <e>`id'</e> of type <e>INTEGER</e>. The class invariant requires that<e>`gadget'</e> is not <e>Void</e>, but the size required to store <e>`gadget'</e> is very large. The class also has a secret routine <e>`create_gadget_from_identifier (a_id: INTEGER)</e> which can be used to create a <e>GADGET_FROM_DATABASE</e> given its <e>`id'</e> value. In such a case, rather than store <e>`gadget'</e> it is probably better to just store the <e>`id'</e> value, and then call <e>`create_gadget_from_identifier'</e> at retrieval time.

A restoration routine is similar to a creation procedure, in as much as it cannot reply on the class invariant holding. It can rely on attributes for which the persistence predicate evaluates to <e>True </e> as having been restored, though.

==Syntax==

One new keyword <e>restore</e> will be required. This can occur in several places:

<ul>
<li>After the <e>create</e> clause in the class prolog. What follows is a list of restoration routines, just like the list of creation procedures. Typically this will occur in the form:
<e>
restore {STORABLE}
recreate_attributes
</e>
</li>
<li>After the <e>attribute</e> keyword and optional body. What follows is:

1. The tag <e>persistence_predicate:</e> followed by one of:

a) <e>True</e> meaning always persist.
b) <e>False</e> meaning never persist.
c) The keyword <e>agent</e> followed by a declaration of a <e>PREDICATE</e>.

2. An optional body (introduced by the tag <e>body:</e>) like the attribute body, and this is code that is executed only if the attribute was not persisted. These routines run after all persisted attributes have been restored, but before the restoration procedure is run. It is only used for initialization of attributes that do not depend
upon other restoration attribute bodies having been run.

</li>
<li>
Within a restoration routine as an instruction. Here it is used analagously to a <e>create</e> instruction, to run one of the named restoration routines specified in the class of one of the attributes that was not persisted.
</li>
</ul>

===Example===

<e>
class A

create
make, make_from_db

restore {STORABLE}
initialize_attributes, recreate_attributes

feature {NONE} -- Initialization

make is
-- Initialize `Current' with a new gadget.
do
initialize_attributes
gadget.save_to_database
-- other stuff ...
end

make_from_db (a_gadget_id: INTEGER; ...) is
-- Initialize `Current' using `a_gadget_id' to create `gadget' from database.
do
recreate_attributes (a_gadget_id, ...)
-- other stuff
end

initialize_attributes is
-- Initialize `gadget' and ...
do
create gadget.make_new
-- other stuff ...
end

recreate_attributes (a_gadget_id: INTEGER; ...) is
-- Recreate certain attributes.
do
create_gadget_from_identifier (a_gadget_id)
-- other stuff
end

feature -- Access

gadget: GADGET
-- Gadget retrieved from DB via its `id' attribute
attribute
restore
persistance_predicate: agent is_gadget_persisted (attribute.id) -- `True' and `False' would also be acceptable values,
-- with `True' being the default
body: agent create_gadget_from_identifier (attribute.id)
end

end

class B

inherit

A
redefine
make
rename
gadget as gadget_from_a
end

create

make

restore {STORABLE}

restore_gadgets

feature {NONE} -- Initialization

make is
-- Initialize `Current' with a new gadget.
do
Precursor
create gadget.make_new
end

restore_gadgets (a_id, a_other_id: INTEGER; ...is
-- Restore `gadget' and `gadget_from_a' from database.
do
restore recreate_attributes (a_other_id, ...)
create gadget.make_from_databse (a_id)
end

feature -- Access

gadget: MY_GADGET
-- Gadget createable from database.
attribute
restore
presistence_predicate: False
end

end
</e>

Here the ECMA <e>attribute</e> keyword is reused to denote the instance of `gadget'. This is only available within the attribute restore clause, not in a restoration routine.

Now here are some scenarios in which objects of classes A and B are stored:

<e>
local
a: A
b: B
do
create a.make
create b.make

-- Save a to a storable, using defaults for retrieval
a.independent_store (a_medium)

-- Assuming `a.is_gadget_persisted (a.gadget.id)' returns `False', `a.gadget' will not be saved, but `a.gadget.id' will be saved
-- for use in the local (attribute-specified) restoration routine `create_gadget_from_identifier.

-- Save b to a storable specifying a restoration routine
b.independent_store (a_medium, agent b.restore_gadgets (b.gadget.id, b.gadget_from_a.id, ...))

-- Assuming `b.is_gadget_persisted (b.gadget_from_a.id)' returns `False', then neither gadget will be stored, but their identifiers
-- will be recorded so they can be passed to `restore_gadgets' at retrieval time.
</e>

==Redefinition==

The open/closed principle is honoured (I think). The author of the class can determine that an attribute must always be stored (this is the default, and is the current situation), or that it is never stored (for a pure cache attribute), or provide flexibility by specifying an agent.

The agent's routine could be deferred, frozen (yuk!) or just a normal routine, in which case descendant classes can redefine it.

The actual instance data that is passed to the persistance_predicate and the restoration_routine could be specified via an agent, which allows for further flexibility. For restoration, it might even involve an <e>EV_DIALOG</e> (heaven forfend)!

==Class correctness conditions==

The possibility of the persistance_predicate evaluating to (or statically specified as) <e>False</e> on an attribute that is required to be non-Void (or non-default for an expanded attribute) implies that either inline restoration code must be supplied, or the restoration routine has an appropriate postcondition clause.

Talk:Persistence predicates

2007-10-04T07:05:58Z

Colin-adams: Agent keyword was missing

Persistence predicates

2007-10-04T06:58:10Z

Colin-adams: Added missing agent keyword

[[Category:Persistence]]
{{UnderConstruction}}
{{Research}}
==Introduction==

Using <e>STORABLE</e>s in an application has at least two significant disadvantages.

One is that using them for long-term persistence is vulnerable to changes in the class.

Another is that too much data may be stored, resulting in large files (or database occupancy, or whatever) and slow reload times. Some data, such as internal caches, are probably best not serialized at all. For other data, it may be better just to store a shorthand identifier to enable the data to be rebuilt (maybe on demand) at retrieval time.

This article explores ways to address the second problem. The first problem is best tackled by only using <e>STORABLE</e>s as a medium-term caching mechanism.

==Transient data==

Java tackles this problem with the keyword <java>transient</java>. An attribute so marked is not stored at serialization time. When the object is retrieved the attribute will be void.

This seems rather limited to me. It can't be used if the class invariant constrains the attribute to be non-void. And I don't think there is a way for a descendant class to override this behaviour (it's a long time since I've written any Java, so I could be very wrong here).

My thinking is that there should be a way to specify whether or not a particular attribute should be stored on any given occaision, and a way to specify what to do at retrieval time.

===Persistence predicates===

A persistence predicate is a routine of type <e>PREDICATE [ANY, TUPLE [!<attribute_type>]]</e> associated with an attribute of type <attribute_type>.
At storage time, the predicate will be called with the instance of the attribute as its argument (if the attribute is non-Void). If it returns <e>True</e> then the attribute is stored. If it returns <e>False</e> then the attribute is not stored, but it may be re-created at retrieval time.

===Restoration routines===

If a persistence predicate returns <e>False</e>, it may be that the programmer does not need this data at all (such as the case of an internal cache). But in some cases the programmer will want the data to be recreated at restoration time (this may be necessary to restore the class invariant), rather than retrieved from the persistence mechanism.

Take an example of a class which has an attribute named <e>`gadget'</e> of type <e>GADGET_FROM_DATABASE</e> having an attribute named <e>`id'</e> of type <e>INTEGER</e>. The class invariant requires that<e>`gadget'</e> is not <e>Void</e>, but the size required to store <e>`gadget'</e> is very large. The class also has a secret routine <e>`create_gadget_from_identifier (a_id: INTEGER)</e> which can be used to create a <e>GADGET_FROM_DATABASE</e> given its <e>`id'</e> value. In such a case, rather than store <e>`gadget'</e> it is probably better to just store the <e>`id'</e> value, and then call <e>`create_gadget_from_identifier'</e> at retrieval time.

A restoration routine is similar to a creation procedure, in as much as it cannot reply on the class invariant holding. It can rely on attributes for which the persistence predicate evaluates to <e>True </e> as having been restored, though.

==Syntax==

One new keyword <e>restore</e> will be required. This can occur in several places:

<ul>
<li>After the <e>create</e> clause in the class prolog. What follows is a list of restoration routines, just like the list of creation procedures. Typically this will occur in the form:
<e>
restore {STORABLE}
recreate_attributes
</e>
</li>
<li>After the <e>attribute</e> keyword and optional body. What follows is:

1. The tag <e>persistence_predicate:</e> followed by one of:

a) <e>True</e> meaning always persist.
b) <e>False</e> meaning never persist.
c) The keyword <e>agent</e> followed by a declaration of a <e>PREDICATE</e>.

2. An optional body (introduced by the tag <e>body:</e>) like the attribute body, and this is code that is executed only if the attribute was not persisted. These routines run after all persisted attributes have been restored, but before the restoration procedure is run. It is only used for initialization of attributes that do not depend
upon other restoration attribute bodies having been run.

</li>
<li>
Within a restoration routine as an instruction. Here it is used analagously to a <e>create</e> instruction, to run one of the named restoration routines specified in the class of one of the attributes that was not persisted.
</li>
</ul>

===Example===

<e>
gadget: GADGET_FROM_DATABASE
-- Gadget retrieved from DB via its `id' attribute
attribute
...
restore
persistance_predicate: agent is_gadget_persisted (attribute.id) -- `True' and `False' would also be acceptable values,
-- with `True' being the default
body: agent create_gadget_from_identifier (attribute.id)
</e>

Here the ECMA <e>attribute</e> keyword is reused to denote the instance of `gadget'. This is only available within the attribute restore clause, not in a restoration routine.

==Redefinition==

The open/closed principle is honoured (I think). The author of the class can determine that an attribute must always be stored (this is the default, and is the current situation), or that it is never stored (for a pure cache attribute), or provide flexibility by specifying an agent.

The agent's routine could be deferred, frozen (yuk!) or just a normal routine, in which case descendant classes can redefine it.

The actual instance data that is passed to the persistance_predicate and the restoration_routine could be specified via an agent, which allows for further flexibility. For restoration, it might even involve an <e>EV_DIALOG</e> (heaven forfend)!

==Class correctness conditions==

The possibility of the persistance_predicate evaluating to (or statically specified as) <e>False</e> on an attribute that is required to be non-Void (or non-default for an expanded attribute) implies that either inline restoration code must be supplied, or the restoration routine has an appropriate postcondition clause.

2007-09-12T14:01:30Z

Colin-adams: Added request for demand-loading of notebook tabs

[[Category:Projects]]
Welcome to the Eiffel/EiffelStudio Wish List. This is the place where you, the community, get a chance to tell us what you think is important to include in the future versions of the Eiffel compiler and EiffelStudio IDE.

Please use this list responsibly and try to correctly categorize your wishes. A brief description may help us evaluate your requirements but please be brief.

Our stock pile of genie snared, dusty gold lamps is running low for our next release ([[EiffelStudio Releases]]) but we'll be sure to scour the lands for more.

== Compiler ==

=== General ===
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! Source & Generated Files in an RDBMS and (optionally) Compile directly from database
| Use an RDBMS to store all sources,libraries and generated files instead of a filesystem. Optionally directly compile from the database. Repository can be shared amongst multiple users
|| Pro's:
* 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
||

|-
! Shared EIFGEN
| Allow sharing of EIFGENs (in read-only mode)|| || ||]

|-
! On-demand tab loading
| Allow creation of an EV_NOTEBOOK tab with an agent to be called to fill the tab when it is first loaded|| || ||

|-
! Enum
| A way to author Enum-like class for typed options or flags. Currently using INTEGER and a bag of analogous constants doesn't make Eiffel "elegant". || ||
* 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.
||

|-
! Decimal
|Addition of a decimal type / REAL_128 for 28 digit precision - || MA_DECIMAL is not efficient || MA_DECIMAL already covers this||

|-
!User types
|I want to be able to define types .e.g. a decimal type as mentioned above. I know all built in types can be defined from scratch, except I a way to initialise from literals. So we need a way to define them as well. Suggest a new defered class with create methods from_literal( s:STRING), and queries is_interger_ok:BOOLIAN, is_real_ok:BOOLIAN, is_arbitary_string_ok:BOOLIAN, is_type_string_ok:BOOLIAN (we would define a new type of string just for this). The compiler when generating optimised code will have to compile the new types and dynamicaly bind to them to create an object that can be embeded into the code. I beleave this would let us write code like: x:DECIMAL; x=1.23 (without a conversion from REAL (float base2)) || || ||

|-
! CHARACTER_16
| CHARACTER_16 type || Smaller footprint than CHARACTER_32, UTF-16 is the default internal text representation for Windows/.Net/OS X/Java so conversion from CHARACTER_32 is costly, particular when dealing with large amounts of text || Please No! CHARACTER_32 covers this already. And UTF-8 is more space-efficient than UTF-16, which is an abomination. What will happen if you have a character from above the BMP? You will then have two CHARACTER_16s in the string for one real character - neither of which is a valid character - then `count' and `item' are all wrong. If you must have UTF-16 STRINGs, then let item return a CHARACTER_32. But note that having a UTF_16 STRING in itself won't eliminate all conversion costs - there is still the endian problem - this could be tackled by each individual UTF-16 STRING knowing whether it is UTF-16BE or UTF-16LE, but you may still need to convert. Comparing two such strings with different endianness would then have to be done using the codes - in what way is that going to be more efficient than using UTF-32? See [[Wish_CHARACTER_16]] for more details on why it is not ok.||

|-
! 7-bit ASCII
| 7-bit (US) ASCII_CHARACTER and ASCII_STRING which extends upon an ARRAY [ASCII_CHARACTER] with values of 0-127, removing the need for UTF8 conversion/checking when passing basic char values to C (gtk interfacing for example when connecting to signals) || || ||

|-
! MUTEX
| Make MUTEX recursive on non-windows platforms or at least provide a mutex and separate recursive mutex for all platforms. || || ||

|-
! Multiple Precompiled.
| Ability for multiple precompiles in a system. || || ||

|-
! XXX
| Ability to compile/debug for both 32/64 bit systems via project settings || || ||

|-
! XXX
| Ability for for a fully optimal finalization for systems marked as 'client only', so that unused variables will not get generated in the finalized C Code. || || ||

|-
! XXX
| Ability for Eiffel Studio to cross compile || || ||

|-
! XXX
| Ability to be able to control all user settable options in studio without having to resort to manually editing files, this is mainly for C compilation options || || ||

|-
! XXX
| Have a smarter C code generation system that can launch a C compilation of any module as soon as the C code is generated, this way we can also be smarter when monitoring C compilation progress || || ||

|-
! XXX
| Ability for ANY to generate a unique id for each object for referencing and hashability || ||
Objects that are hashable should implement HASHABLE
||

|-
! XXX
| With hashable ability of ANY, change object graph traversal for serialization so that multiple threads can serialize at the same time without having to wait linearly (lock_marking/unlock_marking). This may also require a reworking of the mismatch corrector facility as this does not appear to be thread-safe when magically called by the run-time|| || ||

|-
! XXX
| Ability for Studio to work and compile with Cygwin || || ||

|-
! XXX
| Ability to get a list of file dependencies in the form of a file listing to stdout. This list would contain a) all .e files used in the system, b) all .lib/.so files explicitly listed in the ECF/Ace file and c) all .h files referenced in external features (ideally that have not been subjected to dead code removal). Preferably, this feature should be able to be used without performing a full compilation (level 4?). || || ||

|}

=== .NET ===
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Consume .NET generics. Not being able to use them is becoming harder. We cannot write Atlas (AJAX) based web applications because of it. The Visual Studio SDK, used by EiffelEnvision, is increasing it's use of generics and preventing use from supporting some features. The people who want to use the .NET framework classes instead of the Eiffel ones cannot use generics and have to resort to using the non-generic versions of list, which bulks implementation and leads ambiguity. || || ||

|-
! XXX
| Emit .NET generics types for Eiffel generic classes. || || ||

|-
! XXX
| Allow direct access to member of TYPED_POINTER [xxx] item out/ref routine arguments. || || ||

|-
! XXX
| Allow direct setting of TYPED_POINTER [xxx] item for out/ref routine arguments. || || ||

|-
! XXX
| Optimized ''call.do_nothing'' as a IL pop instruction to removed returned value. || || ||

|-
! XXX
| Custom attributes on routine arguments and Result. || || ||

|-
! XXX
| An ability to call a parent .NET constructor from an Eiffel creation routine. || || ||

|}

== IDE ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Give the user control over which classes will be compiled over the GUI (say: click on grey class and it becomes yellow and will be compiled always from now on, even though it may not be used at all. This is good for development of classes which are not added over GUI in ES.) || || ||

|-
! XXX
| While searching for word or after a double click on a word, it would be nice if all words would be highlighted in pastel color style. || || ||

|-
! XXX
| Allow arguments and locals of a routine to be pickable so that they can be renamed via the refactoring tool. || || || In the case of arguments it might be interesting to allow
renaming in ancestor and descendant versions of the feature.

|-
! XXX
| It's a pain to pick`n`drop huge features source code into the context window for setting break point. What about the following: Pick on the right side of the class text picks the feature as well? (Pick on the left side of the class text picks already the feature call). || || ||

|-
! XXX
| Make editor and grid more theme compliant in terms of color and font || || ||

|-
! XXX
| Remove all use of EV_TREE and EV_MULTI_COLUMN_LIST from studio so that all list widgets are drawn by vision2, this will make porting easier, we can also use the grid items to be able to change names of clusters, classes and features inline via the tree items. || || To which other platform would it make porting easier? For the Mac OS port that's completely unnecessary I think. Also it would make the tree view look uglier (not as other tree views etc on the same platform) and inline editing can be made accessible in other ways (at least in OS X that's quite easy) ||

|-
! Extended Static Checking
| Extended static checking integrated into the IDE. || Provides more immediate feedback on potential contract violations. || ||See, for example, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf ES-Verify]

|-
! XXX
| Rearrange widgets of ''search tool'' so that they use free space on the right. Currently it uses too much vertical space. || || I don't see free space on the right. Has this already been done? ||

|-
! XXX
| Add an option to show the target name before the current edited class in the application title bar. When multiple projects are open, it's not possible to identify an EStudio session based on the title that appears on the tray bar|| || |||

|-
!Step-by-step debugging
| It would be useful in step-by-step debugging to be able to follow the execution cursor when checking the invariants as it is done for the preconditions and postconditions of a routine. This way, it would be easy to step into the right features and skip some (or all) of those present in the invariant. || || |||

|-
!Integrated Designer
| It would be nice to have an integrated visual designer so that building business applications where visual design is very import can be created more easily. || || ||

|-
! Drag-n-Drop
| Allow the alternative of using drag and drop everywhere instead of pick and drop. || || ||

|-
! Code annotation tags support
| Log the tags contained in comments. For example, when using Eclipse, it is useful to leave TODO comments behind to ensure that a part that is not implemented will be eventually. When the time comes to clean up the TODO tags, a tool can list them all along with the descriptions and the locations of the comments. || || || Similar approach can be applied to indexing/note tags.

|-
! Token locations in flat-view
| When debugging, I always look at flat view of a feature, then I found something that I want to change, so I have to go back to basic view. Buf often, I need to search the basic view to relocate the code. It would be nice if I can somehow pick a location in flat view and drop it into the right location in basic view.
|| || ||

|-
! External commands in context menu
| Suppose there is an external command "tortoisediff $file_name" to show diff of a file from its working base, then when a context menu for a class is displayed, this command will be in it, and before launch this command, the $file_name placeholder will be replaced by the actual file name. Also, some special placeholders starting with # will be recognized. They represent open arguments. So before launching the command, a dialog will prompt out asking for those values.
|Easy to use, no need to go to Console tool anymore. || ||

|-
! Outline
| When a mouse pointer is over a class name, a feature name, etc., it would be nice to see in a pop-up tooltip some basic information about it like description, header comment, signature, etc. || || ||

|-
! Current value of a variable
| When a mouse pointer is over a variable in debug mode if would be nice to see in a pop-up tooltip its value. || || ||

|-
! Immediate syntax checks
| It would be nice if editor can detect syntax errors and warnings and highlight them inline as well as outline (using a vertical bar, an icon of a particular color, etc.). || || || Syntax warnings include obsolete language constructs as well as unused code (such as unused local variables). For them it should be possible to suggest a replacement, so that manual editing is not required.

|-
! Refactoring: unused inheritance
| A new tool can be introduced to check if a given inheritance path is actually used in a project and if not, would suggest to remove it. || || || It would be great to be able to run such tools in background, so that the checks are invisible to the user that only gets a warning and a suggestion to remove the unused parent clause. This way some other similar tools can be added.

|-
! Refactoring: unused arguments
| A new tool can be introduced to check if all arguments of a feature are used (including all versions of the feature) and would suggest to remove those that are never used. || || ||

|-
! Refactoring: more interactive renaming
| Renaming tool can be changed to prompt for renaming in comments and strings (one by one) rather than to apply renaming for all of them silently. || || ||

|-
! Improve search tool
| Progress of search operation could be shown when performing search on a project and would ensure that the IDE remains responsible at that time. It should be also possible for a user to break the search operation. || || ||

|-
! Automatic source format
| There could be an option to tell the editor to reformat the code according to user preference settings. Those can address the multi-line expression format and the exceptions to the comb format (like for a class' name), for example. The reformat feature can be made to affect only the display so that different project members can view the source as it pleases them in an uniform way. || || ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<code>
foo: STRING assign set_key_value ("foo", ?) is
do
Result := values.item ("foo")
end

values: HASH_TABLE [STRING, STRING]

set_key_value (k: STRING; v: STRING) is
do
values.force (v,k)
end
</code>
|
|
|

|-
! Convenient Number Syntax
|| Adalike syntax for numbers, e.g. 2#101010 = 10#42 = 2#10_10_10 and 100_000_000 = 100000000. || effectively reduces silly bugs when reading and writing numbers || Eiffel allows underscores within numbers to allow digit grouping e.g. 8_961_226||see annotated ada reference manual ||

|-
! Exceptions mentioned in method interface
|| syntax for telling developers about exceptions thrown by a method. e.g.:
<code>
foo( a : B) : C is
require
a /= Void
exceptions
Net_Unreachable, Net_Timeout
do
Result := values.item ("foo")
end
</code>
|| Clear and elegant syntax, no more looking into the implementation to find out which exceptions might occur and which of them might be handled at which level.
|| 1) new keyword. 2) new compiler option necessary (using this interface extension is fully useful only if enforced by the compiler which would break older code). 3) Does not scale well with sub classing and redefining features. Redefined versions may have fewer exceptions, in which some stated exceptions won't occur anymore, or more exceptions, where the feature would no longer conform to the signature and a hack would need to be made or redefining the base class in which case you have a fragile base class problem. The Eiffel way of handling exceptions with the paradigm "a feature either satisfies its contract or an exception is thrown" is really an elegant way of handling the unknown, although it takes some getting used to when coming from Java. ECMA exceptions as objects and the type multibranch instructions will help with non-trivial exception handling.
||
||
|}

== Other ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Make every effective EiffelBase class implement default_create so that it can be used to instantiate any class with default values. || || ||

|-
! XXX
| Provide a WEAK_REFERENCE [G] class to abstract away the implementation details currently provided by IDENTIFIED for implementing weak references. || || ||

|-
! XXX
| Locale support to determine what the default charset is (or whether it is UTF-8 or not) || || ||

|-
! XXX
| Build an object storing database with built-in record locking so that multiple systems can have access to the same 'objects' || || ||

|-
! XXX
| Make base.ecf rely on smaller ecf's (kernel.ecf, structures.ecf, support.ecf) so that these smaller dependancies can be compiled in only if needs be. It would be good if ANY could be optimized so that it doesn't have any references to io (or print) or mismatch information (only needed when storable is employed) as these bring in a lot of overhead when compiling a simple system. The smaller ecf could also link in with the object files of the runtime to avoid linking against a monolithic runtime (cecil, storable, etc) when you only want to print ("Hello World") || ||
* Unused features are already eliminated in the dead code removal step when finalizing a system.
||

|-
! XXX
| Put more of the run-time code in to inline C code reducing the size of the executable if you are not using certain features, ideally the linked against runtime should only contain the core functionality needed to create objects, perform simple operations and garbage collect, any other features can be brought in on a class/library/configuration level. || || ||

|-
! Additional Classes
| It would be nice to have classes in the basic eiffel libraries for handling serial port communication, zip compression, encryption, smtp, pop3, ftp, http, TCP/IP, usb, pdf generation, print engine for report writing. I am sure their are others but the basic idea is that it would be nice to have a complete multi-OS tool for developing business applications with quick access to classes needed. Presently you have to search the internet to find some of these classes. It would be nicer to have a more complete library available from within the IDE. || || ||

|}

Talk:EiffelStudio Internationalization

2007-08-01T07:17:42Z

Colin-adams: Notes term

Talk:EiffelStudio Internationalization

2007-08-01T07:09:35Z

Colin-adams: Auto-encoding detection