Squeak-dev February 1998

squeak-dev@lists.squeakfoundation.org

110 participants
320 discussions

Re: Squeak as rogue-like gaming platform?!
by Steve Dekorte 28 Feb '98

28 Feb '98

>Of course, if you hose a fundamental proto, you've hosed the system >too. True, but the point is that you don't *have to* change the system in order to explore, but you are forced to with classes. >My main concern with proto-based systems is that the proto is the same >as its clones. So if, for example, you accidentally send an #at:put: >to the prototype Array instead of a clone, every subsequent new Array >will not be empty. This could introduce quite a subtle bug into the >system. That doesn't happen with classes, since Array is not an >array. (Experts, correct me if I'm wrong about this, please.) A good point, but again, that's only one particular implentation of a proto system that you're talking about. NewtonScript for example, allowed for "locked" protos (it even stored some in ROM). But you can make and use a proto system to have as many similarities with classes as you wish. You choose, instead of the language. Isn't the direction taken with Smalltalk? The old language thinking was to create a language for each type of application. Smalltalk(and OO) came along with the idea that the customization should be done at a higher level. Protos simply extend this idea further. Steve

1 0

Re: Prototypes
by Ken Dickey 28 Feb '98

28 Feb '98

>As Ken Dickey's suggested (early in this thread) you should take a look >at SK8. SK8 is a great idea mine and authoring environment with years of testing & tuning of ideas. I would like to point out that SK8's objects are more like Java Beans (though more developed and refined). They were designed for authoring and might be considered fairly heavweight for general use. Thinking of something SK8-like in the Squeak base, we should not lose sight of Squeak's goals w.r.t. simplicity, generality, etc. A low-level approach giving an easy to use authoring environment using heavier-weight prototypes on top of lighter-weight but perhaps more primitive objects is also a possible solution. I think that it is important to view cool environments like SK8 as idea mines but should certainly rethink the ideas in the Squeak context. The main thing at the core level is to have the capabilities for building higher-level objects which make authoring easy. If the SK8 (or other) object models make sense, we don't neccessarily have to push them down into the core feature layer. The main thing is to minimize the impedance mismatch. In SK8 we wrote a generic code generator which took a project/image and wrote the source to regenerate that project in SK8 or Java (or whatever). Java had a big impedance mismatch at the object level in that it was a lot of runtime work to implement the SK8 model. If Squeak were to support a Prototype model (or perhaps a class-instance model with per-instance specialization) the match would certainly be better than with Java. I would definitely suggest that people check out SK8--it is very cool, and I love the authoring capabilities--but lets be very careful at the same time not to do too much violence to the Squeak ideals in the process. I would rather build a SK8-alike on top of current Squeak than wait a year or two for the ultimate Prototype based OO model. Hey, now that I said all of that, take a look at SK8! It's GR8! 8^) [http://sk8.research.apple.com/sk8/sk8.html] Cheers, -Ken

1 0

Re: auto-delegate messages
by Mike Klein 28 Feb '98

28 Feb '98

> Hi, Mike: > > Thanks for the comments! This was just one of those "bolt out of the > blue" things, and I didn't know whether there was merit in it, or > underlying fatal problems that others have caught before. Hi. I just got bad news this week... No more Smalltalk. Only Java. I am pissed, so I'm trolling c.l.s and squeak-list to avoid the innevitable. > >A) He uses a single delegate. One could imagine having multiple delegates, > > with some sort of conflict resolution mechanism. > > Yes, I was thinking that you might want to have an OrderedCollection of > delegates for generality, but didn't want to whip all that up for a > simple posting. I used to "Half-jokingly" offer up the following model of MI: When an object recieves a message it does not understand, it randomly selects an variable that contains an object that CAN respond to the message and it forwards it to said object. If that's not weird enough, variables are search for, first in the lexical scope of the most recent context (thisContext), then in the lexical context of thisContext sender, all the way to the earliest stack frame. If that's not wierd enough, do the search by actually sending the message, and catching (or failing and possibly back-tracking) the DNU signal. Watch those DNU's disappear! One big advantage of Smalltalks's model is that static, single inheritence is good enough for 99+% of the code. If you want something more complicated, you are better off implementing it yourself (ala the scheme you outline, or something else) lest you wind up with a complex model that still doesn't do what you want (like C++, or the model I proposed above). There are just too many directions to extend a static, single inheritence model for one of them to be the end-all and be-all. Of course, Smalltalk sorely needs a richer MetaObject Protocol. (E.g. It would be nice to have a SlotDescription class whose instances would 'name' instVars, rather than using a String or Symbol) > > > >B) The delegate is static. If the interface of delegate changes > > (by any of a number of means, not the least of which is putting > > a different object in the 'delegate' slot) > > then the 'cache' of CompiledMethods may no longer be valid. > > Good point. Any ideas on how to detect and handle this? I would think > that the delegate class would remain rather static (as the purpose is to > emulate MI "mixin"), but other things could cause the "cache" to become > stale. It depends on whether you consider this a programmer's aid, or an implementation technique. -- Mike Klein

1 0

Re: auto-delegate messages
by Mike Klein 27 Feb '98

27 Feb '98

Great! A cross-post with c.l.s. I started to respond there, but I find the mailing list here homier... I just wanted to add some comments to Tim's approach. It is a good approach, and one that I've used before. A) He uses a single delegate. One could imagine having multiple delegates, with some sort of conflict resolution mechanism. B) The delegate is static. If the interface of delegate changes (by any of a number of means, not the least of which is putting a different object in the 'delegate' slot) then the 'cache' of CompiledMethods may no longer be valid. C) If the receiver is used as a delegate, #canUnderstand: must be over-ridden to search for an applicable delegation path, otherwise the receiver will appear to refuse to respond to a message that it actually would (through the reciever's delegate) D) He classifies the method under 'auto-delegate'. It is nice to know when you are over-ridding a 'programmatically' created method. This is just a specific instance of: 'It would be nice if the Browser warned when you change a method in a category different from the one you are browsing.' E) Although not relevent for Squeak (except for optimization), The Compiler may not be availiable at runtime. It is still possible To "fake" the compiler by creating methods methods by just piecing together the needed byte codes for methods of that form. -- Mike Klein > Hi, all: > > Here's a cute trick / crufty hack I recently posted to > comp.lang.smalltalk. It was in regards to someone complaining that they > had to recreate a bunch of methods when using a delegate to implement > multiple-inheritance-like operation. Instead of manually doing this > (painful) or dynamically doing this by implementing doesNotUnderstand: > (slow), why not combine the two and have the doesNotUnderstand: method > install the custom-created method? > > Comments? > > ---- > | I see. The basic Implementation pattern if I remember correctly. I > guess > | I'm just looking for something better. If I've got 20 methods in the > | implementation or "add-in" class, why should I have to write 20 new > methods > | that simply say: > | > | doSomething > | > | ^otherClass doSomething > | > | The extra effort is bad enough, but the unacceptable part for my is > that > | I now have to write code in several places -- each time I add or change > a > | mehod in the implementation class, I have to add/change the methods in > all > | the other classes that use it. > > Ah, but you don't have to write the code -- why not have the system do it > for you? Just implement a doesNotUnderstand: method that installs the > named method to reflect it to the "delegate" object (inspired by the > "auto-accessor" facility of Squeak): > > > doesNotUnderstand: aMessage > > | selector keywords selString | > selector := aMessage selector. > (delegate class canUnderstand: selector) > ifTrue: > [keywords := selector findTokens: ':'. > selector isInfix > ifTrue: [selString := keywords first , ' t1'] > ifFalse: > [selector isKeyword > ifTrue: > [selString := ''. > 1 to: keywords size do: > [:i | > selString := selString , ' ', > (keywords at: i) , ': t', i printString]] > ifFalse: [selString := keywords first]]. > self class > compile: selString , ' ^ delegate ' , selString > classified: 'auto-delegate'. > ^ delegate perform: selector with: aMessage arguments] > ifFalse: > [^ super doesNotUnderstand: aMessage] > > > -- tim >

1 0

Squeak as rogue-like gaming platform?!
by Ian Bicking 27 Feb '98

27 Feb '98

I was glad to see your post. I looked into the ORCS project a while ago, but got the impression they were going to use some odd C-like language, and so I gave up on it. A well-developed framework under Squeak would be great, I think, because it would bring a rich programming language and class library with it, as well as a very pleasant development environment. I've been looking into interactive fiction lately, and I think there's a lot to be learned from that. There's a few mature developement environments that exist for IF, and there's a lot of similarities between IF and Rogue-ish games. I've only started learning Inform (and I haven't looked at TADS or ALAN), but it's definately based heavily on a prototype-like system (nearly every object in IF is unique, so inheretence isn't a large concept). The more simulation-based Rogue-like games would certainly include greater numbers of similar objects, and would demand a better formed class hiarchy, but the prototype model would still probably be central. I agree that some syntactic sugar is necessary if Squeak is to be used. I don't know if it's really necessary to make it too C-like, though, except perhaps for political reasons. Some of the sugar in Python is nice, though. [if you really want to make the C people happy, maybe Objective C would make sense? Interpretted would be *very* nice, though] -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- || Ian Bicking | bickiia(a)earlham.edu || || drawer #419 Earlham College | (765) 973-2537 || || Richmond, IN 47374 | || -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

2 1

Re: Prototypes
by Ken Dickey 27 Feb '98

27 Feb '98

>[ ] With classes you know where all the code is. The Browser has all the methods. The methods are layed out in a spacial ordering. This is one way to remember how to get back to a piece of code. For reasons of sharing and selection of inherited vs idiosyncratic behavior, in the authoring environment it is useful to keep 'parents' and 'children' which allows for ST style hierarchy browsing. As the heap can be scanned to get this infomation, one might consider this knowledge as cached to allow for 'tree shaking'/liposuction to reduce image size. >The problem with prototypes seems to be one of self restraint... Perhaps we should offer the user the choice each time,.. I am definately all for helpful/supportive interfaces! Cheers, -Ken

1 0

Re: Prototypes
by Travis Griggs 27 Feb '98

27 Feb '98

Ted K. wrote: > The problem with prototypes seems to be one of self restraint. When you decide to make a subclass in the current system, it is a deliberate act. You pick a name, and consider what instance variables should be there. With prototypes it would take superhuman self-restraint to keep things neat and well-partitioned. > > A common error will be to forget to say "and apply this change to all object like me". Perhaps we should offer the user the choice each time, of whether this change applies to just this object, or to all similar ones. I would think, that be default, you would want the behavior to be "apply this change to all objects like me" and that creating instance specific stuff would require a cogniscent action (pressing a command key or something). Maybe we change the "Inspector" to include method browsing features, and you can make instance specific changes there. -- Travis Griggs Key Technology tgriggs(a)keyww.com To Smalltalk! - and Beyond!

1 0

Re: An entry point for scrollbars
by Ian Piumarta 27 Feb '98

27 Feb '98

> Similar interrupt sequences work on Windows and Unix, > but I am not sure what they are. For "command" (or "apple" or "flower" or whatever) read "ALT" on Unix. The interrupt key is therefore "ALT-.". Ian

1 0

Prototypes
by Steve Dekorte 27 Feb '98

27 Feb '98

Is there any interest in making Squeak prototype-based? Steve Dekorte

5 6

more prototypes
by jecel＠lsi.usp.br 27 Feb '98

27 Feb '98

It has already been mentioned that there are two ways to create new objects: - ask a factory object to build one from a kind of blueprint - ask a similar object for a copy of itself There is also an important variant of the first kind - ask a special factory (the parser) to build an object from a textual description, like #('help' with this 2) This is sometimes called "creating from nothing" (or "ex nilo" creation, or something equally silly) which is only accurate if we consider the parser to be nothing. One important use of classes is as a factory object that understands the #new message. We don't really need this, as cloning and literal object are quite sufficient. But classes also are used for reflection - they hold the meta-level information about their instances that is needed by the programming environment. If we eliminate classes, then we will need to create new objects (Self calls them mirrors) so we can still write the programming environment within the same language. So it would seem that nothing is gained by getting rid of classes, but this is not true as these mirrors can be created "on the fly" only when needed instead of having to hang around all the time. My own experience is that having to create classes before you can make an instance is as bothersome as having to declare all of your variable types. It is so much better to point to something on the screen, copy it, call up its definition and then start hacking away. With the ability to drag-n-drop objects, cleaning up the mess you make is hardly a chore later on. -- Jecel

2 1

Jump to page: