--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/d3c47f17-b694-486a-8542-240c91f692ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/d3c47f17-b694-486a-8542-240c91f692ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I can say having lived a similar experience as yours returning to Eiffel after almost 15 years 9 months ago, I bought the old books, and it wasn't easy for me to get the updates.
Thanks for the first pointers.Just in case anyone picks up this thread in search of answers, here two links:
the_option : INTEGER register_property, register_customer, record_visit, reset_customer, reset_property, list_properties, list_customers, help, quit, invalid : INTEGER is unique
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/5ac0cd02-0d65-45fa-84fa-9dc5e35a2c3f%40googlegroups.com.
On Wed, Jul 24, 2019 at 8:06 AM Richard <eiffel-...@rth10260.info> wrote:Question Estudio editor - part 2When I right-click on a class etc in the Groups pane I activate the drag-and-drop feature.Enhancement: I would like to drop the object into the tab area with the effect that a new tab opens with the chosen objectDoesn't it do the trick dropping your object into the tab bar not on an existing tab? I'm refering to after last tab
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/5ac0cd02-0d65-45fa-84fa-9dc5e35a2c3f%40googlegroups.com.
--
**********************************************Philippe GachoudPuerto Williams 6657Las CondesSantiago de Chile
note date: "$Date$" revision: "$Revision$"
feature -- Enumeration red: QUX once Result.make (1) ensure instance_free: class end
This is a recent addition. See https://dev.eiffel.com/EiffelStudio_18.01_Releases.
It was described in this group: https://groups.google.com/forum/#!topic/eiffel-users/Y1FXpFBfInA
To allow for such a postcondition, the feature must not use the object state, i.e. it must not access any attributes, and any feature it calls must recursively satisfy the same condition. Then clients can use the feature without a qualifying object, e.g. {COLORS}.red.
And yes, there will be a collated language description including all recent extensions.
-- BM
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/14854363-8ecd-460f-90c9-9e0a779fb5ac%40googlegroups.com.
-- -- experimential suggestion
somecolor : {QUX}
...
somecolor := {QUX}.red -- sample
...
inspect somecolor when {QUX4}.green then -- do something for green when {QUX4}.red then -- do something for red else -- perhaps unassigned end
note description: "Minimalistic enumeration class derived % % from class QUX by Alexander Kogtenkov" author: "rws" date: "29.07.2019" revision: "0.1"
expanded class QUX4
feature -- Enumeration -- use condensed coding style (hint: clickable view expands nicely) -- invokes default_create -- just ordered aplphabetic by chance
colorless: QUX4 once ensure instance_free: class end black: QUX4 once ensure instance_free: class end blue: QUX4 once ensure instance_free: class end green: QUX4 once ensure instance_free: class end red: QUX4 once ensure instance_free: class end yellow: QUX4 once ensure instance_free: class end white: QUX4 once ensure instance_free: class endend
somecolor : {QUX}
...
somecolor := {QUX}.red -- sample
...
if somecolor = {QUX}.red then print ("somecolor matches as red%N") elseif somecolor = {QUX}.green then print ("somecolor matched as green%N") else print ("somecolor didn't match one or two %N") end
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/14439016-4f70-41ac-9160-fb4d0d9a490e%40googlegroups.com.
note
description : "Root class for this application."
legal: "See notice at end of class."
status: "See notice at end of class." author : "Generated by the New Vision2 Application Wizard." date : "$Date: 2010-11-02 11:05:49 +0000 (Tue, 02 Nov 2010) $" revision : "1.0.0"
class APPLICATION
inherit EV_APPLICATION
create make_and_launch
feature {NONE} -- Initialization
make_and_launch -- Initialize and launch application do default_create prepare launch end
prepare -- Prepare the first window to be displayed. -- Perform one call to first window in order to -- avoid to violate the invariant of class EV_APPLICATION. local w: like first_window do-- ==================== originally generated ====================================-- -- create and initialize the first window.-- create w-- first_window := w---- -- Show the first window.-- --| TODO: Remove this line if you don't want the first-- --| window to be shown at the start of the program.-- w.show-- ==============================================================================-- #################### what i tried to to #################################### -- create and initialize the first window. create first_window
-- Show the first window. --| TODO: Remove this line if you don't want the first --| window to be shown at the start of the program. first_window.show -- ############################################################################## end
feature {NONE} -- Implementation
first_window: detachable MAIN_WINDOW; -- Main window.
note copyright: "Copyright (c) 1984-2006, Eiffel Software and others" source: "[ Eiffel Software 356 Storke Road, Goleta, CA 93117 USA Website http://www.eiffel.com Customer support http://support.eiffel.com ]"
end -- class APPLICATION
Error code: VUTA(2)
Error: target of the Object_call might be void.What to do: ensure target of the call is attached.
Class: APPLICATIONFeature: prepareType: detachable MAIN_WINDOWLine: 52 --| window to be shown at the start of the program.-> first_window.show -- ##############################################################################
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/c3786980-e6d1-499b-9cde-408bf7b34393%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel...@googlegroups.com.
Thanks for a first hint.
Windows didn't seem to pick up the manifest, although tailored according to https://docs.microsoft.com/en-us/windows/win32/controls/cookbook-overview , and dropped side-by-side to the exe, both in workbench mode and in a finalized version.
Hello ECMA people ;-)
Just a short question concerning this:
Had it been discussed to use 'Current = Void' instead of 'class' ? Why was this dismissed?
Regards,
Bernd
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/402901d545cc%24ebfdee70%24c3f9cb50%24%40inf.ethz.ch.
No.
-- BM
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/4476f1b7-34b8-2447-a1fc-c4c9f2032399%40gmail.com.
Lost in the woods
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/a0a13064-d581-41f5-a038-6083c7d9064d%40googlegroups.com.
Search engines are still not very good at handling special symbols.
~ is simply the object equality operator. If a and b are two non-void references, then
a = b holds if and only if a and b are references to the same object.
a ~ b holds if and only if the objects to which they refer are of the same type and equal.
The first implies the second. In the second, the definition of when objects are “equal” is given by the `is_equal‘ function, in its version for the common type.
Previously object equality would have to be written in one of the two forms
a.is_equal (b)
equal (a, b)
but they raise the risk of a run-time “catcall” (non-matching types, here harmless in principle but potentially causing a run-time interrupt anyway). The idiom using ~ is always safe, hence preferred.
And yes, we continue to work on improving the documentation of newer mechanisms.
-- BM
From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> On Behalf Of Richard
Sent: Wednesday, August 21, 2019 02:26
To: Eiffel Users <eiffel...@googlegroups.com>
Subject: [eiffel-users] Re: Returning to Eiffel
Lost in the woods
--
Thank you!
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/5294fe34-6124-4a7b-ab31-df2e9006c35d%40googlegroups.com.
my_routine
local
a1, a2, a3: INTEGER_REF
b1, b2: INTEGER
do
if a1 = a2 then
-- something
end
if b1 = b2 then
-- something
end
end
if &a1 = &a2 then
Dear Finnian,
Thanks for raising this issue but… I don’t think so!
The cited Wikipedia definition, as it stands (I don’t know what book or article it came from), is not quite sound. “An identifier stands for what it is bound to” takes for granted that an identifier is bound to something. But that’s not always true, as the definition itself specifies in its first part: if one can use “an identifier id in a context that establishes a binding for id”, a consequence is that an identifier can be not-bound -- for example, before we establish the first-ever binding for it.
So a sound definition should say “an identifier, if bound, stands for what it is bound to”. (And preferably say what it stands for if not bound.)
The Eiffel approach is simpler and unlike the above definition is, I believe, logically sound. An entity (the kind of identifier relevant here) is always bound at run time to a value. If that value is a reference, it is void or attached (to an object). The semantics of all operations, for example equality a1 = a2, or object equality, is precisely defined by the standard for both of these cases.
Note the three levels: the identifier (entity); the value; the object.
(For reference types the value is a reference. For expanded types the value is an object so there are only two levels, not three.)
It is the goal of a higher-level language, through abstraction, to protect programmers from unnecessary details, as long as the semantics is clear and surprise-free. I don’t think that forcing on programmers the explicit introduction of addresses would help. In fact the need to distinguish between L-values and R-values, even in the vast majority of cases for which no confusion would arise, introduces worse confusion instead and is in my view one of the main deficiencies of C programming.
Still, it’s always good to go back to the fundamental questions. Thanks.
-- BM
From: eiffel...@googlegroups.com [mailto:eiffel...@googlegroups.com] On Behalf Of Finnian Reilly
Sent: Friday, 23 August, 2019 13:09
To: Eiffel Users <eiffel...@googlegroups.com>
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/8538281c-036c-4e63-824f-364a58679ea2%40googlegroups.com.
Peeking behind the curtains of EiffelStudio I find that the icons used are packed into a matrix within a single PNG file.
As life has it I drifted away from Eiffel as an interest, but lately i am looking to catch up with the evolution of the language.My last understanding of the syntax equals the 2006 ECMA-367 standard definition.Question: where can I find documentation on syntax changes since then?Thanks for any and all pointers.ps. at first glance much of the docu provided at https://dev.eiffel.com/Main_Page seems fairly dated and isn't very helpful.
-- some syntax coding surprisesprint ("Tuple count " + tup.count.out + "%N") -- some infoprint ("Tuple count " + tup.count. out + "%N") -- some infoprint ("Tuple count " + tup.count .out + "%N") -- some infoprint ("Tuple count " + tup.count . out + "%N") -- some infoprint ("Tuple count " + tup . count . out + "%N") -- some info
Not everything in the ECMA spec is expressed as a bnf, but this seems to address your concern:
8.32.4 Semantics: Break semantics
Breaks serve a purely syntactical role, to separate tokens. The effect of a break is independent of its makeup (its precise use of spaces, tabs and newlines). In particular, the separation of a class text into lines has no effect on its semantics.
Because the above definition of “break” excludes break characters appearing inCharacter_constant, Manifest_string and Comment components, the semantics of these constructs may take such break characters into account.
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/be0070ef-1c25-45d2-8770-4de1823ac51c%40googlegroups.com.
a_greeting := if time < noon then "Good morning" elseif time < evening then "Good afternoon" else "Good evening" end
a_text := inspect a_number
when 1 then "one"
when 2 then "two"
else "do not know"
end
inspect a_number
when 1 then a_text := "one" when 2 then a_text := "two" else a_text := "do not know" end
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/96a2cf9a-7f51-47bf-9c7d-bcc3c68b3629%40googlegroups.com.
Error code: VEVI
Error: variable is not properly set.
What to do: ensure the variable is properly set by the corresponding
setter instruction.
Class: MY_INTEGER_MATH
Source class: ANY
Feature: default
Variable: Result
Line: 360
do
-> end
feature -- Basic operations
frozen default: detachable like Current
-- Default value of object's type
do
end
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/EEFAC0D3-F980-4F15-B7C6-BFFC99BFBC5E%40acm.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CABuDMNMJyDHT%3D316mpNin%3D5Uhvh_zSnmQrTFxeePg%3D_kFOsLpg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/560285BA-AA76-4740-AF04-B95027F36093%40acm.org.
I have a small test program with one small class I want to exercise.Compilation errors out with the message of
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/88ffc56f-fdaf-431f-bc61-0e8a390e8092%40www.fastmail.com.
-------- Original Message --------
Subject: Re: [eiffel-users] Returning to Eiffel
From: Ian Joyner <i.jo...@acm.org>
Date: Fri, September 13, 2019 5:57 am
To: Eiffel Users <eiffel...@googlegroups.com>
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/55FE1F42-A091-4C4E-A65B-988DB59ECCEE%40acm.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/55FE1F42-A091-4C4E-A65B-988DB59ECCEE%40acm.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/55FE1F42-A091-4C4E-A65B-988DB59ECCEE%40acm.org.
Have we come to this?
-------- Original Message --------
Subject: Re: [eiffel-users] Returning to Eiffel
From: Larry Rix <lar...@moonshotsoftware.com>
Date: Fri, September 13, 2019 9:11 am
To: Eiffel Users <eiffel...@googlegroups.com>
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CAJ7KgmA8PqoYiqmvGn5sdOzqRAUgQ%3DLLpzjc%3DY9UVVKG4jYsAA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20190913061805.cf48dd763fcaf5d42559c6c92f6fc53b.5d9ce7348f.wbe%40email25.godaddy.com.Attachments:
- image.png
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/39eccafa-0aee-4ac8-81f8-7a8b5a1a7465%40www.fastmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/39eccafa-0aee-4ac8-81f8-7a8b5a1a7465%40www.fastmail.com.
I believe that a conditional inspect expression does far more than save typing. In Richard’s example below, the inspect statement repeats the assignment to A_Text in each branch. Even if it is the clear intention of the author, it is not possible to ensure that all branches of this statement – even new branches added by a different author - assign a value to A_Text.
Inspect statements/expressions are rightly, in my view, frowned on in an OO environment with polymorphism. For the rare cases where their use is unavoidable, it is better to ensure discipline through a language mechanism, instead of hoping that whoever edits the code will pay attention to author comments or, in their absence, divine the author’s intention.
From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> On Behalf Of Gary Smithrud
Sent: 13 September 2019 03:21
To: eiffel...@googlegroups.com
Subject: Re: [eiffel-users] Returning to Eiffel
I don't like it. It completely changes the semantics of inspect and for what? To save.some typing...
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CABuDMNMJyDHT%3D316mpNin%3D5Uhvh_zSnmQrTFxeePg%3D_kFOsLpg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CAJ7KgmCTvE82izUg9DmAbsDOtGLoDCFbN7sOs7Fjz1Ft2XMozQ%40mail.gmail.com.
when <expression> matches <value_interval_1> then -- statements matches <value_interval_2> then -- statements ... matches <value_interval_N> then -- statements else -- statements end
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CABuDMNNFKrReAgL9UjEwTRWkpP3O5a3hbvFSU32zaHfnPwMJ-w%40mail.gmail.com.
Curious -Eiffel defines a Conditional Expression https://www.eiffel.org/doc/eiffel/Conditional_expression like:
.....
Eiffel also defines the multi-branch instruction with inspect (at https://www.eiffel.org/doc/eiffel/ET-_Instructions#Multi-branch).
.....
So far so good. Has there ever been a discussion over a matching Multi-branch Expression ?
Something like this:....
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/0e804ceb-da06-7a20-1bc1-5b2bb1f33fe3%40gobosoft.com.
Yes, readability is one of the key criteria, and was exactly the argument that the original proposer (Richard) was using when he contrasted (I am citing his example)
a_text := inspect a_number
when 1 then "one"
when 2 then "two"
else "do not know"
end
with
inspect a_number
when 1 then a_text := "one"
when 2 then a_text := "two"
else a_text := "do not know"
end
The second form contains redundancy. Redundancy can be good (static typing is a form of redundancy), but here it seems useless and distracting (you have to check that the same variable `a_text’ is being assigned in every case – waste of time, attention and effort). It is reasonable to argue that the first variant is more readable
I am not endorsing the proposal at this point (pending further evaluation, and assessment of other priorities in the language’s evolution) but I don’t think it is fair to dismiss it on the basis of generic gut feelings.
-- BM
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20190913073824.cf48dd763fcaf5d42559c6c92f6fc53b.fe34178ece.wbe%40email25.godaddy.com.
give_me ( n : array [STRING] ; i : INTEGER ) : STRING -- arrays of names / the number to represent
do
if n.lower <= i and then i <= n.upper then Result := n [i]
else Result := "invalid"
end
end -- give_me
numbers_55_thru_77 : array [STRING]
once
create Result.make_filled ("unknown", 55, 77)
Result [ 55 ] := "fiftyfive"
Result [ 60 ] := "sixty"
Result [ 61 ] := "sixtyone"
Result [ 70 ] := "seventy"
end -- numbers_55_thru_77
print ("Give Me 55 as " + give_me (numbers_55_thru_77, 55) + "%N")
print ("Give Me 61 as " + give_me (numbers_55_thru_77, 61) + "%N")
print ("Give Me 77 as " + give_me (numbers_55_thru_77, 77) + "%N")
print ("Give Me 12345 as " + give_me (numbers_55_thru_77, 12345) + "%N")
Richard <eiffel-...@rth10260.info>:
Talking about “idiomatic” (and nitpicking), in Eiffel style we would not call a function “give_me” (a verbal form that suggests a command) but something more like “given_to_me” (or more likely just “item” in this case). Also, I think it has been a long time since anyone bothered to repeat the name of a routine as a comment at the end, Ada-style. The standard indentation style is also different from what’s below.
-- BM
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/1568449190.680267570%40f139.i.mail.ru.
-------- Original Message --------
Subject: Re: [eiffel-users] Returning to Eiffel
From: Ian Joyner <i.jo...@acm.org>
Date: Sat, September 14, 2019 1:08 am
To: Eiffel Users <eiffel...@googlegroups.com>
I think that like i++, the += and -= forms expose the underlying operation of machines, although not as bac as the side effects in i++.Thus the inspect expression is more abstraction oriented. If anyone read the hourglass model in July CACM (https://cacm.acm.org/magazines/2019/7/237714-on-the-hourglass-model/fulltext) I’d say that ++, +=, -= are in the bottom part of the hourglass and should not be exposed, whereas inspect expressions are more in the neck and upper part of the hourglass.
Ian
On 14 Sep 2019, at 04:39, Eric Bezault <er...@gobosoft.com> wrote:
On 13/09/2019 16:38, r...@amalasoft.com wrote:
Apart from the infamous ternary expression, C (a language for which I have great respect) has another pair of all-stars with which we are familiar (and might even like): the pre/post increment/decrement operators. While the more popular of these are the post variants, and their use is most often innocent enough, it's simply too easy to put in the wrong place, or to misinterpret. Their less svelte siblings, the '+=' and '-=' operators, seem more in line with the "intent is obvious enough" and "first, do no harm" principles, and might actually have a place in a more disciplined language like Eiffel.
Note that the expression 'i++' is violating one of Eiffel's principles:
Command-Query-Separation. An expression with side-effect: each call to
'i++' modifies its result. So there is no chance to have it adopted in
Eiffel. Conditional expressions do not suffer from this problem, neither
do '+=' and '-='.
--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/0e804ceb-da06-7a20-1bc1-5b2bb1f33fe3%40gobosoft.com.
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/825F2E8C-80F3-4B06-B2B4-37781C1183BE%40acm.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20190914045138.cf48dd763fcaf5d42559c6c92f6fc53b.93339536a5.wbe%40email25.godaddy.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20190914045138.cf48dd763fcaf5d42559c6c92f6fc53b.93339536a5.wbe%40email25.godaddy.com.
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/1568449190.680267570%40f139.i.mail.ru.
karsten...@gmx.de:
19.07.10.3368 (July 31st 2019, beta 19.07)
New features
- compiler: Added support for manifest immutable strings, once manifest immutable strings, and immutable string constants. Examples:
{IMMUTABLE_STRING_32} "Unicode string..."
,once {IMMUTABLE_STRING_8} "once value"
,id: IMMUTABLE_STRING_8 = "abc"
.
if sub_node.has_same_name (once "SHORTCUT") then
if sub_node.has_same_name (once "SHORTCUT") then
This particular syntax has been around since at least 16.01. For routines that are called many times, it is not desirable to create a new local instance of "SHORTCUT" each time, which is what would happen if not prefixed with `once'.
Finnian
-------- Original Message --------
Subject: [eiffel-users] Re: Returning to Eiffel
From: Richard <eiffel-...@rth10260.info>
Date: Wed, August 19, 2020 12:57 am
To: Eiffel Users <eiffel...@googlegroups.com>
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/2dda1a73-f4a1-441a-905f-82282304db1eo%40googlegroups.com.
Same problems here with the old books. What I do is that go methodically through the book and then check the new Eiffel class spec. I also do version control and then upgrade the code step by step, documenting it (say, there was a formula for calculating "Pi" with arc tangent, but now MATH_CONST does it for you - change the types - and the compiler - oh, wow, what a great tool! - and you're done. Stuff like that...I have a few on my git repository, but the book's copyright doesn't seem to allow me to make the repository public. I'm thinking of asking one of the authors. This would help greatly, I think.
Also, I see that the Smalltalk community made a move to ask the authors of old books to have them released on the web. The books are old and no-one wants to buy them anymore (except us few). This would be a healthy undertaking for the Eiffel community.
Cheers,-- Hankps. at first glance much of the docu provided at https://dev.eiffel.com/Main_Page seems fairly dated and isn't very helpful.
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CAJ7KgmD8Ro9AsYiqQTqnLAVoGQ4fCYcikriftPvwZbTQ3Ssp2g%40mail.gmail.com.