On 10 January 2013 19:31, Igor Stasenko <[email protected]> wrote: > On 10 January 2013 18:29, Paul DeBruicker <[email protected]> wrote: >> On 01/10/2013 07:32 AM, Frank Church wrote: >>> >>> >>> >>> Thanks for the last answer which lists all the workspaces. >>> >>> My initial desire was to label my Workspaces and then copy the contents >>> of those which match some label and organize them into a kind of >>> collection. Similar to ScriptManager. >>> >>> So essentially I want to list all Workspaces whose titles or contents >>> match a substring, parse the contents further for some criteria and put >>> those matching into a list for review. Then from there put the right >>> ones into a permanent persisted collection. >>> >>> My intention is to do something like. >>> >>> | workSpaces textMorphs | >>> workSpaces := OrderedCollection new. >>> textMorphs := TextMorphForEditView allInstances >>> select: [ :morph | (morph firstOwnerSuchThat: [ :owner | >>> (owner >>> isKindOf: SystemWindow) and: [ owner model isKindOf: Workspace ] ]) notNil ] >>> >>> I want to capture all the matching Workspaces into the workSpaces >>> variable, by some method such as 'workSpaces[i] := textMorphs[i] >>> getWorkspace' and get the labelString of the Workspace, but it seems >>> that firstOwnerSuchThat returns a nil or notNil, rather than the actual >>> Workspace and it also seems redundant to get the list of Workspaces into >>> the workSpaces through iterating over the textMorphs variable as the >>> owner variable in the loop captures them at some point. >>> >>> So this question breaks down into 2 parts. >>> >>> 1. How can copy add the owner if it turns out to be a Workspace to the >>> workSpaces variable inside the loop (what is syntax) >>> >>> 2. How would I write a method such as : workSpace := textMorph >>> getWorkspace, with or without using firstOwnerSuchThat, ie a general >>> method of parsing the inheritance/ownership chain. >> >> >> I recommend you read through this: >> >> http://squeak.joyful.com/LanguageNotes >> >> >> 1. >> >> workSpaces:= >> >> TextMorphForEditView allInstances >> collect: [ :morph | (morph firstOwnerSuchThat: [ :owner >> | (owner >> isKindOf: SystemWindow) and: [ owner model isKindOf: Workspace ] ]) notNil ] >> >> >> 2. >> >> TextMorph>>getWorkspace >> |workspace| >> workspace:= self firstOwnerSuchThat: [ :owner | (owner >> isKindOf: SystemWindow) and: [ owner model isKindOf: Workspace ] ]. >> ^workspace >> >> >> >> Heres some for you: >> >> Why are you so resistant to using classes and so interested in using >> workspaces? Why invent a new way of using Smalltalk when you don't have >> the basics down pat? My point is you didn't know about #select: and you >> didn't know about #collect: but you do know that Workspaces are >> interesting and Classes and the Browser is not. Why not just put the >> contents of whatever you've got in the Workspaces into methods in a >> Classes you define and the you can call them whenever you want and >> persist them with the tools that have been developed thus far rather >> than inventing your own tooling while learning about Smalltalk..... >> > indeed. > I wonder why you (Frank) need such complicated way for doing things. > If you need a reusable piece of code, which you want to use more than 1 time, > classes is the best placeholder for them.. > > Even if you put things at class side, it helps a lot.. so then you can > just type: > > MyUtilsClass doThis > > MyUtilsClass doThat > > etc > >> >> Good luck >> >> Paul >> > > > > -- > Best regards, > Igor Stasenko. >
Hi Igor, I am new to Smalltalk but not new to programming and I am into my first 14 hrs into learning it with Pharo. As I was trying to work out the right syntax it brought to mind the thoughts of Brendan Eich, Gilad Bracha and Lars Bak who said the familar syntax (Algol/C style) of languages like Javascript, Go and Dart was chosen to make it easier for programmers familiar with C, Pascal etcetera to starting using. them, rather than learn a whole new paradigm, even at the cost of complicated parsing and language structure. If I was using Eclipse IDE for instance, at every step I could use auto-completion and the documentation to decide what follows from what, even in a domain I had no familiarity with, but Smalltalk doesn't lend itself to that approach. With spoken languages even without proper syntax or phrasing a person who knows the language can deduce what you are trying to say but with computers you either get it right or the computer stares back at you blankly. As an experienced programmer I am trying to accomplish something non-trivial as hard and as fast as I can with Squeak, Pharo and their supporting libraries and ecosystem and the only way is to bombard the mailing lists and forums. You could say I am trying to understand how the language constructs can support my intentions as fast as I can. >> >> >> Heres some for you: >> >> Why are you so resistant to using classes and so interested in using >> workspaces? Why invent a new way of using Smalltalk when you don't have >> the basics down pat? My point is you didn't know about #select: and you >> didn't know about #collect: but you do know that Workspaces are >> interesting and Classes and the Browser is not. Why not just put the >> contents of whatever you've got in the Workspaces into methods in a >> Classes you define and the you can call them whenever you want and >> persist them with the tools that have been developed thus far rather >> than inventing your own tooling while learning about Smalltalk..... >> > indeed. > I wonder why you (Frank) need such complicated way for doing things. > If you need a reusable piece of code, which you want to use more than 1 time, > classes is the best placeholder for them.. > > Even if you put things at class side, it helps a lot.. so then you can > just type: > > MyUtilsClass doThis > > MyUtilsClass doThat > > etc > >> >> Good luck With respect to the above I can truthfully say that at this juncture I don't know what it all means, from the theoretical view point, nor from the practical perspective of what I am trying to accomplish, which is why the questions are flying in so thick and fast. For instance yesterday I was thinking as to why the types/classes of the instance variables was not specified when I defined a class, in the way I would with Object Pascal and Java classes or record types, then it dawned on me that perhaps their getters and setters, together with other methods defined on them would define what in other languages would be their type. Thus it results in better understanding of the notion that in Smalltalk everything is an object and the methods it supports more or less defines its "type" Another thing - the topic of this thread is not so much concerned with Workspaces. I am more interested in scanning the workspace for any control capable of text editing and extracting the text from it. Workspaces are the first instance one comes across, and shift-clicking the editing area resulted in a TextMorphForEditView. So to do what I want I have to create a new kind of editing widget with TextMorphForEditView embedded it in it, or find an existing one and use/learn from/adapt it. In fact it is linked to SO 5592521 Last of all - teachers please, I don't want to go to Smalltalk kindergarten. I have done too much programming in my life to be put in kindergarten when I start Smalltalk. The problem here is although one can learn from reading examples, it can be hard to understand the language constructs unless they are derived from one's own use cases, and this is why my questions have been coming in so thick and fast. PS. The Stack Overflow ranking of a lot of expert Smalltalkers has an inverse relationship to their expertise, a notable exception being Frank Shearer (related to the footballer?) ;-) -- Frank Church ======================= http://devblog.brahmancreations.com
