text: Board index » Smalltalk
  All times are UTC
  >.*-*-*.com/
  > If static typing improves code quality by eliminating a class of runtime > errors, why don't we all use type systems that can detect these > problems? It should lead to much better software quality. Why don't we > use type systems like that to do all of our development?
  That is not *really* a solution. You are just moving the problem around - and then claiming it is not on your patch anymore.
  Detecting array bounds overflows at compile time is ultimately an insoluble problem - much like Turing's halting problem. You can't deal with the general case - only a few simple instances.
  So the premise of your argument is wrong - you can't *really* detect array bounds overflows at compile time - not all of them anyway - not while you are dealing with a Turing complete programming language. -- __________
  > i, personally, find it butt-ugly if "defaultBackgroundColor" is part of the > Object class, and would like to avoid using or producing software that > involves things like that.
  Most commercial Smalltalk environments are highly modular and allow extension through subclassing as well as by class extension. In my VisualAge Smalltalk environment, the core Object class only defines 28 methods. If I select the core definition of Object, that is all that I see. That said, their are dozens of sets of class extensions defining hundreds of additional methods (none of them are "defaultBackgroundColor" though). If I don't use any of the frameworks that define those additional methods, none of them become part of my packaged application. In fact, I don't even see any of those additional methods in the browser unless I actually select one of class extensions that define them..
  -Eric
  > > i, personally, find it butt-ugly if "defaultBackgroundColor" is part of > the > > Object class, and would like to avoid using or producing software that > > involves things like that.
  > Why?
  DISCLAIMER: i am expressing and explaining *my* personal preference here. i have no inclination or intention to try to convince you or anybody else of it. (it seems this sort of thing is necessary when discussing stuff like this in this community. sorry.)
  >.
  as to "modular": the way i apply the term to programming languages the "modules" are the lexical units what interact with each other whenever feasible through explicit contracts.[*] in an object-oriented languages i want to use, these units correspond to conceptual entities, usually classes, which would imply that modules cannot be modified, since two distinct lexical units would correspond to two distinct classes. what precisely are the modules in smalltalk? it's certainly not the classes. parcels perhaps? how explicit is their interaction with each other? what happens if their modifications to the global class tree clash? when is this detected and how is it fixed? the answers i have had from smalltalk on these and related issues so far seem to suggest to me that at least my idea of "modularity" is not very well supported there.
  again, i am just trying to illustrate my preferences, since you asked me "why". this is some of the why.
  -- j
  [*] java, for example, also violates that principle. while for the most part it does use explicit contracts (even though they are quite lame contracts), it fails to do so in the interaction between superclass and subclass---which is a very sad design flaw. C# does a slightly better, but still not sufficient job. i'd prefer explicit inheritance declaration as in, e.g., eiffel. in java, two overlapping interfaces that are implemented by the same class also lead to undeclared interaction between lexical units, and can create quite a surprise.
  For PGP Key, see
  > I've been working in Smalltalk professionally for ten years, and I've > never had the urge to use #isKindOf: or #isXYZ. You're sending a > message to an object. The object should know how to respond to that > message, or you're sending the message to the wrong object. If I wanted > to introduce behavior that depended on the type of the object, I'd > introduce a double-dispatch mechanism rather than a bunch of #if > statements to do type checking.
  in any event, smalltalk vendors seem to see the need for this sort of operation---there are about 20 such methods in squeak's Object class alone.
  eliot miranda espouses a similar view in this post:...
  his post admittedly compares isXYZ to isKindOf, but it is in reply to andy bower raising the concerns you just raised, so it is reasonable to assume that miranda sees at least some value in these testing methods. the follow-ups to his post also contain some interesting angles on this point.
  -- j
  >> i, personally, find it butt-ugly if "defaultBackgroundColor" is part of > the >> Object class, and would like to avoid using or producing software that >> involves things like that.
  IMHO, it's important to use a tool, well, the way it's meant to be used. If you are religiously avoiding adding methods to Object, then you are handicapping yourself. Enjoy the difference between the languages -- it gives some variety to life!
  One big difference between the Java and Smalltalk programs is that Java environments treat classes as units to be read and understood one by one, while Smalltalk tends to work with cross-cutting packages. A Smalltalk package can include individual methods from various classes, or from the other point of view, a Smalltalk class can be assembled from multiple packages.
  Object>>defaultBackgroundColor is a good example. If you don't care about this method and find it distasteful, then don't think about it. Why are you thinking about it, anyway? If you are working with the framework that uses this method, *then* you will need to worry about the method. Otherwise, just leave it be and concentrate on your own concerns.
  -Lex
  > >> i, personally, find it butt-ugly if "defaultBackgroundColor" is part of > > the > >> Object class, and would like to avoid using or producing software that > >> involves things like that.
  > I've had people say the exact same thing about the number 3 being an > object. It's just an integer, they say. It should be something > "smaller" than an object. It doesn't need to be able to get stuck in > generic arrays and it certianly doesn't need to have messages sent to > it. It just doesn't "feel" right for integers to be objects. It's > "ugly".
  that is what my statement was about.
  [snip]
  ...In my VisualAge
  We should have pretty strong *faith* in our vendor, for us to be certain that they are the Ancient Ones who came up with the eternally unchanging correct set of 28 methods which every object must support - but no more.
  (28 goes beyond string-theory!)
  Naturally conflicts between the Gods - about which methods are allowed in Object - are an issue on its own, but there package-extensions and selector-namespaces can help.
  Regards -Panu Viljamaa
  > first of all, it is important to figure out *whether* you want to use the > tool in the first place. in doing so, people are (or at least, i am) guided > by their preferences, which are preferences about how they'd like to work, > the kinds of products they'd like to produce, and also and related to this, > what tools they'd like to use for this.
  > that is what my statement was about.
  For example, it would indeed be ugly to hack java.lang.Object to add isFoo() methods. Java has an interfaces mechanism that works for this, and further it's {*filter*} your tools if you change the system classes. The situation is quite different in Smalltalk.
  1. "like Current" and static type checking
  2. type checking/inferencing for "beginners"
  3. No Boolean type in "types"
  4. Type checking strength
  5. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")
  6. about utility program named "Winteracter "...i need any information about the program..^^
  7. programs in "Effective Tcl programming"
  8. Setting "checked" property on menu item
  9. Check Characters "cc"
  10. Interesting change in "bounds checking"
  11. Conditional "checking"
  12. "Annoying" subscript checking