eiffelroom - Comments

UFOs

Alexander has clarified that ephemeral classes have no identity and no state.

Maybe we could call instances of them UFOs: Unidentified Fleeting Objects.

It is a connection between

In reply to Formal Generics in ROUTINE, PROCEDURE, FUNCTION and PREDICATE:

It is a connection between TYPE being generic and the SCOOP necessity to know the separate status of the target type. A new query was added to ROUTINE to get that type and the signature of that query was naturally TYPE [BASE_TYPE]. If we did not have BASE_TYPE then the only type we could give that query was TYPE [detachable ANY].

However I don't know about the current version of SCOOP and if this still applies.

Others from the ECMA committee might remember another reason for BASE_TYPE.

I once used it as a kind of

In reply to Formal Generics in ROUTINE, PROCEDURE, FUNCTION and PREDICATE:

I once used it as a kind of documentation. I created a deferred class with a function in it, and specified the contract of the function (it was intended as a call back) there. The idea was that the programmer, seeing a BASE_TYPE, would take a look at that class, and know what the contract of the call-back was supposed to be.

This could only act as a hint. I was just trying to make some use of an otherwise useless construct.

Agreed

In reply to Formal Generics in ROUTINE, PROCEDURE, FUNCTION and PREDICATE:

I can attest that the BASE_TYPE generic is never used. I have never seen even one case where the base type was restricted to anything...

That's correct

In reply to Ephemeral classes:

When this possibility is required, we can have 2 classes with the expanded one inheriting the reference:

class A_REF
feature
	...
end
 
expanded class A inherit A_REF end

Then the code from the example can be rewritten as

a: A_REF
b: B
 
a := b

Hopefully in practice this will not happen too often, because the idea is to detach any state and identity from an object - allowing the attachments like the above we preserve them instead.

There is one issue with

In reply to Ephemeral classes:

There is one issue with having expanded class without attributes being considered ephemeral it is the one of conformance. In the case of the ephemeral class expanded class A, and having class B inherit A, you cannot write the following:

a: A
b: B
 
a := b

but I definitely agree that expanded classes without attributes fit the description of ephemeral classes.

Clarification

In reply to Ephemeral classes:

I'd like to clarify the idea of the previous message. When we talk about objectless calls, we mean that out of the 3 properties associated with objects:

identity
state
behaviour

we need only one - behaviour. The other two should not be present for the calls to be safe as objectless. And this is what expanded classes without attributes provide: only behaviour without any identity or/and state. Therefore they can be used directly for the purpose raised by this topic:

note
	identity: no
	state: no
	behaviour: yes
expanded class MATH_64
feature -- Logarithm
	log2 (value: REAL_64): REAL_64
			-- Logarithm with base 2
		...
	ln (value: REAL_64): REAL_64
			-- Logarithm with base `e'
		...
	lg (value: REAL_64): REAL_64
			-- Logarithm with base 10
		...
end

Free bonus: the objectless features can be used in unqualified calls (if inherited, including secret inheritance), qualified objectless calls and qualified object calls:

inherit {NONE} MATH_64 -- Normal inheritance can be used as well if required
...
	m: MATH_64 -- Can be declared if we want to avoid inheritance from MATH_64
...
	x := ln (y) -- Unqualified call to inherited feature
	x := {MATH_64}.ln (y) -- Qualified objectless call
	x := m.ln (y) -- Qualified object call (the object `m' is only to make the call, it's not used by itself)

It should not do any harm

In reply to Ephemeral classes:

I believe it's OK to inherit and redefine features that are initially used as objectless. The issue is that they cannot be any longer used as objectless if the inheriting/redefining class does not ensure this property. But this does not break clients of the original objectless class, because the calls are not associated with any objects, they are bound to the class instead.

(And if one wants to forbid such inheritance or redefinition, the class can be marked as frozen.)

Shall we introduce new entities?

In reply to Ephemeral classes:

It looks like I failed to highlight that apart from stateless property of a class that can be used for objectless calls the other one is lack of identity. Indeed stateless class still can be used to program an application with the behaviour that depends on the objects (the example is simplified, compared to real life, but should give an idea):

class TRAFFIC_LIGHT_COLOR
inherit
	ANY
		redefine
			out
		end
create {TRAFFIC_LIGHT}
	default_create
feature -- Output
	out: STRING
			-- <Precursor>
		local
			controller: TRAFFIC_LIGHT
		do
			create controller
			if Current = controller.green then
				Result := "green"
			elseif Current = controller.yellow then
				Result := "yellow"
			else
				Result := "red"
			end
		end
end
 
class TRAFFIC_LIGHT
inherit
	ANY
		redefine
			default_create
		end
feature -- Creation
	default_create
		do
			light := red
		end
feature -- Access
	light: TRAFFIC_LIGHT_COLOR
			-- Current light
feature -- Modification
	turn_green do light := green end
	turn_yellow do light := yellow end
	turn_red do light := red end
feature -- Allowed values of `light'
	green: TRAFFIC_LIGHT_COLOR once ("PROCESS") create Result end
	yellow: TRAFFIC_LIGHT_COLOR once ("PROCESS") create Result end
	red: TRAFFIC_LIGHT_COLOR once ("PROCESS") create Result end
end
 
t: TRAFFIC_LIGHT
a, b: TRAFFIC_LIGHT_COLOR
...
create t
a := t.light
t.turn_green
b := t.light
io.put_string (a.out) -- Prints "red"
io.put_string (b.out) -- Prints "green"

As the example demonstrates we need to get rid of object identity to allow objectless calls.

The last property is already present in expanded classes without attributes. If we follow Occam's razor, there is no need to invent a new notion. Otherwise we can quickly get into the situation like "Doesn't Y already provide X? - Yes, it does, but we added Z and use it instead."

However, the classes that are supposed to be used in a specific way are better to be explicitly marked as such. My feeling is that the built-in Eiffel documentation system, based on note clause, is quite underused for this purpose. In particular, we may have an associated clause

note
	state: no
	identity: no
	storable: no

for the classes like these.

Inheriting from an ephemeral class

In reply to Ephemeral classes:

What would happen if I write a class that inherits from an ephemeral class?

ephemeral class A
feature
	objectless_feature do ... end
end
 
class B
inherit A
end
 
class TEST
feature
	g
		local
			b: B
		do
			create b
			b.objectless_feature
		end
end

This would always call {A}.objectless_feature, right? No opportunity for polymorphism? Or would class B be permitted to redefine objectless_feature?

Stateless classes

In reply to Ephemeral classes:

(This idea came to mind while reading Alexander's post below.)

Rather than "ephemeral classes", I think a better name would be "stateless classes".

Eiffel already uses too many idiosyncratic keywords, which I suspect may be a barrier to its wider acceptance: "deferred" vs "abstract", "void" vs "null", etc. The word "stateless" has been widely used for a long time.

The mechanism is ready for use

In reply to Ephemeral classes:

Talking about objectless calls, we can consider how objects are used. There are 2 properties tightly bound to an object:

state - attributes hold associated values
identity - reference equality can tell if the objects are the same or not even if they are in the same state

We do not care for identity of objects of expanded types. In other words we never know if an object of an expanded type is "the same object" referenced by some other entity (or an expression in general) or not.

From the practical point of view, if we consider a boolean expression a = b where type of a and b is the same stateless type (i.e. has no attributes), we can get different results if the type is reference, for example, because the equality can be preceded by

create a
create b

but we'll always get True if the type is expanded (the equality operator above refers to the standard object equality, not to some special cases, like NaN in floating point math, discussed elsewhere).

In the latter case there is neither state nor identity associated with an object: objects of the same expanded type without attributes cannot be distinguished in any way. Moreover, no special rules for using special entity Current are required, because it is safe to use it: there is nothing associated with it. Summarizing the above, Eiffel already has appropriate mechanism for "ephemeral" classes: they are expanded classes without attributes. Only the language specification needs to be updated to allow objectless calls on types, based on such classes.

The name was suggested during

In reply to Ephemeral classes:

The name was suggested during an ECMA meeting. It might not be the final name, but for the moment this is what we will use for testing this.

This mechanism is known in

In reply to Ephemeral classes:

This mechanism is known in the Eiffel world as reverse inheritance and was proposed many years ago. I don't have the details but this was looked at by the ECMA committee and dismissed for the time being because most likely it was not resolving a problem that users were having.

I wonder how compatible the

In reply to Ephemeral classes:

I wonder how compatible the idea of ephemeral is to "exherit"-ing from existing classes; essentially associating additional functionality to objects. The use-case would be, I have some common function I apply to an integer so it should be associated with an integer.

ephemeral class BLOCK
exherit
NATURAL_32
 
feature
 mix (other: BLOCK): BLOCK
  do
    Result := Current.xor (other)
  end
end
 
class APPLICATION
feature
 make
  local
   op1: NATURAL_32
   op2: NATURAL_32
   block1: BLOCK
   block2: BLOCK
   block3: BLOCK
  do
   op1 := 0xababcdcd
   op2 := 0x44444444
   block1 := op1
   block2 := op2
   block3 := block1.mix (block2)
  end
end

If one were to exherit from multiple classes, it would be similar to how generic conformance works. You can exherit the class as long as the object you're operating on statically conforms to the exheritance clause.

In my opinion this would be a cleaner way to define conforming inheritance.

To your original point, it would be nice to be able to define C callback code within Eiffel.