Squeak-dev February 2002

squeak-dev@lists.squeakfoundation.org

202 participants
665 discussions

Re: [Modules] Upper case message names for accessing modules
by goran.hultgren＠bluefish.se 04 Mar '02

04 Mar '02

As Henrik wrote - there are other questions to tackle. It would be nice if you all reacted to the "minimal meta card" I talked about for example. :-) I am still "thinking" about the cataloging problem. It's a bit tricky to get something simple and still scalable. But... that was not the thing I wanted to say. The issue with "imports" should be rather small I think because hopefully Squeak will "auto import" a module during compilation - at least if there is only one module active that does define that name. Henrik? Ok, why don't I test it - so I did. I made a class with a method referring to Transcript. Compilation went fine and I guess that because Modules are still weak it even worked to run it without any neighbor modules. So ok, I need to do it explicitly, I ran the "self deepDeclareExternalRefs." from the explorer-thingy and then BAM, it added two neighbors: #(Squeak Language Core)* #(Squeak Language Collections)*) I am not sure why it didn't go all the way down to Streams... Even adding a reference to ReadStream didn't make it go there. It actually seems that these two modules are always neighbors - even with an empty method! How come Henrik? I tried referencing another of my own classes and that got discovered correctly. regards, Göran

5 8

Getting rid of metaclasses (Was: Behaviors vs Modules)
by Anthony Hannan 02 Mar '02

02 Mar '02

Nathanael <n.schaerli(a)gmx.net> wrote: > - A mixin may contain a meta-mixin which defines class side behavior. I was leaning towards getting rid of metaclasses. A class reference like "String" would instead reference the String prototype, and class methods would be moved to instance methods under an appropriate category like "instance creation". Class variables can be replaced by instance methods that store arbitrary constants, instead of just literals. This allows overriding without the need to use class instance variables. And the prototype can serve as an example (enhancing documentation) or as a real prototype to copy. The prototype (or any instance) would respond to #new the same as today by creating a brand new instance. It would respond to #copy by copying itself. So the user has a choice.

14 25

[VM] Plugins and namespaces
by Ross Boylan 02 Mar '02

02 Mar '02

I am trying to understand the interrelations between the different external and internal plugins, with an eye toward an enhanced Win32 build for VMMaker. I am concerned both with the names of files and functions. Here's my current working model. Is it correct? 1. The same file or function name may appear in two different plugins. 2. Consquently one should use a separate directory for each plugin. 3. The relevant include files for each plugin include those in its own directory and the general VM files only. 4. The build for the core VM should not include headers for any of the plugin directories. 5. Plugins access other plugins only through calls to the interpreter proxy, so do not need headers from the other plugins. 6. All the above statements apply equally to external or internal plugins. 7. Until recently, the namespace collision issues were theoretical, so it was possible to get away with a looser approach. However, the separations outlined above are the desired ones going forward. 8. For internal plugins, function names are prefixed by the module name to make them unique (not sure where that happens). For external plugins, the names are left as is; the lookup mechanisms specify the module and function name, so there is no problem. As a somewhat separate issue, can anyone comment on directory trees appearing under an individual plugin directory? It seems in some cases the plugins themselves have components.

3 4

How do you print?
by Jeff Bowman 01 Mar '02

01 Mar '02

Hi, I'm pretty new to squeak and smalltalk. Been at it for about 5-6 weeks now. I'm writing an application for a friend of mine, and I need to be able to print to a printer. The printer is most likely not a postscript printer, and it is most likely on a Windows computer (I happen to use Linux:) I can't find anything like a PrintStream or other object which would encapsulate printing to a printer. I have text (no graphcs at the moment but there will be in the future) to print which I can format as I like. I need to be able to create a button that says 'Print' the user can press and get a report. I've tried browsing and searching for print, printer, printing on the swiki, but no luck so far. Can someone help me? Jeff wolfb(a)bigfoot.com BTW, the code I have so far is at http://jeff.nontrivial.org if you have the squeak plugin for your browser, or http://jeff.nontrivial.org/cutlist/MyStuff.st can be filed in if you don't have the plugin working in your environment. -- __ / / (_)__ __ ____ __ / /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a /____/_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . .

2 1

RE: Modules and class... [ a off-topic question ?]
by Lex Spoon 01 Mar '02

01 Mar '02

