no free functions?!

So, I've learned that Eiffel doesn't have free functions or static
methods.

How would you go about defining, say, erf(x) ? Do you have to make it
a method in some faux class? If so, does an instance of this class
need to be created before the function can be called on it as if it
were a method? Isn't this bizarre?

jhc0033@gmail.com schrieb:
> So, I've learned that Eiffel doesn't have free functions or static
> methods.

It does have once features.

> How would you go about defining, say, erf(x) ? Do you have to make it
> a method in some faux class? If so, does an instance of this class
> need to be created before the function can be called on it as if it
> were a method? Isn't this bizarre?

You could call it bizarre. I call it honest.
Whenever you call a function from a non-OO library,
you assume an implicit context. This context tends to
be explicit in Eiffel. E.g., the errno variable and
similar variables are connected to the funcions by
man pages only; try using them reliably in multithreaded
programs.

Eiffel forces a module around everything executable,
that is true. Does it hurt much when you write modules
featuring the empty set of state variables?

Consider Eiffel with DbC, not without it.
It might seem harder at first, because it invites you
to think about the module invariant.
However, in a stateless service class, the module invariant
should be trivial: true.

In message <66c2a78b-de16-4fd5-b757-7aaf90655bf4@z24g2000prf.googlegroups.com>
"jhc0033@gmail.com" <jhc0033@gmail.com> wrote:

> How would you go about defining, say, erf(x) ? Do you have to make it
> a method in some faux class? If so, does an instance of this class
> need to be created before the function can be called on it as if it
> were a method? Isn't this bizarre?

Bear in mind the instance of the library class can be expanded, so you don't
have to have an explicit create statement, just declare a local.

On 14 Mai, 20:36, Simon Willcocks <simon.willco...@t-online.de> wrote:
> In message <66c2a78b-de16-4fd5-b757-7aaf90655...@z24g2000prf.googlegroups.com>
> "jhc0...@gmail.com" <jhc0...@gmail.com> wrote:
>
> > How would you go about defining, say, erf(x) ? Do you have to make it
> > a method in some faux class? If so, does an instance of this class
> > need to be created before the function can be called on it as if it
> > were a method? Isn't this bizarre?
>
> Bear in mind the instance of the library class can be expanded, so you don't
> have to have an explicit create statement, just declare a local.

Does ISE optimize this away (expanded class without member variables)
now?
They didn't in the past. I like that SmallEiffel was always better in
this way.

But i agree with the OP that i would see Eiffel go away from this pure
OO.
In my experience pure OO and multiple inheritence is just delivering
what Meyer
promised. Eiffel is used for DbC. We just added agents to get around
some of the
OO restrictions. And AFAIK there are object less constants already.
Something that
was also forbidden by Eiffel 2.0

The paradigm Eiffel goes with is pure OO. A function doesn't exist
unless it operates on an ADT albeit possibly an partial ADT.

Eiffel has non-conforming inheritance which allows you to pull in
functionality in a non-conforming matter so no, you don't need to
instantiate an instance.

On May 14, 2:56 am, "jhc0...@gmail.com" <jhc0...@gmail.com> wrote:
> So, I've learned that Eiffel doesn't have free functions or static
> methods.
>
> How would you go about defining, say, erf(x) ? Do you have to make it
> a method in some faux class? If so, does an instance of this class
> need to be created before the function can be called on it as if it
> were a method? Isn't this bizarre?

On 14 mai, 12:53, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
> E.g., the errno variable and
> similar variables are connected to the funcions by
> man pages only; try using them reliably in multithreaded
> programs.

What's the problem with using errno reliably in multithreaded
programs ? Any decent libc implementation support that quite well
using TLS and dereference :

bits/errno.h:42:# define errno (*__errno_location ())

nicolas.edel@gmail.com wrote:
> On 14 mai, 12:53, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
>> E.g., the errno variable and
>> similar variables are connected to the funcions by
>> man pages only; try using them reliably in multithreaded
>> programs.
>
> What's the problem with using errno reliably in multithreaded
> programs ? Any decent libc implementation support that quite well
> using TLS and dereference :
>
> bits/errno.h:42:# define errno (*__errno_location ())

Actually, you are proving my point: While shared variables are
not available as a C concept, TLS provides exactly the modular
setup to which I had been referring[*]; you don't see the
modularization, though. Alas, for C use, TLS is a non-portable
OS-concept, and "thread" it is not built into the language
and therefore no information for the C compiler. Eiffel,
properly implemented, has support for concurrent and parallel
programming built in via "separate" and associated semantics
(see e.g. SCOOP).

