This is a comment on the "Inconceivable" entry in Jim Robertson's blog, which I tried to post on the weekend, but apparently it was too late, so I'm just posting it here. See also the comment by Glenn Vandenburg and the original post Jim refers to.
OK, I think I see more of what you're getting at, and where you see the Smalltalk community doing things differently, although it's always dangerous to generalize about diverse communities.
I think the biggest difference is in the expectations people would have of the source code they're seeing. Smalltalk programmers would generally expect to be able to see the list of instance variables and the methods that access them. If they can't see them, but they exist, they'd find that confusing, and they wouldn't think of the presence of the instance variable and accessor methods to be cluttering up the source code. From your comments, it sounds like Ruby programmers would. Perhaps that's also related to tools, because Smalltalk has tools that help organize the source code. There's also perhaps an encapsulation point that people don't automatically put accessors for all variables.
So in Smalltalk, people wouldn't tend to think of having a method somewhere that declares the existence of a number of instance variable that are related in some way and also two accessors for each. They'd expect to see those things, and would probably prefer to do something like annotate the class definition, or the accessor methods, to distinguish those things that are to-many relationships.
In fact, when you talked about generating code, I assumed you were talking about more complicated methods for managing persistence, and being aware of the fact that the variable is a collection, not just accessor methods. The more complicated methods are the sort of thing that Smalltalk people would think of as cluttering up code, and would be likely to do by reflective mechanisms of one sort or another.
And, as Avi points out, if we did generate code, we probably wouldn't do it in such a way as to throw away the intention of the original annotation. But again, that's a bit confusing. If all we're talking about is accessors and a variable declaration, then there are no additional semantics to be taken into account in the generated code. All we've said is that there's an instance variable, we just haven't said it in the normal spot. The fact that it's a collection is irrelevant to the accessor methods or the declaration. You do say that you have the accessors doing a bunch of additional very nice stuff, so maybe they do take that into account, but then we start to get into details.
As far as how hasMany works in the Glorp Active Record stuff that I did, it's just an annotation, so the reflective code takes it into account. So, if you put in that annotation, it's expected that you have a variable by that name (the accessors are optional). It doesn't generate it for you. Reading, writing, and querying against the object works via API's that know about that annotation and take it into account, but which don't generate any code (unless you count SQL). One reason I wouldn't want to rely on extra code in getters and setters is just it's more complicated to make them work if people get the collection and modify it directly. Glorp works by just remembering what the object's state was previously and seeing what's changed, regardless of the mechanism. Of course, other people have done things differently in different frameworks.
For the meta-tricks in general, I'd agree that many of the tricks are very similar. The kinds of things that Ruby and Rails do with reflection are exactly the sorts of things Smalltalkers do with them, and the idioms are very recognizeable.
