I regard Smalltalk as a teaching language

Post #106,738 by warmachine 6/20/03 8:30:39 PM Reply	I regard Smalltalk as a teaching language Four years ago, I learnt Smalltalk as part of a degree course without problems. Including the concept that code blocks can be passed as data as opposed to the Java technique of writing a class that implements an interface. It's definitely, a clean language. But I don't like it because of no compile-time type checking and no message access modifiers (private and protected). I'm aware that parameters that don't implemement the correct messages can be trapped using Design By Contract but I regard Design By Contract as impractical. Also, practical, working code needs messages that are not public. And classes that aren't public. For abstract classes based on the Template design pattern, hooks into the skeletal algorithmn should be exposed to the subclasses but not others. The famous 'Gang of Four' book suggests the use of protected. So, I regard Java as the advanced language and Smalltalk as a teaching language. I only want specific classes of a package to be public and act as the facade. I want mistakes such as passing a string parameter instead of an integer to be trapped at compile-time, not at system testing. I want to share code that is common to similar messages in a message but not expose it to the public. So I use Delphi or Java. Matthew Greet But we must kill them. We must incinerate them. Pig after pig, cow after cow, village after village, army after army. And they call me an assassin. What do you call it when the assassins accuse the assassin? They lie. They lie and we must be merciful to those who lie. - Colonol Kurtz, Apocalypse Now.
Post #106,751 by Arkadiy 6/20/03 9:30:12 PM Reply	Dixit. -- Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them. --Alan Cooper. The Inmates Are Running the Asylum
Post #106,772 by tuberculosis 6/21/03 12:19:43 AM Reply	I regard it as the most powerful production tool I have I don't like it because of no compile-time type checking this has been shown to be a red herring - compile time type checking rarely catches anything and test driven developmen is every bit as effective at catching these trivial to find and fix errors. and no message access modifiers (private and protected). But we have other conventions for indicating that methods are private and they work just as well. They include method categories with names like "private-event processing", method names that start with the word private - ie privateMouseDown:, or in the case of ObjectiveC, the convention is to start the method name with an underscore or simply to not declare it in the main class interface but rather to add the method as a private category. I grant that there is no compiler enforcement of the programmer's intent, but I view this as a plus. Particularly because, in my experience, most programmers are really bad at deciding what should be private vs public and I often have to break their conventions to get the code to do what I need. Bottom line, Smalltalk and ObjectiveC have a philosophy of "trust the programmer" and C++/Java have more of a "do unto others first" sort of mentality. I prefer the former. "Extreme programming is basically ... a bunch of practices that are really all about Smalltalk. Very incremental development. Very simple design. Testing, and so on." -- Ron Jeffries
Post #106,786 by ChrisR 6/21/03 3:15:09 AM Reply	couple of comments I only want specific classes of a package to be public and act as the facade. Why do you care if others have visibility to the interface to these methods? I've never had much of a problem discerning what methods constitute the correct interface for a class. Just because some methods are declared public does not guarantee that they will be called in the correct circumstances (and many times may require a correct sequence). On the one hand, you can solve this fairly trivially in Smalltalk by (a) naming the private methods in such a manner that it's obvious that they are not part of the intended public interface; and (b) creating groups of methods (messages) such that one group is called private - the facility for grouping methods into groups doesn't seem to be part of the Java culture. On the other hand, you can make the argument that simply having 4 levels of visibility is insufficient for a project of any complexity. What may be required to be public at one layer of the software, may really be totally irrelevent to the a higher level of abstraction. Ok, so Java recognizes this be having a package level visibility, but that just ups the level to one additional layer. What about interaction and layering at the package level. At some point, it becomes obvious that the decision to expose an interface at some level of publicity becomes a design decision pitting openness and flexibility of the classes against weighing down the system with arbitrary levels of closed class interfaces. Eiffel tries to solve this problem by allowing the granting of rights to methods to be controlled on the micro level down to which classes may access which methods. Modula-3 had a more sensible approach by allowing you to define different instances of interfaces to a class, thus allowing you to publish a spec for varying levels of abstractness to the class. I want mistakes such as passing a string parameter instead of an integer to be trapped at compile-time, not at system testing. And what if you are passing parameters to-and-fro in a much more loosely coupled framework - let's say something like DHTML, where the requests are filtered through web pages? When you're passing objects in and out of collections, that static type checking seemingly causes about as many errors as it solves - and collections (along with message passing) is what Object Oriented Programming should be about. I'm in the midst of a little C# ditty and I can say that it drives me crazy to have casting in practically 10% of the assignments - and C# with it's boxing/unboxing requires less casts than Java. What does that mean. It means that the code is not flexible in that the types get hard-coded a bunch of lines of code (change the types involved and you got a whole lot of touching to do). It also means that the comiple time type checking is useless as you are passing the check on to run time (hey compiler forget that I'm assigning an Object to a String - tell me a runtime if that's what actually happens).
Post #106,843 by warmachine 6/21/03 8:10:21 PM Reply	Re: couple of comments Why do you care if others have visibility to the interface to these [non-public]methods [and classes]? At the risk of another flame war: coding philosophy. Maintenance programmers have to identify the responsible classes in a short time, so javadoc generated documentation should describe the public functions that are designed around what it should do, rather than others that deal with 'how'. As you state, naming conventions can make this distinction clear, but it's my experience that an overloaded brain can't so readily ignore even easily filterable information. Also, when I design a class, I decide at design stage what behaviours are exposed to the outside world, subclasses or other classes of the package. I'm a strong believer in encapsulation: if a behaviour was not designed and tested as public, exposing it without a rethink and retest of the class is too dangerous. If a programmer thinks a private function could be used as public and the compiler denies this, the hurdle of changing the class source code will encourage a proper examination. Just because some methods are declared public does not guarantee that they will be called in the correct circumstances (and many times may require a correct sequence). What's your point? Having all message public doesn't help either. I want mistakes such as passing a string parameter instead of an integer to be trapped at compile-time, not at system testing. And what if you are passing parameters to-and-fro in a much more loosely coupled framework The other flame war: I believe in well defined interfaces and strong typing is part of this. I'm a defensive coder and I want anything that can go wrong caught and shot as soon as possible. To me, a change of type is the result, as well as cause, of a change of design. As for collections, I don't see your argument. If client code in Java is expecting a member of a collection to be an incorrect type, it will miscast it and an exception will be thrown. In Smalltalk, the client code will pass the member messages it doesn't understand and an exception will be thrown. Smalltalk just makes the code cleaner and more readable. This is good but not enough to convince to ditch Java-style typechecking. Matthew Greet But we must kill them. We must incinerate them. Pig after pig, cow after cow, village after village, army after army. And they call me an assassin. What do you call it when the assassins accuse the assassin? They lie. They lie and we must be merciful to those who lie. - Colonol Kurtz, Apocalypse Now.
Post #106,854 by ChrisR 6/21/03 11:41:57 PM Reply	Documentation tool? At the risk of another flame war: coding philosophy. Maintenance programmers have to identify the responsible classes in a short time, so javadoc generated documentation should describe the public functions that are designed around what it should do, rather than others that deal with 'how'. You make a couple of assumptions about maintenance programmers. First, you're assuming that the original designer is more capable of making decisions about what is applicable in the mature phase of a project. Problem with this assumption is that it disregards the very existence of the need for maintenance programming. What is that need? It's one of two things: either the original design needs to be extended or it's that the original design is errant. In either case, the maintenance programmer is trying to get around the original design limitations. It's interesting that the original designer created the problem and is now trying to handcuff others because of the belief that his design decisions should be respected (and enforced). As you state, naming conventions can make this distinction clear, but it's my experience that an overloaded brain can't so readily ignore even easily filterable information Are you saying that the tools for documenting Java source code are superior to those for documenting Smalltalk? I might remind that some of the best development and documentation tools for Java were originally designed for the Smalltalk environment (a not uncommon complaint is that the Java versions are pale imitations - e.g. Visual Age for Smalltalk is better than Visual Age for Java). Anyhow, the wieght of your argument seems to be that people are (a) incapable of documenting the interface of a class without a syntax enforced public/private statement; and (b) incapable of reading a comment that a method is designed to be private. As I said, Smalltalk uses groups (actually the proper term is catagories) to document the nature of the interface. This is actually more substantial than the public/private identifier as it identifies the nature of the methods in a much more concise grouping. You may help the maintenance programmers by allowing them to disregard the private methods (something which is done in Smalltalk by putting all these methods in a Private group - and no it's not just a method naming convention). But once they get into the methods, you've provided them no additional help in identifying what the purpose of the methods are (unless they read the fine print - something you think they would ignore if you put in comments about being private). If a programmer thinks a private function could be used as public and the compiler denies this, the hurdle of changing the class source code will encourage a proper examination. If a programmer starts calling methods without realizing what the purpose and intent of those methods are, i'd say you got much bigger problems than can be solved by merely hiding a few methods. Let's say we have the reverse scenario. Let's say you screwed up on the software design. Let's say six months later someone stumbles across a bug in the design. Interesting that you seem to believe that the programmer that has to fix the code should have less capacity than you had in the original design. As for collections, I don't see your argument. If client code in Java is expecting a member of a collection to be an incorrect type, it will miscast it and an exception will be thrown. The argument is simple. The act of having to typecast means that you are disabling compile time checking. So any time you deal with external interfaces - be it the interface via the web server in the case cited - or an interface to an external datasource such as a RDBMS - you end up having to typecast a significant amount of assigments/statements.

Welcome to IWETHEY!