[vwnc] Pragmas - Have we misused them?
Locked
12
12
[vwnc] Pragmas - Have we misused them?
 
|
While taking a shower I was thinking about the pragma thread
and it occurred to me that one problem is that we have misused them. Pragmas were intended to be method properties, or tags, but in several applications they have become class properties. It is easy to tell because the methods containing these pragmas are not intended to be executed. They are simply holders for the pragmas. While it is nice to employ existing facilities for other uses, doing so can make them ambiguous and confusing. So, it would seem to me that we need a conflict-free extensible technique to define and manage class properties other than method definitions. Method pragmas should be limited in use to methods that are intended to be executed. I might also suggest that it would be nice if there were browser support for other types of method properties, i.e. properties that might not be expressed when viewing the code. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
On 21/07/2008, at 10:55 AM, Terry Raymond wrote: > I might also suggest that it would be nice if there were > browser support for other types of method properties, i.e. > properties that might not be expressed when viewing the code. +1 As an example, for the purposes of editing I would like to annotate a method as being synthetic i.e. derived from a metaprogramming DSL construct, rather than being explicitly supplied. This covers that case of annotating a method with some 'original' source for an inline C compiler such as the C declaration that lies behind the method, where the method may be ST code that constructs the type information explicitly e.g. an explicit form of what DLLCC does invisibly when compiling a C 'pragma'. A 'less hidden magic' form of DLLCC. I've been thinking that I have to use pragmas for that so they are preserved/visible in source, but I must admit I haven't investigated fully, it's just that your suggestion seems cleaner. Might this be as simple as a) extending fileout/in formats to support generic annotations and b) providing an annotations CodeTool? You still have a refactoring issue because in all likelihood the keys to access such annotations would be symbols. There is only one symbol 'namespace' and rename-type refactorings currently operate on symbols. This means that it's possible to rename a method and 'accidentally' rename any symbols used as keys or constants in a non-message-selector context. Maybe this doesn't matter given symbol identity, except of course when you construct symbols rather than using literals. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 A reasonable man adapts himself to suit his environment. An unreasonable man persists in attempting to adapt his environment to suit himself. Therefore, all progress depends on the unreasonable man. -- George Bernard Shaw _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
In reply to this post by Terry Raymond
On Jul 20, 2008, at 6:25 PM, Terry Raymond wrote:
> While taking a shower I was thinking about the pragma thread > and it occurred to me that one problem is that we have > misused them. Pragmas were intended to be method properties, > or tags, but in several applications they have become class > properties. It is easy to tell because the methods containing > these pragmas are not intended to be executed. They are simply > holders for the pragmas. Terry, I think I agree with you. But am not sure, because you don't give any specific examples. I'm curious what tags you describe as good tags, and which you find that don't fit in this model well. I've said in the past: "...There is a "trap" that we seem to fall in repeatedly with these method tags. We try to program with them. Every experience I have like this convinces me that this is a bad idea. We should program with Smalltalk. We should use tags simply to annotate simple meta data to a given method..." But I'm not sure what kind of intersection your judgement of good-tag/ bad-tag has with mine. It would be interesting to compare notes. -- Travis Griggs Objologist "I choose. Therefore, I Am" _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
In reply to this post by Terry Raymond
On Sun, Jul 20, 2008 at 6:25 PM, Terry Raymond <[hidden email]> wrote:
While taking a shower I was thinking about the pragma thread Why cant they be acceptable for both purposes? They are a general purpose mechanism with broad applicability, which is part of their appeal. Good language design tries to provide powerful general mechanisms. Bad language design provides a proliferation of incoherent features.
Do you object to the use of methods to define meta properties such as shouldBeImplemented subclassResponsibility ? Are these an intolerable abuse of the execution semantics of methods?Do you object to the construction of abstract superclasses that are not meant to be executed but subclassed? Are these an intolerable abuse of the execution semantics of classes?
While it is nice to employ existing facilities for other Bah, humbug! I can imagine the User's Guide. When its Thursday and its raining do this. When its Friday and sunny do that. Instead why not look at method metadata (because that is what it is, not tags, not pragmas, but metadata represented as messages), as a facility that can associate with arbitrary methods an arbitrary set of messages which have whatever purpose the programmer sees fit. These can be introspected using the following API: (description elided). Typically definitional uses (methods labelled with a particular method metadaum) will be found using "senders", and referential uses (code that examines methods with particular method metadata) will be found using "implementors". Examples of the pattern (examples elided). Exceptions of the pattern: (exceptions, e.g. class side pragmas: metadata, elided). And stop trying to define the "one true way" to program and embrace the flexibility of the system.
Lucky carbon can be used to make so many different compounds. If it didn't we'd all get along...
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
> And stop trying to define the "one true way" to program and embrace > the flexibility of the system. > Hey now Eliot I think that's a bit harsh. Besides, what they're objecting to is more ways to do the same number of things. Why invent another hammer if the hammer you've got already works? Okay, hammer exampes are very bad :) I like pragmas because they let me be more descriptive in context. Recently I added a <function> pragma to Seaside-Gadgets. This pragma lets me say "This method can be called from javascript as a function" which in turn is interpreted to mean "output a javascript function that calls the seaside server". If I consider the alternate way to do this.. I'd need to come up with a place to 'register' my callable methods - and keep it up to date as I program. To do that I'd really need more tool support - more specifically, unique tool support specifically for my special seaside javascript callback mechanism. I might even think to do it - but with pragmas it is a no brainer to do it. One thing I always wanted to do with Pragmas was to replace instanceMethodsChanged and classMethodsChanged with a more interesting way to describe pragmas and what to do when they change. I think Travis detailed a similar idea in his post, so may be one of these days it'll happen :) However, I've yet to prove to myself that I really need it. I think the point I'd like to press is that Pragmas may add another way of doing stuff, but it's an elaboration on the stuff we already have - messages. I like that. More kool-aid please. Michael _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
On Sun, Jul 20, 2008 at 11:05 PM, Michael Lucas-Smith <[hidden email]> wrote:
I apologise if it comes over as being harsh. I really don't mean to be. But I do think minimality and generality are extremely important principles and very important elements of Smalltalk's (and Lisp's and chemistry's, and physics' ) power. Occam's razor, as simple as possible but no simpler. So replacing a general mechanism with two different approaches is an error.
I like pragmas because they let me be more descriptive in context. Right. Analogous to Tami Lee's first alternative use of pragmas (after I'd used them for menu definition), which was defining the interface of and exporting the subset of methods comprising an OLE server API.
If I consider the alternate way to do this.. I'd need to come up with a Exactly. That's not a hack. That's a concise solution to a common problem. One thing I always wanted to do with Pragmas was to replace Yes, yes, yes, yes! Pull a figure out of the air between ten and twenty. Every time you fix an AR in Store, parcel loading or whereever to do with change propagation increment the sum. When the sum reaches the number you first thought of kick yourself *hard* that many times for not fixing the problem up front ;)
I think the point I'd like to press is that Pragmas may add another way (with apologies to Paul Simon) We're goin' to Jonestown! _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
On 21/07/2008, at 3:57 PM, Eliot Miranda wrote: > But I do think minimality and generality are extremely important > principles and very important elements of Smalltalk's (and Lisp's > and chemistry's, and physics' ) power. Occam's razor, as simple as > possible but no simpler. So replacing a general mechanism with two > different approaches is an error. Surely this doesn't logically follow? A general mechanism might be used for two different purposes; it's generality might hide essential distinctions between the intentions of each purpose. The use of the general mechanism is thus lossy, which is important when you subsequently want to parameterize something on the basis of the original intention. My precise point being that I think it is a matter of conjecture whether the pragma model is praised or damned by Ockham's razor. Maybe the *intention* of pragmas is different enough to the intention of method sending to warrant a different mechanism, and the conflation is a case of 'too simple'. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Plurality is not to be assumed without necessity -- William of Ockham (ca. 1285-1349) _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
On 21/07/2008, at 4:11 PM, Antony Blakey wrote: > > On 21/07/2008, at 3:57 PM, Eliot Miranda wrote: > >> But I do think minimality and generality are extremely important >> principles and very important elements of Smalltalk's (and Lisp's >> and chemistry's, and physics' ) power. Occam's razor, as simple as >> possible but no simpler. So replacing a general mechanism with two >> different approaches is an error. > > Surely this doesn't logically follow? A general mechanism might be > used for two different purposes; it's generality might hide essential > distinctions between the intentions of each purpose. The use of the > general mechanism is thus lossy, which is important when you > subsequently want to parameterize something on the basis of the > original intention. > > My precise point being that I think it is a matter of conjecture > whether the pragma model is praised or damned by Ockham's razor. Maybe > the *intention* of pragmas is different enough to the intention of > method sending to warrant a different mechanism, and the conflation is > a case of 'too simple'. And to have a bet both ways ... :) At least Andre Schnoor, John Brant (and L Peter Deutsch in the past) have opined that pragmas are an unnecessary complication, and a mechanism using existing Smalltalk mechanisms/paradigms would be preferable i.e. pragmas are 'not simple enough', and hence violate Ockham's razor in the opposite direction. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Isn't it enough to see that a garden is beautiful without having to believe that there are fairies at the bottom of it too? -- Douglas Adams _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
On Mon, Jul 21, 2008 at 12:08 AM, Antony Blakey <[hidden email]> wrote:
Stop hand-waiving. This really _is_ an invalid argument. To substantiate this opinion come up with an alternative implementation or approach to the set of problems pragmas solve and dempnstrate that it is better in practice. Until then this is merely whingeing and hot-air (something poms usually spout).
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
On 21/07/2008, at 4:50 PM, Eliot Miranda wrote: > Stop hand-waiving. This really _is_ an invalid argument. To > substantiate this opinion come up with an alternative implementation > or approach to the set of problems pragmas solve and dempnstrate > that it is better in practice. I don't think an alternative implementation should be a prerequisite to arguing that some idea has conceptual flaws. > Until then this is merely whingeing and hot-air (something poms > usually spout). Ahh. I don't want to waste anyone's time. I understand this form of argument can seem pedantic, and be tedious. IMO the form of an argument isn't irrelevant to the content. The linguistic forms function in the same way as a logical formula, which must be correct both to properly understand the content of the argument and to accept it's validity. In considering arguments about simplicity, one point always comes up - considering Ockhams razor in it's more literal translation 'Plurality is not to be assumed without necessity', what is 'necessary' defines a form of ground term, which needs to be agreed upon. It is the essential core of any argument that invokes it. And while this is getting more abstract, IMO it is an important philosophical point underlying much of this discussion, not merely hot air. But maybe I am the only one who sees this issue in these terms. From an implementation perspective, I suggest: 1) Pragmas are not semantically message sends. We don't treat them that way. A lot of implementation and tool machinery is leveraged by treating them that way, but IMO that is largely irrelevant to the question of whether it is a good idea from a linguistic sense. And I understand that you suggest that pragmas are a model of metadata, not merely an implementation, and hence don't depend on that point. However, if you think of them as message sends, what's the receiver? Is it the method object? Conceptually or actually? Who 'sends' them. It seems to me that you are extracting the the concept of a pattern as embodied in a message send, and isolating it from the concept of sender and receiver. 2) Annotation of code model objects, be they methods, shared variables/ bindings or classes, is IMO a more general concept. The annotation could add behaviour to the code model object in a delegation-based MI fashion. A way of extending the definition of the code model object, rather than adding syntax. A method could be a "MenuProvidingThing + Method + ...". Obviously MI is not part of Smalltalk, but delegation based composition is all over the place, so it's not that unusual. Obviously this requires tool support, but I think it is worthy of consideration, and, might be a better way of associating the application of the 'pragma' with it's meaning, in a standard Smalltalk manner. 3) An alternative approach, suggested both by (my possibly wrong understand of) Newspeak's treatment of primitives, and your own (private) suggestion of the epiphenomena of subclassResponsibility et al, is to replace pragmas with an actual send to a 'black hole' e.g. MenuSystem addMenu: #... position: 20. Which would be a no-op. The 'pragma' machinery could however find messages sent to MenuSystem within a class subtree or hierarchy and treat them as the pragmas. So they really are message sends in a syntactic fashion. I suggest this only to indicate that the design space is fairly wide. Or maybe it wouldn't be a black hole, and could be like this: MenuSystem addMenu: #... position: 20 do: [.... ] In which case the use-case of pragmas devolves to finding methods that send to 'MenuSystem' and calling them at the appropriate time. So you use reflection to determine what methods to call, when. As far as being declaration, it's entirely feasible for MenuSystem to capture enough information to undo such a call if the sending method is later recompiled/removed. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Plurality is not to be assumed without necessity -- William of Ockham (ca. 1285-1349) _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
In reply to this post by Eliot Miranda-2
I'm following this discussion (which I might have provoked) closely
trying to understand the points you are making. Coming from Dolphin Smalltalk, I was not previously exposed to pragmas. That's why I have been asking. On Mon, 21 Jul 2008 00:20:33 -0700 "Eliot Miranda" <[hidden email]> wrote: > come up with an alternative implementation or approach to the > set of problems pragmas solve and dempnstrate that it is better in practice. One pragma that (slightly) bugs me is the <test> pragma, I can use to tag tests with non-canonical names. This annotation could be substituted by recognizing all methods of the category "tests" as unit tests. Another pragma application is building menus. These pragmas are carrying positional information. I can see no easy way to do this with a similar approach, so they're necessary here. But somehow those indexes remind me of the good ol' days of line numbers in BASIC programs. What goes between position 55 and 56? Is there an easy way to "renumber" these pragmas? To provide a real alternative, you'd require a annotation framework going way beyond what is currently available as the special case of method categories. Slapping a dictionary with more-or-less arbitrary keys onto methods comes to mind... So right now I'm seeing pragmas as a tool working on the source code level. Pragmas are solving problems, which sometimes could be solved differently. If that's the way it is, I'll be dealing with it. Thanks, s. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
In reply to this post by Eliot Miranda-2
Am 21.07.2008 um 07:43 schrieb Eliot Miranda:
> And stop trying to define the "one true way" to program and embrace > the flexibility of the system. I think I disagree. Smalltalk's immense flexibility is one of the major causes for its steep learning curve even after decades of enthusiatic support from fans. This might sound paradox, but developer's don't so much need the freedom of choice, they more need the freedom from (overwhelming) choice. IMO, pragmas being used as a magic universal trigger mechanism are very much like the "flexible goto", or even worst: self-modifying code. Why? Because a bare naked message send does not imply or require a meaningful framework behind it. IMO, Smalltalk is a victim to its productivity: It's often easier to reinvent the wheel than to get into some existing framework and conform to it. This led to an overwhelming variety of competing frameworks and APIs. The confusion often experienced by newbies is not because of the great, powerful language. It's because of the incomprehensible jungle of flexibility. I clearly advocate the more restricted "tag" style of usage here. In fact, I'm using pramgas to tag methods for review and for exclusion from certain product builds, etc. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
In reply to this post by Stefan Schmiedl
Am 21.07.2008 um 10:30 schrieb Stefan Schmiedl: > Another pragma application is building menus. These pragmas are > carrying > positional information. I can see no easy way to do this with a > similar > approach, so they're necessary here. But somehow those indexes remind > me of the good ol' days of line numbers in BASIC programs. What goes > between position 55 and 56? Is there an easy way to "renumber" these > pragmas? This is exactly what bugs me most: A package that requires its own additional UI elements must not make assumptions on the physical layout of the environment it's being loaded into. It can't, because that environment is subject to change. But IMO the core problem is the lack of a general user interface guideline in the first place. Menus and menu items currently are just passive representations of what's rendered on screen (mostly). They could be intelligent and self-organizing, knowing their conceptual purpose so they can join different menu supersets (menubar, context menu, tool menu) dynamically. VW has the power to implement great, well-designed UI frameworks (more than any other development environment, and yes, even with Wrapper under the hood), but this design task is a major effort. The Apple Human Interface Guidelines are a very enlightening read. They may not fully apply to some of the Windows and Unix-related elements, but their general principles are valid everywhere. The reason why most Mac software (even XCode) is easy to understand and use is not because Cocoa, ObjC or C++ are superior languages. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
In reply to this post by Antony Blakey-2
On 21/07/2008 Anthony Blakey wrote:
> At least Andre Schnoor, John Brant (and L Peter Deutsch in the past) > have opined that pragmas are an unnecessary complication, and a > mechanism using existing Smalltalk mechanisms/paradigms would be > preferable i.e. pragmas are 'not simple enough', and hence violate > Ockham's razor in the opposite direction. On 21/07/2008, at 4:50 PM, Eliot Miranda responded to Antony: > Stop hand-waiving. This really _is_ an invalid argument. To > substantiate this opinion come up with an alternative implementation > or approach to the set of problems pragmas solve and demonstrate that > it is better in practice. Here is an example were pragmas would be an unnecessary complication... GemKit is used to maintain VW copies of GS code in a separate VW namespace. An old GemKit feature that I may someday restore is to "mirror" methods. The two methods Root.Smalltalk.Object>>myMethod and Root.GemStone.Object>>myMethod are an example. Once a mirror relationship is established then a change to either method causes the other method to be updated with the same code. Mirroring is a technique to make it easier to maintain an application that can execute the same way in either VW or GS objectspaces--for applications designed around location independence. Not all methods are mirrored, but any can be. Kernel VW methods can be mirrored in GS code, or vice versa. Some form of method tagging is required for mirroring. I could use pragmas to tag the methods as mirrored. The advantage would be that the pragma tag in code would make it obvious (without other GemKit browser modifications) that the code is mirrored. The drawback to using a pragma to tag a method as mirrored is that it causes the method to change--it is no longer just copying code from the original method to the mirror. Changing the original method to pragma-tag it doesn't feel right. The tag is for GemKit. GemKit should be tracking tags itself and should not be modifying code just to note a relationship that only GemKit cares about. There are simple alternatives to pragma-tags for mirroring. One approach is to define class methods (like #gbcMirroredInstanceSelectors and #gbcMirroredClassSelectors) on Root.GemStone.Object (a class maintained by GemKit) that answers a collection of selectors that are to be mirrored. GemKit is already aware of method changes in the system. It just needs to see if the selector is one of the ones tagged for the class. Tagging a method as mirrored only causes a change to the #gbcMirored*Selectors method. The tags are maintained along with the code they relate to and in the framework for which the tags are relevant. A similar amount of work is done with either approach. The pragma approach just doesn't seem right though. I don't want to modify code just to tag it for some purpose. I wouldn't want to reversion pundles just because I've tagged some of their methods as mirrors; that would introduce a multitude of code management issues for this example. Tags are best maintained for and by the framework that is interested in them. When the tags are for VW itself (like for VW system menus) then pragma method tags are fine. If there is a chance that you'd want to tag prerequiste code then the pragma approach is not appropriate. In other words, Cincom itself would see no problem using method pragmas in new and innovative ways but anyone else should use them with care. Fortunately, alternatives are easy to implement. Paul Baumann -------------------------------------------------------- This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
In reply to this post by Stefan Schmiedl
On Jul 21, 2008, at 1:30 AM, Stefan Schmiedl wrote:
> One pragma that (slightly) bugs me is the <test> pragma, > I can use to tag tests with non-canonical names. This annotation could > be substituted by recognizing all methods of the category "tests" as > unit tests. This is purely my fault. It was an experiment on my part originally, a sort of "hmmm... what would this end up like." It's an SUnitToo only thing. I grew to like it, for the previously noted benefit, that I found I liked the test names better, when I wasn't naming them as something that sounded good following the preamble 'test'. That said, it's entirely optional. One can still do the testBlah thing. Which reminds of 8.3 filename filetypes, where we embed the metadata of a entity in its name, a technique that seems pretty cheesy, but that you can get a bit of mileage out of nevertheless. More than once, I have considered doing exactly as you hinted, simply use the ClassOrganizers information to decide what test to run. The only reason I haven't yet is that I just haven't gotten around to it, and haven't take the time. If there were other's clamoring for it, I'd do it in a heartbeat. That said, note that it's just an indirect form of the "embedding meta data in the naming convention". Instead of a pattern match of the method selector, you're now doing a pattern match of the method category. And then we can regress back to this whole set of hypothetical and philosophical arguments about what form metadata takes, and what mechanism is used to attach it to an entity. -- Travis Griggs Objologist "Dying men never wish they'd spent more time at the office" _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
On Mon, 21 Jul 2008 09:00:27 -0700
Travis Griggs <[hidden email]> wrote: > On Jul 21, 2008, at 1:30 AM, Stefan Schmiedl wrote: > > > One pragma that (slightly) bugs me is the <test> pragma, > > I can use to tag tests with non-canonical names. This annotation could > > be substituted by recognizing all methods of the category "tests" as > > unit tests. > > This is purely my fault. One of the risks of boldly going where no man has gone before :-) > It was an experiment on my part originally, a > sort of "hmmm... what would this end up like." It's an SUnitToo only > thing. I grew to like it, for the previously noted benefit, that I > found I liked the test names better, when I wasn't naming them as > something that sounded good following the preamble 'test'. Assuming for a moment that they are here to stay... is there a way to make <test> more useful? Ever felt the need to provide a selector for a specific setUp call? shouldWork <test: #setUpGoodData> shouldFail <test: #setUpBadData> Or something like testFoo <test: 'suite 1'> I've not had enough coffee today, so I might be totally off the rocker here :-) > That said, it's entirely optional. One can still do the testBlah > thing. Which reminds of 8.3 filename filetypes, where we embed the > metadata of a entity in its name, a technique that seems pretty > cheesy, but that you can get a bit of mileage out of nevertheless. And I shamelessly use both ways in my current project. Bad developer, bad, bad. > More than once, I have considered doing exactly as you hinted, simply > use the ClassOrganizers information to decide what test to run. The > only reason I haven't yet is that I just haven't gotten around to it, > and haven't take the time. If there were other's clamoring for it, I'd > do it in a heartbeat. Not important. The available tools are sufficient. > That said, note that it's just an indirect form of the "embedding meta > data in the naming convention". Instead of a pattern match of the > method selector, you're now doing a pattern match of the method > category. And then we can regress back to this whole set of > hypothetical and philosophical arguments about what form metadata > takes, and what mechanism is used to attach it to an entity. DTSTTCPW, but OAOO. Just making Smalltalk, s. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
Eliot suggested I "stop hand-waiving", so I posted some explicit
implementation ideas for pragma-like facilities on my blog: http://www.cincomsmalltalk.com/userblogs/antony/blogView?showComments=true&printTitle=Alternatives_to_pragmas&entry=3394144013 Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Some defeats are instalments to victory. -- Jacob Riis _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
In reply to this post by Eliot Miranda-2
From: Eliot
Miranda [mailto:[hidden email]] On Sun, Jul 20, 2008 at
6:25 PM, Terry Raymond <[hidden email]>
wrote: While taking a shower I
was thinking about the pragma thread Why cant they be
acceptable for both purposes? They are a general purpose mechanism with
broad applicability, which is part of their appeal. Good language design
tries to provide powerful general mechanisms. Bad language design
provides a proliferation of incoherent features. Do you object to the use
of methods to define meta properties such as
shouldBeImplemented
subclassResponsibility ? Are these an intolerable
abuse of the execution semantics of methods? I don’t see how they are an abuse,
they do something useful if executed. Do you object to the
construction of abstract superclasses that are not meant to be executed but
subclassed? Are these an intolerable
abuse of the execution semantics of classes? Hardly. The methods are executed.
Bah, humbug! I can
imagine the User's Guide. When its Thursday and its raining do this.
When its Friday and sunny do that. Instead why not look at method
metadata (because that is what it is, not tags, not pragmas, but metadata represented
as messages), as a facility that can associate with arbitrary methods an
arbitrary set of messages which have whatever purpose the programmer sees fit.
These can be introspected using the following API: (description elided).
Typically definitional uses (methods labelled with a particular method
metadaum) will be found using "senders", and referential uses (code
that examines methods with particular method metadata) will be found using
"implementors". Examples of the pattern (examples elided).
Exceptions of the pattern: (exceptions, e.g. class side pragmas:
metadata, elided). And stop trying to define the "one true way"
to program and embrace the flexibility of the system. My whole issue here is proper separation of
concerns. We need method properties or “tags”, and we need class properties. Just because
the system is designed to use methods does not mean that we cannot separate the concerns
and add class properties. By the way don’t mistake my critcisms
to mean I don’t like pragmas, I do. It is just that we need to evolve our
solutions as we learn more about the problem space. There are many
cases where pragmas have been used as class properties, rather than
method properties. If we don’t separate the concerns we eventually
get into a twisty mess. Terry _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
On Tue, Jul 22, 2008 at 5:03 AM, Terry Raymond <[hidden email]> wrote:
I don't want to drag this out or jump down people's throats all the time. Apologies. I will just say, though, that the tooling costs have proved prohibitive. Steve and I never got round to implementing first-class inst vars, which were the most important feature we needed. The parcel, package and source formats change. The programming GUIs all change. The change tracking system changes, etc.
If class properties are added other than as methods then they also need parcel, package and source format changes, browser changes, ChangeList/ChangeSet changes, and a parallel refs/defs search framework.
Using method metadata is much cheaper and initially much less buggy because it leverages the existing method/message support. just my curmudgeonly 2¢
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Pragmas - Have we misused them?
|
|
On Jul 22, 2008, at 10:50 AM, Eliot Miranda wrote:
> I don't want to drag this out or jump down people's throats all the > time. Apologies. I will just say, though, that the tooling costs > have proved prohibitive. Steve and I never got round to > implementing first-class inst vars, which were the most important > feature we needed. The parcel, package and source formats change. > The programming GUIs all change. The change tracking system > changes, etc. > > If class properties are added other than as methods then they also > need parcel, package and source format changes, browser changes, > ChangeList/ChangeSet changes, and a parallel refs/defs search > framework. > > Using method metadata is much cheaper and initially much less buggy > because it leverages the existing method/message support. > > just my curmudgeonly 2¢ I think I pretty much agree. So the irony is that while I generally eschew the term "pragma" for afore stated reasons, what we have is really a solution based on pragmatism. :) Michael and I were chatting about this the other night. One interesting observation was what happens if you ditch the syntax, and instead use higher level tools to manage method annotations? You might have a pull down menu or something to add known annotations. If you make a "copy" of the method (still the most common form or temporal reuse, find pattern, modify it to fit current need), what happens to the tag? How do you "copy" that too? And amen to the first class inst vars comment too. :) -- Travis Griggs Objologist "I choose. Therefore, I Am" _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |