Squeak-dev January 2003

squeak-dev@lists.squeakfoundation.org

148 participants
312 discussions

Testers required: Windows Setup for Squeak
by Torsten.Bergmann＠phaidros.com 01 Feb '03

01 Feb '03

Hi, there is a 3.2 distribution of Squeak packaged as windows setup for the Squeak CD ftp.ira.uka.de/pub/squeak/SetupSqueak32-4956.exe Would be nice if some of the windows squeakers out there could test it on the different platforms (Win9x, Me, XP, W2k, NT) ... Thanks Torsten

5 4

Comments on Lex's "Object as Capabilities in Squeak"
by Mark S. Miller 01 Feb '03

01 Feb '03

[cross-posted to squeak-dev and e-lang] In rereading Lex's paper, Anthony's paper, and the Squeak-E thread on squeak-dev, there's a lot to say. I'm tempted to just jump right in and try to talk you guys out of dynamic scoping, just as Norm talked Dean and I out of it in the Joule-design days. I do think this is the most important remaining issue (though not the last one), but I think I'll instead build up to it slowly. It took Norm a long time to convince us, even when we already had a large base of common premises. I think I should first see what premises we all do have in common, and what premises we can come to have in common. I will start by commenting on Lex's paper. From there, I expect to go on to Anthony's, and then to the email thread. On first reading Lex's paper, I assumed that we were all trying to solve the same set of problems, and that Lex (and squeak-dev) has not yet realized the incompatibility costs of addressing these. On rereading Lex's paper, I think this is still probably true, but it strikes me that y'all may in fact only be interested in a genuinely less challenging subset of these problems, in which case y'all can plausibly address these at a much lower incompatibility cost. In any case, none of us can make informed choices until we understand what these tradeoffs are. This will be new exploration for me too, as so far I've mostly only thought about the more complete problem. All unattributed ">"-style quotes are taken from Lex's "Objects as Capabilities in Squeak", Aug2000 version, at http://minnow.cc.gatech.edu/squeak/uploads/2074/sandbox.html . For a first attempt at a taxonomy, let's try the following four levels of ambition: 1) Applet-like security: >In order to widely share Squeak pages across the Internet, it will be >necessary to engineer a safe display environment--a sandbox--for such pages. I've never heard of "Squeak pages" before. (My apologies again for my ignorance of Smalltalks post PPS2.5.) However, from the meaning I'm guessing, this sounds like a statement of purpose that could as well have been stated for Java applets. I would characterize this as: Instantiate safe "mobile" code. The applet-like instance can render into its window, receive ui events and interact with the user, but cannot exercise any of the user's authority nor modify any of the user's persistent state -- beyond the state understood to be part of the applet-like instance itself. The problem with applets is, they're useless. That's why you don't hardly see any. Their uselessness is precisely derived from a) their starting position of lack of authority (good), and b) the inability to incrementally and dynamically authorize them--well after they're instantiated--to do some useful job (bad). (See #2 below.) For those seeking only this level of ambition, I see nothing at all wrong with the mechanisms Lex proposes. (This is *not* to imply that these mechanisms aren't fine at higher ambition levels, or to fault Lex's paper for not articulating a more extreme goal-set. It's taken me decades to go from working on these problems to being able to explain what problems I'm solving, and I still feel like I haven't reached the halfway point on that journey.) I point this out so we can keep track of ambition-architecture correspondences as we go. When I say "I see nothing wrong", I'm referring specifically to Lex's paper. In particular, please don't take this remark as an endorsement of dynamic scoping (currently being discussed on squeak-dev) even for this first level of ambition. The paper transforms globals into per-process variables, where a process serves much the same function as a ClassLoader unit (the ClassLoader, all the classes loaded by that loader, and all instances of those classes) in Java's applet architecture. Either of these mechanisms would be candidates for the least incompatible change to Smalltalk in order to rescue "globals", rather than replace them. If relevant objects are partitioned between such processes (as I take Lex to be mostly trying to do), then the two mechanisms may even be close to equivalent. If y'all's ambitions really do stop here, it would be good to argue their relative merits, but I'm hoping we won't need this argument. (If the relevant objects cannot be so partitioned, such that the same object can be accessed from multiple such processes, then I would indeed argue, even for this ambitiion level, that process-scoping is wrong while loader scoping still looks acceptable. But I'll wait on that argument until it proves necessary.) OTOH, Dynamic scoping goes well beyond trying to preserve compatibility in order to rescue old code, and instead introduces a new linguistic concept substantially more complicated and questionable that per-process-scoping or loader-scoping, solves no further security problems, and moves Squeak away from the idea of object oriented programming. But I'm getting ahead of myself again. 2) Caplet-like security, one level deep: As safe as applets and as useful and usable as applications. http://www.skyhunter.com/marcs/securityTechComparisons/framed/goldenTriangl… Lex's reference to "pages" and the text spent on UI access leads one to expect that the user is able to operate the ui of untrusted code -- applet-like so far. In order to get beyond the sterile uselessness of untrusted Java applets, the user needs to be able to grant a caplet-like instance further specific authorities, as appropriate in order for the caplet to do some useful job on behalf of the user. Authorization must happen by intuitive user interface actions, enabling the user to "naturally" (without thinking they're thinking about it) maintain a model in their heads on the bounds of authority they've granted to different caplets, so they can naturally reason about the bounds on risk to themselves when considering another act of authorization. See http://www.sims.berkeley.edu/~ping/sid/ for an elaboration of these principles, and http://www.skyhunter.com/marcs/narratedIntros.html for a concrete system with UI (CapDesk) that implements 8 out of 10 of these principles. (Crucially, CapDesk turns the UI into a capability system using the same philosophy we're applying at the language level: turn each act of designation into also being the corresponding naturally-implied act of authorization. The user does essentially the same things he normally does. These user-interface actions are now understood to also have the security meaning that one would naturally expect. This is a bold claim. Look at the pages to see the system in action.) The above systems go out of their way to look conventional while obeying these principles. It would be a very different, and quite exciting, investigation to apply these principles to Croquet. Before speaking to what any of this might have to do with the architectural issues being discussed, I'll first wait to get a sense of whether y'all are interested in pursuing these overall goals. 3) Privileged security abstractions 4) Unprivileged security abstractions By a "Security abstraction" I mean something like the revocable forwarder shown as Figure 6 on page 6 of http://lfw.org/ping/capmyths/usenix.pdf . Such a security abstraction often stands between several different interests, receiving and manipulating authority on behalf of each of them. Such abstractions are also "deputies", as explained starting on page 11 of the same paper. Modern CPUs have a "privileged mode" and an unprivileged, or "user" mode. E is built on Java. Java code in the E implementation is like code run on the privileged instruction set, and E code is "user code". Lex has a similar distinction between "privileged" and "unprivileged" Smalltalk code, and I suspect he has to. No matter how similar these are made, they constitute two separate languages which need two separate names. Let's call then "Squeak" and "SafeSqueak". Unconverted legacy code that remains in the image is Squeak code, all of which is in the TCB. By "privileged" security abstractions, I'm attempting to define an intermediate level of ambition that may require less principled support. The issue is, how complete a language is SafeSqueak? It's easy to make it expressive enough to do applet-like things (#1 above). It's next easiest to also enable it to accept and use authorizations reified as capabilities-as-objects (in support of #2). But is the system such that SafeSqueak objects may find themselves between other SafeSqueak objects, each representing different interests? Is SafeSqueak a good language for writing security abstractions as deputies, in order to bring about cooperation without responsibility in such a system? If the answers are yes, then we're in #4. Otherwise, different unprivileged interests may still be represented by SafeSqueak code, but the security abstractions that stand between these interests are all Squeak code. In this case, we're in #3. To determine which of these apply, a good exercise is to try to rewrite the money example from http://www.erights.org/elib/capability/ode/ode-capabilities.html#simple-mon… in SafeSqueak. I would like to see Squeak evolve into a system that can support #4. I would hope y'all do as well. Only with #4 can SafeSqueak be a self-contained language, and Squeak become a shrinking legacy. A note on consensus: Above I've repeatedly talked about finding out what "y'all" want or believe. I don't imagine y'all are a collective, any more than I imagine e-lang is. I'm just referring to the sense of the community that I hope to gather from the reactions. ********************************************************************** In the section >The ObjectInspector Capability a set of methods are listed. #realBlockFor: is missing, as it is mentioned in the section >The ObjectInspector Capability as >realBlock := ObjectInspector realBlockFor: aRestrictedBlock The ObjectInspector design seems sound, as a super-powerful part of the TCB, to be closely held within the TCB, in order to build things like privileged debuggers. (Unprivileged debuggers are hard, even in #4 architecture! KeyKOS and EROS do it. E does not.) It seems to me that ObjectInspector can be refactored in a way that would make it both more convenient, and would naturally subdivide authority, simply by currying it. I assume that the listed methods of ObjectInspector are class methods, as shown by the above quoted use. Let's say that all these were instead instance methods, and that ObjectInspector instead had one instance variable and one "new:" class method. Then, instead of writing x := ObjectInspector instVatOf: obj at: i you'd write: x := (ObjectInspector new: obj) at: i The cool thing is that (ObjectInspector new: obj) evaluates to an object giving encapsulation-breaking, meta-level access only to the state of object "obj" rather than the system as a whole. This is a small but crucial step toward non-privileged debuggers, if you wish to get there eventually. ******************************* In the section on Literals, you seem to use immutable and read-only as synonyms. I find this confusing. To me, "read-only" means I can observe the current state but modify it. It doesn't mean the state won't change. And if the state to which I have read-only access does change, I expect to be able to observe the new state. Do you indeed mean "immutable" everywhere you say "read-only"? ****************************** The section "Dynamic Variable" seems to be to explain only per-process variables. Is this right? Could someone explain about "World"? This section refers to "methods that are marked as privileged". Even after reading the later section that explains this, I didn't feel like I understood how this marking happens, or how the authority to do this marking is controlled. >are still be able to access variables Bad "be" Can the same dynamic-variable-using instance be invoked from different processes (causing different bindings of the same use-occurrence of the same variable), or are dynamic-variable-using instance partitioned among the processes that can invoke them. Unfortunately, I suspect it's the first, but I'll wait to find out before arguing against it. ************************************ >Whenever code is loaded from untrusted sources, it should be loaded into >unprivileged methods. I'm not sure how to read this. If the code includes methods that were written assuming they would run privileged, what happens? >Processes with direct access to I don't understand what this means, but it alarms me. In a capability system, we should be speaking only of objects having access to other objects. I know that Processes are objects, which is good, but I don't think this accounts for what you mean. ***************************** Are restricted classes (as implemented by the restricting proxy) read-only? (I mean, genuinely read-only, not immutable.) I think they should be. > In particular, many class methods return "self" This reminded me that Smalltalk methods by default return self. E had a different but similarly dangerous policy. We found to our terror that this was a pervasive source of accidental security holes in our code, very much along the lines of the specific security hole you found with classes. Rather than making a custom repair for each individual case, I fear that you'll find you'll want returns-to-SafeSqueak to return null, rather than self, by default. This is the first issue I've encountered that makes Java easier to tame than Squeak. In Java, methods are void return by "default". ("default" is a funny word. It's still explicit, but is the path of least resistance.) >required to allow access one of these Typo: insert "to" ************************** >An incomplete list of such methods is the following: I would be very interested to see the complete list of methods on Class, ClassDescription, Behavior, and Object that you consider safe. It's much more important to review the list of what's allowed than the list of what's disallowed (though you made the right choice of which to list for the paper). I don't understand why you allow instaVarAt: and instVatAt:put: on non-proxies? Does this include non-proxies written in SafeSqueak? I completely did not understand the section "Characters and Symbols", probably because of my ignorance of modern Smalltalks. Could you expand? ********************* >This proxy might or might not immediately install the cursor as requested, >depending on the precise security policy that is being implemented. Implemented by whom, how? This is the first I've seen of "security policy" used this way. ******************** I would hope to convince you that shared-memory multi-threading, locks, semaphores and such should not be part of SafeSqueak. But, scoping and partitioning issues aside, this is a mostly separate discussion we can leave till another time. ******************** You don't actually explain what the issue is with Exceptions. ****************** >In particular, the following primitives should be disabled: > >* instVarAt: and instVarAt:put:, because they allow directly breaking > confinement > >* at:, basicAt:, at:put:, and basicAt:put:, if the proxy has indexed fields, > because they would allow directly breaking confinement I think I understand the others, but what's the problem with #at: and #at:put: ? >Additionally, #shallowCopy and #clone make revocation much more difficult; >thus, they should most likely be overridden to return the receiver instead >of returning a true copy. If you can't support their contract (and indeed you can't), then shouldn't you just suppress them? >Note that all non-primitive methods from class Object may be safely left >accessible. Since such code must consist of message sends between >parameters, self, and globals, user code could emulate the code even it it >were disabled, and so disabling such methods gives no gain in security. Are all the globals accessible from methods on Object necessarily accessible by both callers and subclasses? ******************************** >A primary advantage of the submemories approach is that there is no need to >add a special kind of cross-memory oop Given the stated purpose of submemories, you need to be able to reclaim a submemory without being able to reclaim the parent memory. This means that oops from the parent into the sub need to spontaneously seem to become some innocuous object (like null) when this happens. I think you will find support for this hard at fine-grain. E supports this only between vats, where there's an enforced indirection through intermediate objects anyway, and where the possibility of partition is part of the semantics anyway. In any case, I recommend postponing further worry about resource controls and denial of service until these other issues settle down. ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

7 13

Re: Dynamic scoping
by Allen Wirfs-Brock 01 Feb '03

01 Feb '03

At 11:46 PM 1/30/2003 -0500, Anthony Hannan wrote: >... >Allen Wirfs-Brock <Allen_Wirfs-Brock(a)Instantiations.com> wrote: > > The topic at hand is dynamic "variable" scoping. > >I prefer messages to variables because they are more powerful and >general. It allows more sophisticated queries, instead of just >returning a fixed value. I guess I'm just proposing another form of >exception handling, where exceptions are distinguished by selector >instead of class, that is why I reused #on:do:. > >I even like to think of global variables as messages sent to Smalltalk >or the class's environment/pool. Like Self, no variables just objects >and messages. The reason I quoted "variable" above is because the majority of the recent discussions and proposals concerning "dynamic scoping" have not been about scoping actual variable references but about a mechanism and message protocol for creating a dynamically scoped name/value association context. Almost all the proposals I have seen use some message protocol to accomplish this. The only alternative would be to change the Smalltalk language (and hence compiler's) definition of variable reference such that they are dynamically rather than lexically scoped. For now, I will simply assert that this would be a bad idea. Something you may want to consider is what constitutes the difference between a language extension and a new language. A good language extension should add the desired functionality in a way that is both program and programmer compatible with the existing language. In the absence of it's use, an extension shouldn't change the behavior of any existing programs and probably even more importantly, it shouldn't change any programmer's conceptual understanding of the language. If an extension doesn't have these characteristics then what you are actually doing is defining a new language. This may be appropriate in some circumstances but if that is what you are doing you need to be up front about it. "Self" is a Smalltalk-like language but it is clearly a different language. If you want to define a new Smalltalk-like language that is your prerogative, but don't try to sneak it in as part of a focused functional extension to the existing language. You still seem to want to have some sort of commonality between exception handling and dynamic "variable" scoping. I suspect this is your language implementor persona getting in the way of your language designer persona. Clearly, exception handlers use a dynamic scoping mechanism and it has been demonstrated that dynamically scoped name/value associations (fluids would be a fine shorthand for that phrase) can be implemented using the Smalltalk exception mechanism. However, that doesn't mean that exceptions and fluids are the same thing. I assert that a programmer who needs to establish an exception handling context is thinking about something very different from a programmer who needs to establish a fluid binding context. You will only create confusion, if you try to make them look the same. Equating exceptions and fluids would also unnecessarily limit your implementation alternatives. It would not be at all surprising to discover that the usage patterns of exceptions and fluids are quite different and call for differing optimization strategies. For example, you might discover that "shallowing bind" mechanisms are better suited for one and "deep binding" mechanisms for the other. Another good language design rule is to optimize the design of a feature for its most common usage. In this case I'm pretty confident that the most common usage would be a fixed value binding. While an "active value" (a block evaluation) is more powerful, it isn't going to be the most common usage. By requiring a block for the bound value you are complicating the most common usage and introducing likely error scenarios that would not exist for fixed values. It's fine to provide an alternative "active value" form but don't force everybody to use it all the time. >To satisfy your design principles, we could change the syntax to: > >foo > Context bind: #world toDo: [myWorld] during: [self bar]. > >bar > Context world. > >Context would be an object that only understands #bind:toDo:during: and >#doesNotUnderstand:. #doesNotUnderstand: would search the sender chain >for the first #bind:toDo:during: context for the message's selector and >execute its toDo: block. I believe this syntax satisfies the design >principles you mention below. Aside from the block as the second argument, my main concern is the #doesNotUnderstand: trickery. Another good Smalltalk design principle is: don't use #doesNotUnderstand: to create surface syntax. The virtual machine implementor will have made optimization trade-offs based upon observed or projected usage of #doesNotUnderstand:. What if the usage patterns of fluids are very different from those and suggest the need of a higher level of optimization? In your design, you don't have a local optimization alternative. You are going to have to tackle optimizing #doesNotUnderstand:. So, my preference (using this vocabulary) would be: foo Context bind: #world to: myWorld during: [self bar]. "ok to keep #bind:toDo:during: as an alternative" bar Context bindingOf: #world. If your concern is the verbosity of #bindingOf: I would go with the symbol based protocol: foo #world bindTo: myWorld during: [self bar]. bar #world binding I suspect that the verbosity is probably not really a big issue as I suspect that most of these binding should be encapsulated in other methods. For example you might expect Morphic class to define: use: aWorld during: aBlock ^Context bind: #world to: aWorld during: aBlock. currentWorld |w| w := Context bindingOf: #world. w ~~ nil ifTrue: [^w] ifFalse: [^World] Allen_Wirfs-Brock(a)Instantiations.com

1 0

Re: Dynamic scoping
by Lex Spoon 31 Jan '03

31 Jan '03

Anthony Hannan <ajh18(a)cornell.edu> wrote: > Hi Allen, thanks for responding, and thanks for the language design > principles. > > Allen Wirfs-Brock <Allen_Wirfs-Brock(a)Instantiations.com> wrote: > > The topic at hand is dynamic "variable" scoping. > > I prefer messages to variables because they are more powerful and > general. It allows more sophisticated queries, instead of just > returning a fixed value. I guess I'm just proposing another form of > exception handling, where exceptions are distinguished by selector > instead of class, that is why I reused #on:do:. That's interetsing, but it seems to make a nuisance of the vast majority of cases, where you are binding a plain-jane variable. Also, I'm not sure if it's a good idea that what looks like a variable can now have a block sitting behind it. Variables are a fundamental part of understanding how code works, and it would be nice if they behaved according to the expected rules. Computers are already full of rules that are "mostly" true, and everyone has had debugging experiences where 2+2 returned 5 or some other bizarre htings, because they are using rules that are just mostly true. It is nice if I write a variable and immediately read from it, I know I'll get the value back (barring multithreading, which granted is a "mostly" rule itself!). The blocks approach may make more sense in Self, where people are used to the ambiguity of variables and methods. In short, I love the implementation idea of tracing the stack to find your context, but I don't like the user-level invocation, either. -Lex

2 1

RE: Dynamic scoping
by Brian T Rice 31 Jan '03

31 Jan '03

I really don't want too much to be made out of it, since Slate (http://slate.tunes.org) is essentially in a coccoon metaphorphosizing (being bootstrapped), that I can't give you a system that does all of this Right Now. However, I must mention that you can achieve nested lexical overrides without invoking dynamic scoping through the use of macros, i.e. compile-time code expansions, which Slate handles in a nicely-compatible way with existing Smalltalk. Slate also has the property that methods do not return "self" implicitly, as mentioned earlier, and that the global namespace is rather heavily structurable. It also allows for a fairly uniform package structure which is amenable to capability analysis, but this has not been fully-developed yet, only outlined. I have followed the E and Squeak-E dicussions with great interest, and will certainly be incorporating ideas as I can into Slate. Anyway, that's my reluctant plug-of-the-month. -- Brian T. Rice LOGOS Research and Development mailto:water@tunes.org http://tunes.org/~water/

1 0

Re: Comments on Lex's "Object as Capabilities in Squeak"
by Anthony Hannan 31 Jan '03

31 Jan '03

"Mark S. Miller" <markm(a)caplet.com> wrote: > At 12:26 AM 1/31/2003 Friday, Lex Spoon wrote: > >The main thing you'll care about is that, during the money exrecise, I > >became completely convinced that dynamic class lookups are bad. > > That's a real relief. But before I'm too relieved, is there anyone else who > still thinks that dynamic scoping should be part of the Squeak, Squeak-E, or > Croquet efforts (or any decent oo language, for that matter)? Yes, exception handling needs dynamic scope, doesn't it? Do you propose handling exceptions differently? Cheers, Anthony

1 0

Squeak on Dell Axim X5?
by Nils Kassube 31 Jan '03

31 Jan '03

I'm looking for a replacement for my aging Palm IIIx and Dell's new and cheap PocketPC Axim X5 looks interesting. However, I want to play with Squeak on the road -- so has anyone tried this before?

1 0

RE: World Morph (was: Comments on Lex's "Object as Capabilities i n Squeak")
by Withers, Robert 31 Jan '03

31 Jan '03

hmm, you predicted my vote correctly. Let's add together the probability of confirmation from Avi, Hans-Martin, Lex, Stephen, Anthony, and Andreas and presume that superposition works. Let's count it as a full vote! ;-) cheers, rob > -----Original Message----- > From: cg(a)cdegroot.com [mailto:cg@cdegroot.com] > Sent: Friday, January 31, 2003 12:22 PM > To: squeak-dev(a)lists.squeakfoundation.org > Subject: Re: World Morph (was: Comments on Lex's "Object as > Capabilities > in Squeak") > > > Mark S. Miller <squeak-dev(a)lists.squeakfoundation.org> said: > >At 01:05 AM 1/31/2003 Friday, cg(a)cdegroot.com wrote: > >I think this would be great. With such a more specialized > list, we could > >also stop cross-posting to e-lang. > > > That's Rob, you, me. Two more and I set it up :-) > > >Since Squeak-E is more Squeak than E, I'd rather see this as a > >squeakfoundation list. Can someone there set it up? > > > When quorum is reached, I'll do so. I have a Squeak-JA list pending > anyway, so if two people shout 'yes' you will enjoy the side effect of > making some Japanese Squeakers happy ;-) > > -- > Cees de Groot http://www.cdegroot.com > <cg(a)cdegroot.com> > GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F > E098 9E8B > Cogito ergo evigilo >

1 0

Squeak-E List Vote
by Brent Vukmer 31 Jan '03

31 Jan '03

I'm interested in subscribing! -----Original Message----- From: cg(a)cdegroot.com [mailto:cg@cdegroot.com] Sent: Friday, January 31, 2003 12:22 PM To: squeak-dev(a)lists.squeakfoundation.org Subject: Re: World Morph (was: Comments on Lex's "Object as Capabilities in Squeak") Mark S. Miller <squeak-dev(a)lists.squeakfoundation.org> said: >At 01:05 AM 1/31/2003 Friday, cg(a)cdegroot.com wrote: >I think this would be great. With such a more specialized list, we could >also stop cross-posting to e-lang. > That's Rob, you, me. Two more and I set it up :-) >Since Squeak-E is more Squeak than E, I'd rather see this as a >squeakfoundation list. Can someone there set it up? > When quorum is reached, I'll do so. I have a Squeak-JA list pending anyway, so if two people shout 'yes' you will enjoy the side effect of making some Japanese Squeakers happy ;-) -- Cees de Groot http://www.cdegroot.com <cg(a)cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B Cogito ergo evigilo

1 0

Re: World Morph (was: Comments on Lex's "Object as Capabilities in Squeak")
by Mark S. Miller 31 Jan '03

31 Jan '03

At 10:11 AM 1/30/2003 Thursday, Anthony Hannan wrote: >World is the top Morph in the tree of morphs that automatically gets >displayed and refreshed on the Screen. A button would have a parent >morph, such as a window; the window would have a parent morph, such as >the World. You add a morph by creating it with all its submorphs, then >adding it to the world. For example: >"World addMorph: (SystemWindow new addMorph: (RectangleMorph new position: 100@100))" >(go ahead execute it). Thanks, it worked. So "World" is just the root Morph in the Morph tree? That makes sense. But then I'm confused why we have a problem. When would a method of an object refer to World by name? I see why the above code needs to refer to World by name: it's a top-level expression to be doit-ed, which puts it in the same category as E command-line expressions. The doit/printit/inspectit commands should probably evaluate their expression in a top-level privileged scope containing bindings representing all the user's authority, just like E command-line expressions. (Yes, this is equivalent to what it does now, just described in terms of the proposed distinction with the part that would change -- the scope methods defined in, which would be a safeScope.) (Given pure lexical rules, and methods being defined in scopes with no authority, then all authority used in such top-level expressions will be statically apparent, so the user-programmer has a chance of making an informed decision on this grant of authority. Non-programmers, who can't understand the authority implied by the code they're seeing, should probably not use the doit/printit/inspectit commands on an image where they may encounter example code they shouldn't trust. Alternatively, different workspaces could be provided in which powerful authorities are absent or virtualized. Does the doit/printit/inspectit already use a scope according to the Workspace? If not, would this be a problem?) However, if a method of an object contains code like your above example with a hard coded global reference to World, then, when invoked, it will insert the new Morphs directly under the root of the Morph tree instead of putting the new Morphs where their instantiator or caller wants them. This is a failure of virtualizability -- an important kind of polymorphism and late-binding. Remember my trivial "zippy" file example. Likewise, a morph-creating-object should have an instance variable or parameter for a parent Morph. The object may be coded under the assumption that this parent Morph will indeed be bound to World. But as long as the instantiator provides a Morph which acts World-like, the object shouldn't be able to tell the difference. As far as it's concerned, the provided Morph is the World. Hard coded globals references to mutable state or to authority conveying objects is a form of early binding. Morphs deserve full polymorphism! I suspect that, even independent of security, this kind of early binding is just bad oo programming practice. Can you provide any examples that motivate including hard coded global references to World inside methods of objects, other than in example, demonstration, or testing code? I do have an installed Squeak (I'm not sure how old) so feel free to just tell me where in the image to look. Thanks. ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

2 3

← Newer
1
2
3
4
5
6
7
...
32
Older →

Jump to page: