[Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak

[Paul D. Fernhout]

Ian Bicking wrote:
> Some things other people have done (like Logix: 
> http://livelogix.net/logix/) makes me think that this could be done in 
> CPython now, with just some fiddling in the compile process.  I think 
> the Python object model (which can't easily be changed) is already 
> flexible enough for this.
> 
> And ignoring some syntactic details you could do this in current CPython.

Interesting concept, to put it mildly. And also interesting under "future 
work" they say:
   http://livelogix.net/logix/future-work.html
"Although Python has provided a great launch pad for Logix, we may switch 
to another platform at some point. Efficiency and security are two areas 
that are somewhat lacking with a Python foundation. What are the 
alternatives? Maybe Mono, maybe Parrot, maybe C--, maybe LLVM..."

I know that is one of the reasons I still think about doing something (at 
least proof of concept) in Jython -- because it can piggy back on the Java 
JVM security model, and I might also consider writing a low level routine 
for handling networked programming in Java (if speed was an issue, after 
doing it all first in Jython). [But, I've also been looking at working 
with the Idle codebase too, by building on its RPC functionality.]

Still, the less I can mess with the syntax the better, I think. That's why 
I lean towards just having one "Prototype" class.

>> I think that Ian's suggestion is the most sensible strategy for 
>> proceeding
>> in that direction and continuing to maintain community interest in a
>> PySqueak inclined towards Self-like prototypes and a related GUI for
>> constructivist educational use (and other general use as well).
>> And if metaclasses turn out to not be the best approach,
>> still anything simple which preserves the Python syntax
>> while giving the new features (say, having all prototypes inherit from 
>> a common class which overrides __getattr__ and __setattr__ to
>> simply look into the instance to find data and behavior?)
> 
> I think it could be easier than that.  I think a lot of the more 
> declarative programming I do really has prototypes underneath it. 
> (Ironically in Javascript I never find a need for prototypes, except to 
> simulate classes.)  

Of course, you probably don't have a Self-like environment for Javascript. 
:-) Or is there one? I've never done much with JavaScript.

I did once listed about 100 reasons to use VisualWorks Smalltalk over C+++ 
without having to talk specifically about object-oriented programming 
issues -- just focusing on the environment and the libraries and the VM 
and issues like garbage collection and integrated fine-grained version 
control.

Anyway, I tried to follow your example, but I am still left confused as to 
how it is easier than creating GUI tools that manipulate all instances of 
just one Prototype class? Your example still seems focused on making 
classes. With one class, a few lines of code to search for values through 
parent slots and you're done? Essentially, for any prototype-ish work, one 
would just work with instances of this one class. Am I missing somethgin 
vital here? Are you thinking about one class per one prorotype object? Is 
that for performance reasons?

Consider:

 >>> class Prototype:
...   def __getattr__(self, name):
...     print name
...
 >>> x = Prototype()
 >>> x.spam("hello")
spam
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: 'NoneType' object is not callable
 >>>

Of course it fails trying to call the None returned by default in 
__getattr___ because the code just prints the field name, but you see I 
could just have that __getattr__ method look into a field of the object 
and return the function, or if it was not there, then start looking into 
parent slots and recursing until it found it or gave up with a call to a 
"does not understand" function (itself hookable).

I do think there might be issues to resolve in how instances of this class 
interact with other python classes. But I am not sure how complex those 
issues are, since everything to Python still looks just like a typical 
python class. All calls work the same way? Or do they?

The issues might have more to do with the GUI and it being able to handle 
dealing with instances of other classes, but that could be done in the 
usual way such as with inspectors and such that Idle defines. A bit 
klunky, but probably serviceable as a start?

Anyway, something to think more on. A proof-of-concept Prototype class and 
a GUI to manipulate it should not be that hard. (Famous last words. :-)

Designing programming systems is so easy when you stop caring about 
performance (at least in the short term). :-) But the advice I was given 
long ago is, slightly updated, is: by the time you get it debugged and 
anyone has noticed it, computers will be fast enough to run it. :-)

Anyway, are there compelling reasons why creating one class per prototype 
is useful or better? Or maybe I am just missing something here.

Perhaps it is confusing in that we are talking about two issues. One is 
saving the state of a running Python program with arbitrary classes and 
instances which you have modified while it runs, and the other is an 
application building process centered around prototypes with classes being 
more a legacy thing.

> I'm not really sure how to fit HyperCard into this -- I don't have a 
> strong feel for what it really means.  I suppose one aspect is that the 
> source code is not at the core; instead the card stack is (or whatever 
> content-centric metaphor you use), and code is attached there.  Ad hoc 
> structured code doesn't work that well with a class... you get something 
> like:
> 
>   class Foo:
>       def bar(self)...
> 
>   foo = Foo()
> 
> And the class/instantiation is just a kind of boilerplate.  OTOH, 
> modules are another model; if each content-context (aka card) was a 
> module, you get some of the structure without the conceptual overhead of 
> the class.

Yes, it would be that simple using classes I think.

Or it could be done using prototypes:

p = Prototype()
p.border = "dotted"
p.background_color = "red"
p.foreground_color = Color.red # if allow mixing classes and prototypes
p.parent = CARD_TEMPLATE_PREVIOUSLY_DEFINED

But I kind of see HyperCard as more like just one set of widgets in a 
Morphic style interface.

Have you had a chance to watch the Self video?
Another source for it:
   http://www.smalltalk.org.br/movies/
If you haven't, I recommend it highly.

--Paul Fernhout