Kirby- Thanks for your note (and also the previous ones when I went on vacation, which I did read but replies got lost in the homecoming shuffle). I didn't reply to those (e.g. how important categories are in practice in Smalltalk as a cultural convention thing), but to sum them up it without the details it might revolve around your use of "SmallTalk" versus "Smalltalk". Using the first signifies having been part of that community for any length of time. :-) Now, that capitalization of "SmallTalk" may actually most sense, because by the communities own common coding conventions it is actually the proper way to capitalize it if you think of it as two words "Small" and "Talk" -- it just isn't done though, as the community tends to think of Smalltalk as one unique concept as another sort of convention. So, is that capitalization consistent? Or inconsistent? Anyway, the deeper issue is that every community has conventions (even when they may not make total sense), and you made that point yourself a while back I believe, in the context of how library implementation are a big part of defining the syntactic and semantic conventions of a language (especially one like Python with open source libraries), and it's hard to swim against that tide. And any new effort runs into difficulties when it attempts to swim against the conventions (or leap into the blue plane instead of stay on the pink plane in Alan Kay's metaphor), requiring not a 10% improvement to be acceptable, but more like a 10X improvement.
In the case here, looking at the prototype related issues (not Python with classes, for which your comment holds better) for a beginner, the Smalltalk (or really Self) way would a single obvious option when you need to get something and the getting has a side effect (just put code in a "x" slot). But in Python, you either need to have a function activate on using a property or you need (as PataPata supports) some way of specifying a side effect before or after a setting operation. That makes for a few points of confusion for any learner (or implementor. :-) You sort of handwave away the "property" function as a rarely used necessary evil for Python, but needing such thing often in Prototypes is one of the big points here about elegance. And in writing code to wrap widgets, having side effects on property access turns out to be common thing in order to keep state consistent with a widget which may not always send changed events for various internal fields (and side effects on setting even more so). In the PataPata case using side effects defined in properties breaks the link between the name of a property and the name of the code that says what it does plus you have to need to know to look at property definitions to see how these are defined. So, you are left as a learner with a basic confusion given that functions in a prototype system are also properties -- so if a piece of code is used related to a property, is it called directly on the property get or is is intended to be used as a function with parens? Now there are ways to resolve this, but they require more intellectual effort and tracking usage and such. So, one more layer of difficulty between you and the code -- and the whole point of prototypes is to bring a person closer to the code IMHO. I think that is one ugly thing about PataPata I saw more clearly after my vacation. But another issue is from a debugging standpoint that you can override __getattr__ in Python (as PataPata does) but it is not clear whether the caller intends to use the result to send a message or as a value, and that can have a big impact on how to handle messages (e.g. when to call "doesNotUnderstand" in Smalltalk and perhaps invoke other delegation code, where there is a big and obvious difference from accessing the code for a method, say, to copy it, and actually using it). Anyway, these are finer points, but they bear on issues of conceptual elegance and ease of learning. Granted, people can learn the exceptions and deal with ambiguity or create new conventions, and a language like Python has so many great features that may overcome these issues for Prototypes, but they are still in some sense conceptual warts in this case for using it to do prototype based systems. Then again, maybe there is a cleverer approach I have not seen yet. I really need to reflect more on how I have used and elaborated on the notion of properties and see how much of it still makes good sense on reflection, and also consider your points here further. The parens on a constructor never bothered me. :-) But coming from Smalltalk (not Self) it is a big deal you can't have multiple constructors. with different names --Paul Fernhout kirby urner wrote: > On 8/7/06, Paul D. Fernhout <[EMAIL PROTECTED]> wrote: > >> On the other hand, after doing even more coding in Python, I'm really >> missing even more all the Smalltalk development tools, a situation which >> PataPata hopes to improve a little, of course, at some continued effort >> which looks somewhat boring/daunting at this point. :-) Venting a little, >> there is also not much one can do about the fact that the Smalltalk >> syntax >> and message passing approach (to me) is clearer for prototype based >> systems than Python's parenthetical functional notation. This is because >> in Smalltalk or Self, "self x" to get and "self x:" to set are clearly >> messages and not possibly variable accesses, unlike Python's "self.x", >> "self.x = value", "self.x()", "self.x(value)" permutations adding >> possibility for confusion (i.e. should self.x to get a property value be >> used with equals or as a function call?). > > > Although you've rarely deigned to engage in nitty gritty syntax > discussions when I bring them up, in response to your "judgments", > I'll risk it again: > > What's the confusion in this case? > > self.x, as seen from the inside, is a property, or a function's > address, likewise a property (looking at it sideways, not loading with > arguments or void, and calling with parentheses [1]). > > But usually we'd write obj.x or some such, as if querying an object > from outside. val = obj.x is "getting" whereas obj.x = val is > "setting". > > Outside, obj.x specifies a property, whereas use of parentheses > signifies invoking a callable i.e. a method in the object's hierarchy > __dict__s someplace (perhaps way up high in some tree). > > The major exception: if we want functions to operate even when the > user gets to use plain old property syntax -- so providing is the > purpose of the infamous property() function (which Arthur thinks was > brough over just to make inferior Java coders feel at home -- and he's > not the only one who thinks that). > > If there's ambiguity in Python, it's in __init__ and __call__ both > being invoked by the same syntax (a pair of parentheses). I haven't > made a complete study of all the ways to confuse myself about this > issue, but what experiments I *have* run indicate a rational sense of > operator precedence, i.e. you have to __init__ something before > there's something to even __call__. > > Kirby > > PS: I expect this'll be rejected from patapata-discuss but I'm > echoing the CC as a matter of courtesy. > > [1] A. Martelli talks about this distinction in his discussions about > Ruby. That reminds me of something I posted in wwwanderers.org > recently -- I'll copy here to edu-sig. > > _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
