Meditation on inside-out classes

[anno4000]

I'd like to draw the attention of those interested in the development
of inside-out techniques to a write-up I have posted on perlmonks under
http://www.perlmonks.org/?node_id=599394. It begins:

With inside-out classes it can be arranged that the class itself behaves
like an object, which I'll call its generic object. The generic object
can be initialized and normal accessors can be used with it to set and
retrieve values. It is, however, not a real object in the sense of a
blessed reference. Different classes have (represent? are?) different
generic objects.


What it amounts to is that every object method of such a class can also
be used as a class method.

It goes on to show how this can be implemented and mentions possible
applications. A brief discussion with other perlmonks follows.

Anno

 

[anno4000]

(e-mail address removed)-berlin.de ([email protected]) wrote
on MMMMCMXIV September MCMXCIII in <URL:^^ I'd like to draw the attention of those interested in the development
^^ of inside-out techniques to a write-up I have posted on perlmonks under
^^ http://www.perlmonks.org/?node_id=599394. It begins:
^^
^^ With inside-out classes it can be arranged that the class itself behaves
^^ like an object, which I'll call its generic object. The generic object
^^ can be initialized and normal accessors can be used with it to set and
^^ retrieve values. It is, however, not a real object in the sense of a
^^ blessed reference. Different classes have (represent? are?) different
^^ generic objects.
^^
^^
^^ What it amounts to is that every object method of such a class can also
^^ be used as a class method.
^^
^^ It goes on to show how this can be implemented and mentions possible
^^ applications. A brief discussion with other perlmonks follows.


I've used something similar - keying on class names, but not yet
for methods that could be called either as class method, or as
object method.

Interesting technique of mixing them, just don't make class names
consisting of just numbers. ;-)

Perl won't let me, not easily.

I'm somewhat worried about another aspect -- subclassing may not
work if one class supports "generic objects" and the other doesn't.

Suppose class "Base" has a method ->foo which it calls through a class
name, assuming that this will work as a "generic object". If a class
"Client", which is not so enabled, inherits from "Base", but overrides
->foo with its otherwise perfectly compatible own ->foo, things go
wrong when Base calls SomeClass->foo( ...). It could crash, it could
warn, it could silently do the wrong thing and it could even apparently
work under some circumstances.

In any case, the hallmark of inside-out classes, (almost) unlimited
inheritance, is compromised. In that view, I hesitate to encourage
the use of this technique.

Anno

 

[anno4000]

(e-mail address removed)-berlin.de ([email protected]) wrote
on MMMMCMXIV September MCMXCIII in <URL:^^ > (e-mail address removed)-berlin.de ([email protected]) wrote
^^ > on MMMMCMXIV September MCMXCIII in
<URL:
[...]

^^ I'm somewhat worried about another aspect -- subclassing may not
^^ work if one class supports "generic objects" and the other doesn't.
[...]

^^ In any case, the hallmark of inside-out classes, (almost) unlimited
^^ inheritance, is compromised. In that view, I hesitate to encourage
^^ the use of this technique.


Well, if you mask a method that is callable as both a class and an
object method in such a way it's no longer callable as both a class
and an object method, then that implementation is wrong. I don't see
that as being compromised. After all, what inside-out means is that Base
promises to SomeClass that its implementation of 'foo' will not restrict
how SomeClass implements 'foo'.

However, that doesn't mean SomeClass is free to change whatever the caller
is to expect from 'foo'. Inside-out is about promises up and down the
inheritance chain - not between caller and callee.

I believe you're right, I was over-anxious.

Any class would have to make public which methods are used as both
class- and object methods, for potential overriders to beware.
Whether the behavior is implemented via the "generic object" or
otherwise is irrelevant.

Thanks for clearing this up, I would have hated to deprecate the
neat feature.

Anno