Multiprogramming looks like an old concept, and languages older
than C and cousins have typically supported multiple threads and
shared variable protection right in the language. Luckily, some of
this old wisdom will now be preserved because the multicore CPUs
provide an incentive to again become familiar with semaphores,
monitors, CSP, etc..
[*] errno is just a good example for the more general shared
variable that needs protection from concurrent access. It hadn't
always been a matter of course for a C library to be thread
safe!

On 18 mai, 14:58, Georg Bauhaus <see.reply...@maps.futureapps.de>
wrote:
> nicolas.e...@gmail.com wrote:
> > On 14 mai, 12:53, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
> >> E.g., the errno variable and
> >> similar variables are connected to the funcions by
> >> man pages only; try using them reliably in multithreaded
> >> programs.
>
> > What's the problem with using errno reliably in multithreaded
> > programs ? Any decent libc implementation support that quite well
> > using TLS and dereference :
>
> > bits/errno.h:42:# define errno (*__errno_location ())
>
> Actually, you are proving my point: While shared variables are
> not available as a C concept, TLS provides exactly the modular
> setup to which I had been referring[*]; you don't see the
> modularization, though. Alas, for C use, TLS is a non-portable
> OS-concept, and "thread" it is not built into the language
> and therefore no information for the C compiler.

Threads are by themselves not a C concept, just an extension (as
networking is).
Also note TLS is as non portable as "standard" libraries for Eiffel
are.

> Eiffel,
> properly implemented, has support for concurrent and parallel
> programming built in via "separate" and associated semantics
> (see e.g. SCOOP).
>

I would have say SCOOP theory is properly designed (I like it very
much as it is described in Meyer's book), but I don't believe any
implementation is provided as a *compiler* builtin but provided as
preprocessor, ie code generator (cf http://scoop.origo.ethz.ch/wiki/SCOOP_Implementation
). I had a brief look at Ecma spec and did not not see any reference
to the `separate' keyword. Any link ?

> Multiprogramming looks like an old concept, and languages older
> than C and cousins have typically supported multiple threads and
> shared variable protection right in the language. Luckily, some of
> this old wisdom will now be preserved because the multicore CPUs
> provide an incentive to again become familiar with semaphores,
> monitors, CSP, etc..

Hope you could be right but I would not bet on that. Languages such as
Erlang have been designed with concurrency in mind, have well-working
implementations but ... that's all.

>
>[*] errno is just a good example for the more general shared
> variable that needs protection from concurrent access. It hadn't
> always been a matter of course for a C library to be thread
> safe!

But now it is, so what ?! It's a pleasure to see it has been possible
to adapt current implementations to current needs without breaking the
standard API. If people making Eiffel had such good intentions for
some years, maybe I would be an happy Eiffel programmer at work.
Also note the SCOOP theory has been described in Meyer's book for a
least 10 years while been available (as a preprocessor and for 1
compiler) since only a very few time. At the same time, a lot of
things have changed in the Eiffel definition!

-Nicolas

nicolas.edel@gmail.com wrote:

> Also note the SCOOP theory has been described in Meyer's book for a
> least 10 years while been available (as a preprocessor and for 1
> compiler) since only a very few time. At the same time, a lot of
> things have changed in the Eiffel definition!

Browsing the archives of c.l.eiffel discussions from
round 1990 is always instructive. There are so many
insights that will easily carpet anyone considering an
easy implementation. ;-)

One design strategy that, I speculate, might have influenced
ECMA Eiffel is the office market situation;
seems like there has been synergy of Eiffel and early .NET.
So maybe good integration with .NET and its typical support
of multithreading is a viable alternative for now.

Syntax error at line 21 in class FOO
(Concurrent Eiffel is not enabled)


end
^---------------------------

"jhc0033@gmail.com" <jhc0033@gmail.com> writes:

> So, I've learned that Eiffel doesn't have free functions or static
> methods.
>
> How would you go about defining, say, erf(x) ? Do you have to make it
> a method in some faux class? If so, does an instance of this class
> need to be created before the function can be called on it as if it
> were a method? Isn't this bizarre?

IMHO static members are "modules" at best, not "classes" or "objects".
If you want it object-oriented, you get it that way. Maybe you want something
else. Next one asking for "static objects" (that need no creation)?

Ulrich