> I think that it is mostly lack of experience in this space that is doing > the talking here amongst Squeak folks. I think my intuitive decomposition of classes and modules may be similar to others', so let me toss it out. A class primarily declares a number of instance variables, and holds a number of methods, and can be instantiated. It can also define variables in a local scope, but that's secondary and not even necessary if we have modules. A module primarily defines variables in a local scope. Theoretically, it could have instance variables, could have methods, and could even allow instantiation. These abilities are not only secondary, but might not be necessary at all. Looking at this, there isn't much of an intersection in the common uses. Why don't we just say that a class *has* a module (to hold class variables), and leave it at that? Of course, I haven't implemented a Smalltalk modules system and developed it over 10 years, so I may be being naive here. I just worry about equating ideas just because their implementations share some features. Conceptually the two things are different, and thus implementing them as the same thing is bothersome. This is the core of the language, so let's keep it as clean as we can! -Lex

3 4

Distributed Object Communication
by Lyle Bloom 01 Mar '02

01 Mar '02

As a neophyte Squeak user I need some recommendations on tools to allow distributed object communication between squeak images running on the same CPU as well as different physical computers. Is CORBA available? Is there a better alternative? Thanks, Lyle __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com

3 2

RE: Modules and class... [ a off-topic question ?]
by Lex Spoon 28 Feb '02

28 Feb '02

> Here are some more [deep] questions... Deep indeed! I've thought about them quite a lot, though, so my conclusions aren't changed by thinking them through again. While I don't have time to get too deeply into this discusison, I can share what thoughts I've already had on them. > Does a class define a type (or not)? > > What is "type"? > > How is "structure" distinguished from "behavior"? > > Are they one and the same thing w.r.t. a "type" or a > "class-specification"? Classes might or might not define a type, depending on what kind of type we are talking about. (I've rewritten this sentence a few times. It's a big discussion -- really, a family of discussions, depending on what you fill in for the "depending on" clause back there!) A class does define a structure and a behavior--in fact, that's seems to be the heart of what a class is. Structure is about static arrangement of data, and behavior is about dynamic happenings, but beyond that these words seem to bend for whatever conversation is at hand. A specification of something, including a class is some means of naming a particular instance. Often, a simple name is used. A definition of a class would give enough information to uniquely determine the class. A "class specification" might be the same as a "definition of a class". > ==== > > Does a class define a namespace (or not)? > > If not, then how does one specify what namespace scope(s)/things a > classes methods, or its instances method, can access? > > Where are those (namespace elements) things defined? > > How does one meta-object protocol extensibility for supporting different > types of "namespaces"? > > I.e., if the answer is not in classes then the design is the result of > not thinking in pure OO terms and reflection/meta-object protocol. > Well, today, classes define a namespace with class variables, and they *specify* some other namespaces which methods will, by default, have access to. I don't know where instance variables fit into this; there is a namespace of instance variables for each class, but that seems a little different than all the other namespaces being talked about. I don't think the namespace stuff is a core property of classes, though. It's open to design. You can just as well say that each class automamtically has its own namespace, and delegate it all to the namespace concept. Or, you can say classes *don't* define namespaces, but only import them. I'm okay with that, considering that the majority of classes define no class variables, and in fact that many class variables could be left at module scope, anyway. You could even say that classes don't mention namespaces at all, and that they must import everything from their surrounding module. That seems fine, too. Overall, the presence of modules seems to offload a lot of the stuff that has accrued in classes, and to give us some nice design options. Extensibility leaves me cold. I'd like to figure out *one* system of classs, modules, namespaces, etc., before worrying about how to let programmers develop other ones. For production applications, it even seems like a bad idea to define new kinds of namespaces. It in fact such a practice would even seem non-OO: OO design is centered around class (and interface) definitions, not language redefinitions. OO guys don't go to the drawing board and say "for this project, we could redefine global variables to work like this". They say "for this project, it makes sense to define Thingwitches and Frobnikas". This is Smalltalk, not Lisp, and in fact I'm starting to think a pervasive difference between the two language families is that Smalltalk picks some specific program organizations that work well, while Lisp leaves extremely basic things open to design. ie, in Smalltalk freedom comes from form, while in Lisp freedom comes from freedom. > ==== > > Does a module specify ownership (or not)? > > Is a module fundamentally a unit of packaging and deployment (or not)? > > Is "namespace" a role/protocol/behavior/interface/api, or an object > type? > A module probably has some ownership with it. A module is surely a unit of packaging and deployment -- and it's a heavy constraint! A namespace isn't necessarily any of the things in this list -- it simply includes a list of names. We can add more stuff to namespaces if we want, though. > What is the distinction between an "interface", a "class", a "behavior"? An interface is an abstract notion of the way an object will respond to certain methods. Interfaces are probably the first cut at how real programmers think about types in OO programs, and thus they tend to end up in a lot of OO type systems (OO type systems without interfaces, and without something to replace them, tell you something about the designer of that type system!) I don't know why we are talking about them in this discussion, though -- Smalltalk doesn't have interfaces in the language. Behavior and interface do have some similarity. Perhaps behavior tends to be more specific, and interface more abstract; but a very precise interface would seem to actually be a behavior. > > When you think about these ideas in terms of specific objects (or > classes) of objects, you're not thinking in OO terms. Behavior (the > message semantics an object understands/responds-to) are all that > matters here. *Boggle*. I don't know what "here" is, and I don't see how behavior is all that matters for *anything* that has shown up in this discussion. > We can formalize these into "interfaces" (or protocol api's if you > like). Any object which supports a given interface/protocol should be > able to perform in the "role" defined by that "interface/protocol". Yes, but where are the interfaces? This is Smalltalk. Interfaces are abstract, not a language feature, and that's a good thing -- OO type systems are either experimental, bad, or not automatically checkable. (I'm leaning more and more toward the opinion that types should be left for proof asssistants, and that trying to make them automatic is weakening the meaning of types so much that they aren't very useful.) To give an idea of the difficulties, note that in the wild interfaces tend to come in gradations: some objects have at:, at:put:, and keys, while others have the full Dictionary protocol. Some streams are readable, writable, and re-positionable, in any combination. Some have binary versus ascii mode. A readable, re-positionable stream is automatically peek-able, but some streams are peek-able even without being re-positionable. It's quite a morass, if you try to support the classes people write when they are unrestricted! Perhaps, instead of interfaces, you are talking about something like mixins? Or perhaps you have some stripped down notion of interface that is both useful and possible to implement? Do tell! > In considering these design issues it is important to view the system > from the meta-object protocol level, not the object-procotol level. > > I.e., think in terms of the object-model as defined by the meta-system. > Where we are describing/talking-about the structure of the meta-system > and its facilities. > Again, I'm left boggled. While I have my own mysticisms, it will take more than keywords for me to understand someone else's. Plain old logic and debate, though, I can handle. Okay. After this whirlwind tour, here's a summary on the question that spurred it off: classes: behavior, structure, namespace, maybe types, interfaces (though normally not in the program code) modules: ownership, namespace Are these really the same type of thing? They only overlap at namespaces. -Lex

