I think it is a good idea. But why the name ephemeral? I suppose the connection is with storables. And are the keyword frozen and deferred supposed to be allowed also? The combination of frozen ephemeral sounds particularly odd to me.

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.

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

1. state - attributes hold associated values
2. 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

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.

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?