Hi,
There is no menu item to inspect or explore the class of the inspected instance. Many constants hide in class variables and are harder to get to when there are no menu short cuts. Karl |
It's not much "harder" to get to in terms of number of gestures. You
can select "browse class" and, voila, there are your ClassVars, ready for printing or inspection. IMO, we should consider and encourage the idea that interacting with code in the browsers is as much a part of the IDE as the menus and buttons. <soapbox> This seems like a good opportunity to express my views about what Squeak is, or at least can be. It seems like there are two prevailing ideas in the community; one that Squeak should be like an "app" where the goal is to insulate the user from ever seeing code or the debugger, and therefore we need a widget (button or menu) for every action the user might ever want to do. The other prevailing idea is that Squeak is devevlopers-tool (like Eclipse, etc.) and should regard its users as full-on developers. It seems like every software out there wants to cater to one of those two groups, but not anyone who is looking for something else. Squeak has the chance to be that something else that empowers regular people who are not programmers, but very intelligent and wanting to use their computer for useful purposes -- if only they had an empowering software "application" other than, at one end, some kind of Office package (usable but not capable) and, at the other, Emacs and a C-compiler (capable but inaccessible to them). As another example, hiding the debugger to put up a generic error message in an alert box totally subverts the strengths and even the original vision of the Dynabook. It's supposed to be a personal computing system, the Debugger is the most useful and empowering browser in the system. The Squeak environment should never swallow its own bugs. Another example is breakpoints vs. "self halt". We have all this.... crazy stuff to support them; swapping out CompiledMethods, restoring them under certain circumstances, and even creating a new soft-dependency from Compiler to Tools! All this, just so the user can select "breakpoint" from a menu instead typing "self halt" in a method? IMO, "sparing" the user from interacting directly with the code is not helping them in the long run.. </soapbox> On Wed, Aug 26, 2015 at 6:10 AM, karl ramberg <[hidden email]> wrote: > Hi, > There is no menu item to inspect or explore the class of the inspected > instance. Many constants hide in class variables and are harder to get to > when there are no menu short cuts. > > Karl > > > |
On Wed, Aug 26, 2015 at 9:39 PM, Chris Muller <[hidden email]> wrote: It's not much "harder" to get to in terms of number of gestures. You It's not so much isolating the user from the system as making a practical system that group somewhat similar issues together. When I inspect a running instance I know I can browse it's class and get to the class variables. One of the biggest failures of Smalltalk is hidden state. When code behaves strangely and you are looking for clues, easy access is a prime quality. Look at this issue where you yourself missed a error because a class variable was nilled: <soapbox> Sometimes it is ok to dig into the underpinnings of a system, and get the whole developing environment. Sometimes you can't be bothered with a debugger, you just want to get the stuff you are working on done. To get somewhere you have to stand on the shoulders of giants and trust that they made the right choices. You can't always go down the rabbit hole. When I write this mail I don't want to debug TCP or know why the cursor change was lagging while I moused over a hyperlink. </soapbox> Karl
|
Free forum by Nabble | Edit this page |