3 2

Re: Serialization
by jescoto＠objective.com.br 28 Feb '02

28 Feb '02

Yes, that is, convert them to a byte representation and reconstruct them in another image. John M McIntosh <johnmci(a)smalltalkconsulting.com> To: squeak-dev(a)lists.squeakfoundation.org Sent by: cc: squeak-dev-admin(a)lists.squeakfoun Subject: Re: Serialization dation.org 28/02/2002 15:36 Please respond to squeak-dev >Ok, Squeak does. > >Is there any example, tutorial, paper or swiki page about how to serialize >instance objects in Squeak ? > >If the answer is "yes", could you, please, say where ? > >Thank you Well I'm not sure what you mean by serialization? Do you mean to convert them to a byte representation, transfer them to another location, and reconstruct them in another image? -- -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

1 0

Distributed Object Communication
by Bloom, Lyle 28 Feb '02

28 Feb '02

1 0

Camp Smalltalk 4 (registration deadline) March 4th
by John M McIntosh 28 Feb '02

28 Feb '02

Hey Squeakers, I should remind you that Camp Smalltalk 4 registration deadline is fast approaching. (March 4th) (Hint we need some more forms in). Yes it might seem a long way off, but *early* prebooking helps keep the rates down. http://wiki.cs.uiuc.edu/CampSmalltalk/CS4+Registration The location looks really cool http://home.navigators.org/us/gleneyrie/ The wiki is at http://wiki.cs.uiuc.edu/CampSmalltalk/CS4 But that doesn't tell the whole story, for that you need to check out some past experiences. For that you should look at http://wiki.cs.uiuc.edu/CampSmalltalk/What+is+Camp+Smalltalk It's a great place to go for a week of restful coding with perhaps some of the most experienced people in the smalltalk community. It is a lot of fun, but we also get a lot of serious work done for the community at large. Anyone, regardless of ability is welcome, certainly you get to learn alot about Smalltalk and about people you read about here, and on comp.lang.smalltalk. PS The venue lends itself to other things, so bring your families along. -- -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

2 1

Jump to page: