HaloO,
Stevan Little wrote:
On Oct 11, 2005, at 8:47 PM, Larry Wall wrote:
You seem to be arguing that a class has no state, but my view is that,
in the abstract, a class encompasses the state of *all* its objects.
It just hasn't picked one particular object to be at the moment.
I love this notion because that makes the type that the class represents
the potential state it would reach when *all* distinguishable instances
were realized---which needs a lot of memory for many classes. But the
bit class/type e.g. has exactly two distinguishable states! Well and
more then these two will never be needed if the algebraic, boolean type
is build with !, && and ||. Negation just exchanges the half of the
type that is in use, the former one is returned into potentiality,
that is, it leaves the programs actuality. The binary connectives leave
false and true in the program respectively as soon as both booleans have
entered the program! That is (1 && 0 == 0) and (0 || 1 == 1) dual each
other, just as the unrealized potential state of a class duals the actually
realized state of the instances of the class in any particular moment.
Here's a nice magic square picture of the idea:
-Class .. ::Class meta space
*--------*
| /|
| / | The diagonal line splits the potential(-) from
| / | the actual(+) instances. Undef and the ::Class
| / | are the "singularities" of the class. The state
| / | of the class moves up the diagonal through instance
| / | creation, while the GC moves it towards Undef.
| / |
*--------*
Undef .. +Class value space
No, not that class has no state, but that with the currently specced
classes we have inherited behaviors (class methods) but they do not
inherit the accompanying state (class attributes) as well. I see this
as potentially very problematic.
What do you mean with "not inheriting class state"? I would think that
beeing an instance of a class, an object should have access to the shared
class data, but it is not part of the per object state. Or do you mean
that class data is not accessable to the instances at all? I would hope
that this is 'hidden' in the scopes where the class's parts are defined
but of course accessable lexically from class support code there.
--
