[vwnc] RBrowserHistory and RBTabbedToolsets
Locked
12
12
[vwnc] RBrowserHistory and RBTabbedToolsets
 
|
Is anybody using these two packages together?
Depending on the load order I get either the history buttons without tabs or tabs without history buttons. Ideally, I'd have both with individual histories per tab. Am I missing something? Thanks, s. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
Hello Dennis,
thanks for replying. On Thu, 17 Jul 2008 17:15:47 +0400 "Dennis Schetinin" <ch...@...> wrote: > What about versions you are using? For me it seems to be ok with the most > recent once (and VW 7.6). But there were issues before... I'm running the current pre-release (jul08.4) for 7.7. here with RBrowserHistory 76 and RBTabbedToolsets 2.mod-hk.2. The last one loaded decides what's in newly opened browsers. I guess that's what I get for living on the bleeding edge :-) s. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
Hi there,
I tried both packages and the conflict is in #postOpenWith:. They both override it and register themselves there in a newly created RefactoringBrowser. I just tried to merge both as: postOpenWith: aBuilder super postOpenWith: aBuilder. self addFind. self addHistory. self addToolsetsTabs. self updateToolbar. (RBHistoryCompatibility currentToolFrom: self) updateDisplay. self enableHistoryButtons and it seems to do the trick here. Maybe it'd be time to add some sort of plugin interface to the RB so that it's easier to load different extensions without worrying too much about the load order. Kind Regards Karsten Stefan Schmiedl wrote: > Hello Dennis, > > thanks for replying. > > On Thu, 17 Jul 2008 17:15:47 +0400 > "Dennis Schetinin" <ch...@...> wrote: > > >> What about versions you are using? For me it seems to be ok with the most >> recent once (and VW 7.6). But there were issues before... >> > > I'm running the current pre-release (jul08.4) for 7.7. here with > RBrowserHistory 76 and RBTabbedToolsets 2.mod-hk.2. > The last one loaded decides what's in newly opened browsers. > > I guess that's what I get for living on the bleeding edge :-) > > s. > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > -- Karsten Kusche - Dipl.Inf. - [hidden email] Tel: +49 3496 21 43 29 Georg Heeg eK - Köthen Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
Hi Karsten,
thank you very much for solving this problem. On Thu, 17 Jul 2008 23:57:18 +0200 Karsten <[hidden email]> wrote: > RefactoringBrowser>>postOpenWith: aBuilder > super postOpenWith: aBuilder. > self addFind. > self addHistory. > self addToolsetsTabs. > self updateToolbar. > (RBHistoryCompatibility currentToolFrom: self) updateDisplay. > self enableHistoryButtons > > and it seems to do the trick here. hmmm... I was expecting something like this. A single method which is overridden by the "conflicting" packages. > Maybe it'd be time to add some sort of plugin interface to the RB so > that it's easier to load different extensions without worrying too much > about the load order. A class side collection of blocks so that RB extensions could use RBExtension class>>initialize RefactoringBrowser plugin: [:rb | .... ] or send the plugin: message from their post-load-block. Guessing from your implementation this would come down to: RefactoringBrowser plugin: [:rb | rb addFind ] RefactoringBrowser plugin: [:rb | rb addToolsetsTabs ] RefactoringBrowser plugin: [:rb | rb addHistory; updateToolbar. (RBHistoryCompatibility currentToolFrom: rb) updateDisplay. rb enableHistoryButtons ] and: RefactoringBrowser>>postOpenWith: aBuilder super postOpenWith: aBuilder. self class pluginsDo: [ :block | block value: self ] Would this be a valid approach? Just making Smalltalk, s. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
In reply to this post by Stefan Schmiedl
Hi all!
Stefan Schmiedl wrote: > hmmm... I was expecting something like this. A single method which > is overridden by the "conflicting" packages. > >> Maybe it'd be time to add some sort of plugin interface to the RB so >> that it's easier to load different extensions without worrying too >> much about the load order. Most of the time, when we have multiple things to be be done in a method depending on the set of loaded extensions in a given environment, we revert to using Pragmas. The core method then looks for the pragmas an executes found methods. This works pretty well and we can have multiple independent extensions adding behaviour to a class without the hassle of overrides or rely on - post-load blocks, which are terrible to maintain, or - class initialization code, which sometimes runs and sometimes doesn't and requires handling of dynamic updates. Regards Jan _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
On Fri, 18 Jul 2008 11:35:49 +0200
"Jan Weerts" <[hidden email]> wrote: > Hi all! > > Stefan Schmiedl wrote: > > hmmm... I was expecting something like this. A single method which > > is overridden by the "conflicting" packages. > > > >> Maybe it'd be time to add some sort of plugin interface to the RB so > >> that it's easier to load different extensions without worrying too > >> much about the load order. > > Most of the time, when we have multiple things to be be done in a > method depending on the set of loaded extensions in a given > environment, we revert to using Pragmas. The core method then looks > for the pragmas an executes found methods. This works pretty well > and we can have multiple independent extensions adding behaviour > to a class without the hassle of overrides or rely on > - post-load blocks, which are terrible to maintain, or > - class initialization code, which sometimes runs and > sometimes doesn't and requires handling of dynamic > updates. So it's a "pull" approach vs. my "push" idea, right? Hmmm... I need to read up on pragmas. Thanks, s. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
In reply to this post by Jan Weerts
yeah, the code-tools already have a nice plugin interface, you can
easily create your own code-tool just by adding another method to CodeModel with a #tool: pragma. Would be cool to have that also on other levels of the Refactoring Browser. Kind Regards Karsten Jan Weerts wrote: > Hi all! > > Stefan Schmiedl wrote: > >> hmmm... I was expecting something like this. A single method which >> is overridden by the "conflicting" packages. >> >> >>> Maybe it'd be time to add some sort of plugin interface to the RB so >>> that it's easier to load different extensions without worrying too >>> much about the load order. >>> > > Most of the time, when we have multiple things to be be done in a > method depending on the set of loaded extensions in a given > environment, we revert to using Pragmas. The core method then looks > for the pragmas an executes found methods. This works pretty well > and we can have multiple independent extensions adding behaviour > to a class without the hassle of overrides or rely on > - post-load blocks, which are terrible to maintain, or > - class initialization code, which sometimes runs and > sometimes doesn't and requires handling of dynamic > updates. > > Regards > Jan > > > -- Karsten Kusche - Dipl.Inf. - [hidden email] Tel: +49 3496 21 43 29 Georg Heeg eK - Köthen Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
In reply to this post by Stefan Schmiedl
On Jul 17, 2008, at 10:45 PM, Stefan Schmiedl wrote: > Hi Karsten, > > thank you very much for solving this problem. > > On Thu, 17 Jul 2008 23:57:18 +0200 > Karsten <[hidden email]> wrote: > >> RefactoringBrowser>>postOpenWith: aBuilder >> super postOpenWith: aBuilder. >> self addFind. >> self addHistory. >> self addToolsetsTabs. >> self updateToolbar. >> (RBHistoryCompatibility currentToolFrom: self) updateDisplay. >> self enableHistoryButtons >> >> and it seems to do the trick here. > > hmmm... I was expecting something like this. A single method which > is overridden by the "conflicting" packages. > >> Maybe it'd be time to add some sort of plugin interface to the RB so >> that it's easier to load different extensions without worrying too >> much >> about the load order. > > A class side collection of blocks so that RB extensions could use > > RBExtension class>>initialize > RefactoringBrowser plugin: [:rb | .... ] > > or send the plugin: message from their post-load-block. Guessing from > your implementation this would come down to: > > RefactoringBrowser plugin: [:rb | rb addFind ] > RefactoringBrowser plugin: [:rb | rb addToolsetsTabs ] > RefactoringBrowser plugin: [:rb | > rb addHistory; updateToolbar. > (RBHistoryCompatibility currentToolFrom: rb) updateDisplay. > rb enableHistoryButtons ] > > and: > > RefactoringBrowser>>postOpenWith: aBuilder > super postOpenWith: aBuilder. > self class pluginsDo: [ :block | block value: self ] > > Would this be a valid approach? It's an OK approach, and has been employed at other points in the browser previously. It's a good idea to keep doing so if you want to ease cross platform porting concerns. The shortcoming of this approach is that you have to add a collection somewhere. And you everyone who accesses it has to be instrumented to invoke the appropriate APIs to register and deregister their new services. If order is an issue, your API has to not only be rich enough to add the service, but at the appropriate point. The scheme we've been pivoting now is to use tagged methods to do this. In this way, we're leveraging existing APIs and existing state to accomplish the same. IOW, the RB might be setup so that people who want to register new #postBuild actions simply add a method of following ilk: myPostBuildWithService: aBuilder <postBuild> "dopostbuildstuff" Just having a class extension is the way the service gets added or removed. The specifics on what should be one addition and removal, when to respond to them and such, are encapsulated in an #instanceMethodsChanged method. We don't need a new collection added to hold them, we're just using the methodDictionary that's already there and the services provided by the Pragma class to select the ones of interest. The method tag might be set up in such a way to show provide ordering information. The "tools" in the lower half of the browser are managed now using this mechanism. I just haven't been given an opportunity yet to get back into the browser, and have a go at the top half. -- Travis Griggs Objologist "There are a thousand hacking at the branches of evil to one who is striking at the root" - Henry David Thoreau _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
>>
Erf, I should read the stuff I write sometimes. Couple grammatical corrections.... > It's an OK approach, and has been employed at other points in the > browser previously. It's a good idea to keep doing so if you want to > ease cross platform porting concerns. > > The shortcoming of this approach is that you have to add a collection > somewhere. And you everyone who accesses it has to be instrumented to /you/ d > > invoke the appropriate APIs to register and deregister their new > services. If order is an issue, your API has to not only be rich > enough to add the service, but at the appropriate point. > The scheme we've been pivoting towards now is to use.... > The scheme we've been pivoting now is to use tagged methods to do > this. In this way, we're leveraging existing APIs and existing state > to accomplish the same. IOW, the RB might be setup so that people who > want to register new #postBuild actions simply add a method of > following ilk: > > > myPostBuildWithService: aBuilder > <postBuild> > "dopostbuildstuff" > > Just having a class extension is the way the service gets added or > removed. The specifics on what should be one addition and removal, ...what should be done on addition and.... > > when to respond to them and such, are encapsulated in an > #instanceMethodsChanged method. We don't need a new collection added > to hold them, we're just using the methodDictionary that's already > there and the services provided by the Pragma class to select the ones > of interest. The method tag might be set up in such a way to show > provide ordering information. /show/ d > > > The "tools" in the lower half of the browser are managed now using > this mechanism. I just haven't been given an opportunity yet to get > back into the browser, and have a go at the top half. -- Travis Griggs Objologist What's next, Intel Processors branded with "Apple Outside" stickers? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
In reply to this post by Travis Griggs-3
On Fri, 18 Jul 2008 13:12:23 -0700
Travis Griggs <[hidden email]> wrote: > The shortcoming of this approach is that you have to add a collection > somewhere. And you everyone who accesses it has to be instrumented to > invoke the appropriate APIs to register and deregister their new > services. If order is an issue, your API has to not only be rich > enough to add the service, but at the appropriate point. Yep, that's why I was asking for enlightenment. Thank you for sharing. > the services provided by the Pragma class to select the ones > of interest. The method tag might be set up in such a way to show > provide ordering information. ... as is the case with menu items or the ordering of items in the settings window, if I understand this correctly. Now I have a few starting points to start looking :-) Thanks again, s. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
In reply to this post by Travis Griggs-3
On 19/07/2008, at 5:42 AM, Travis Griggs wrote: > The scheme we've been pivoting now is to use tagged methods to do > this. In this way, we're leveraging existing APIs and existing state > to accomplish the same. IOW, the RB might be setup so that people who > want to register new #postBuild actions simply add a method of > following ilk: Given that pragmas aren't including in the IDE's code-model navigation facilities, they break the explorability of system structure. IMO if this technique is going to be more widely used, then they need to be first-class elements of the code model. I think there needs to be a pragma navigator to a) show all the extent pragmas; and b) show all of the 'declaring' methods (cf. implementors); and c) show all the 'referencing' methods (cf. senders); and d) include them in e.g. spotlight using this same breakdown. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 On the other side, you have the customer and/or user, and they tend to do what we call "automating the pain." They say, "What is it we're doing now? How would that look if we automated it?" Whereas, what the design process should properly be is one of saying, "What are the goals we're trying to accomplish and how can we get rid of all this task crap?" -- Alan Cooper _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
Antony
If I understand your comment, I find many of the pragmas I am looking for by picking one of the symbols in the pragma and do a 'senders' for that symbol. For example, in the VisualLauncher if you do a senders of #probes you will find all the menu command on the probes menu. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Antony Blakey > Sent: Friday, July 18, 2008 6:34 PM > To: Travis Griggs; VWNC List > Subject: Re: [vwnc] RBrowserHistory and RBTabbedToolsets > > > On 19/07/2008, at 5:42 AM, Travis Griggs wrote: > > The scheme we've been pivoting now is to use tagged methods to do > > this. In this way, we're leveraging existing APIs and existing state > > to accomplish the same. IOW, the RB might be setup so that people who > > want to register new #postBuild actions simply add a method of > > following ilk: > > Given that pragmas aren't including in the IDE's code-model navigation > facilities, they break the explorability of system structure. IMO if > this technique is going to be more widely used, then they need to be > first-class elements of the code model. I think there needs to be a > pragma navigator to a) show all the extent pragmas; and b) show all of > the 'declaring' methods (cf. implementors); and c) show all the > 'referencing' methods (cf. senders); and d) include them in e.g. > spotlight using this same breakdown. > > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > On the other side, you have the customer and/or user, and they tend to > do what we call "automating the pain." They say, "What is it we're > doing now? How would that look if we automated it?" Whereas, what the > design process should properly be is one of saying, "What are the > goals we're trying to accomplish and how can we get rid of all this > task crap?" > -- Alan Cooper > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
In reply to this post by Antony Blakey-2
On Fri, Jul 18, 2008 at 3:33 PM, Antony Blakey <[hidden email]> wrote:
IMO they are included to quite an extent. pragmas are simply literal message expressions so they are messages (they're even implemented using Message instances). You have senders and implementors automatically because the selector(s) of a pragma are included in the senders & implementors menus. There is code to trawl through the system collecting the set of pragmas. All you need to do is build the UI available from the Launcher that says "browse all pragma implementors" and "browse all pragma methods".
Antony Blakey _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
In reply to this post by Terry Raymond
On 19/07/2008, at 9:29 AM, Terry Raymond wrote: > If I understand your comment, I find many of the pragmas > I am looking for by picking one of the symbols in the pragma > and do a 'senders' for that symbol. For example, in the > VisualLauncher if you do a senders of #probes you will find > all the menu command on the probes menu. In your example, I would search for 'submenu:...' which spotlight finds for me, including implementors which tells me where the pragma is used. And I can find the declaration by searching for senders, and then look for pragma declaration methods - which is fine if the method that declares the pragma is called 'pragma' or something obvious, but given that pragma declaring methods can themselves be identified using pragmas ... and strangely I had to search for a literal 'pragmas' rather than a send of 'pragmas:' to find the pragma-tagged pragma declaring method. I think there's a need for a pragma browser. Maybe a UI to browse all the pragmas declared in a class, and the implementors of those pragmas. Browsing senders is more of a problem because pragmas are accessed programatically. Maybe a pragma is needed to mark methods that 'search' for pragma-annotated methods so that you can do the full senders/implementors exploration as it relates pragmas. But I hesitate to even suggest that hack on a hack. Pragmas can't be properly refactored because of the lack of senders information, for the same reason sends using #perform: on constructed symbols can't be. Unlike #perform: however, there is no 'syntactic' way of indicating pragma access, so using pragmas is like using smalltalk where all sends must use #perform: (ignoring the bootstrap issue). IMO pragmas don't (yet) fit properly into the semantics of Smalltalk, and if they are going to be promoted, then some more thought should be given to the way they are modeled and accessed, and what tool support is needed. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. -- C. A. R. Hoare _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
In reply to this post by Eliot Miranda-2
On 19/07/2008, at 9:46 AM, Eliot Miranda wrote: > IMO they are included to quite an extent. pragmas are simply > literal message expressions so they are messages (they're even > implemented using Message instances). You have senders and > implementors automatically because the selector(s) of a pragma are > included in the senders & implementors menus. There is code to > trawl through the system collecting the set of pragmas. All you > need to do is build the UI Which was my point, although IMO VW Smalltalk is the language + the UI, so lack of UI support == lack of 'language' support. In any case, I think that you are simplifying the situation somewhat, especially for non-expert users. Using pragmas to mark the methods that declare pragmas e.g. <pragmas: #instance>, is an example of why better support is needed (more details in my reply to Terry). 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] RBrowserHistory and RBTabbedToolsets
|
|
In reply to this post by Eliot Miranda-2
On 19/07/2008, at 9:46 AM, Eliot Miranda wrote: > pragmas are simply literal message expressions so they are messages > (they're even implemented using Message instances). Thinking about this point, I think it's a negative rather than a positive. Pragmas reuse the syntax but they are not message sends. Having the implementation conflating items with two different user- visible semantics just because it's a convenient implementation technique is IMO a bad idea because tools that depend on an identity between implementation semantics and user-visible semantics then either (at worst) actively mislead the user or (at best) confuse the user. Maybe an expert user, who understands the implementation mechanism for pragmas, can feel comfortable with that, but I think that's a cop-out. The tools should be doing a much better job. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
On Fri, Jul 18, 2008 at 7:20 PM, Antony Blakey <[hidden email]> wrote:
I disagree strongly (but then I would; they were my idea). Using messages to represent pragmas means they're integrated. They can be performed. One can do senders and implementors. They are extensible. As such they are much more reflective amd malleable metadata that you'll find in e.g. C# and Java properties. This was not "a convenient implementation technique". It was the only sensible way to do it. What is fortuitous is that Smalltalk's literal message pattern is so rich a form that its easy to use them for many different kinds of pragma (and this is impostant because e.g. primitive: N errorCode: identifier is not a literal message pattern and not a pragma. It is special syntax. try and do senders of primitive:errorCode: and (IIRC) you won't retrieve all primitives with error codes in the system (at least not in the releases I worked on).
I don't disagree that tools could do a better job. But you're throwing the baby out with the bath water if you damn pragmas for poor tool support. yes, class-side pragmas that define what pragmas are legal are a bit mind-bending. But the rationale is a good one. If there was one class-side method that defined a class's legal pragmas then one couldn't extend the set of pragmas in one's own extension without potentially colliding with someone else's extension. One of the fundamental advantages of the use of pragmas in defining pragmas and defining menu extensions is that the extensions are self-contained and hence do not collide with otger self-containe extensions that extend the same thing (menu, class, COM interface, set of legal pragmas, etc).
This conflict-free extensibility is what I invented pragmas for. When we parcelled up the system it was clear to me that one had to have a way of at least extending menus. The state of play at that time (vw2.5) was to have a humongous menu definition for the launcher that was the superset of all the packages ParcPlace planned to add to it (DLLCC, Advanced Tools etc). If a package wasn't loaded then the menu item was present but disabled. It was poor in that it was inflexible (you couldn't add anything new) and it was noisy (it was full of disabled menu items). The current situation isn't clean because no-one has the time to build the tools to use a base menu definition plus pragmas throughout (notably in the RB). But its still much better.
I think more than tool support you probably need documentation on how to use them, why they're there, and how they work. Then I think you;d find you could do without the UI and do things like browseAllSelect: [:m| m pragmas notEmpty] etc (that is off the top of my head and probably doesn't work, but something similar does).
Anyway I sound like I don't like my baby being criticised. But I do see the need for metadata, see the advantages of the conflict-free extensibility, the flexibility and the integratedness of pragmas, and sincerely think pragmas are a lot better than the competition. Your mileage clearly varies.
regards Eliot
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
and Steve Dahl and Vassili Bykov deserve a lot of the credit. Steve cleaned up my initial implementation, did the menu builder and invented class-side pragmas declaring which pragmas were legal (and I think checking for legal pragmas in the first place). Vassili did all the pragma enumeration facilities.
On Fri, Jul 18, 2008 at 8:49 PM, Eliot Miranda <[hidden email]> wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
On Fri, Jul 18, 2008 at 8:56 PM, Eliot Miranda <[hidden email]> wrote:
This actually brings up an interesting question. At the risk of igniting a flame war as I'm about to leave for vacation... Why should we have to declare which pragmas are legal? Those declarations have a very similar feel to type declarations in a statically-typed language or having to define and then implement an interface. This is Smalltalk, after all. Why can't I just add a pragma to a method and be done with it? Why should I have to go somewhere else to specify that it is legal for me to have put that pragma in my method? Randy -- Randy Coulman [hidden email] _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] RBrowserHistory and RBTabbedToolsets
|
|
In reply to this post by Eliot Miranda-2
On 19/07/2008, at 1:19 PM, Eliot Miranda wrote: > I think more than tool support you probably need documentation on > how to use them, why they're there, and how they work. Then I think > you;d find you could do without the UI and do things like > browseAllSelect: [:m| m pragmas notEmpty] etc (that is off the top > of my head and probably doesn't work, but something similar does). I'm thinking about this problem from a non-expert user perspective, so using some code snippet doesn't look like a good alternative to UI support. > Anyway I sound like I don't like my baby being criticised. But I do > see the need for metadata, see the advantages of the conflict-free > extensibility, the flexibility and the integratedness of pragmas, > and sincerely think pragmas are a lot better than the competition. > Your mileage clearly varies. Actually no, *my* mileage doesn't vary that much. With good tool support I wouldn't have made any comment, so my criticisms of the implementation are in the context of non-existent/unsophisticated tool support, particularly for users with less experience and ST intuition than you (or even me). As far as implementation details are concerned, and particularly your rationale for it, I bow to your experience and investigation. However, I think the convenience of treating them like message sends in the meta model (and hence getting 'all implementors' for free) is offset by the fact that pragmas aren't 'invoked', and hence they lack a mechanism for the equivalent of 'all senders'. They implement only the destination end of the 'sending messages to objects' meme. I have a gut feel that it's a reasonable and pragmatic solution to a very difficult and fundamental-to-Smalltalk problem, although I do think that it doesn't integrate completely with with the underlying Smalltalk model. But then, Namespaces break the fundamental assumption of source/object coherence in the image and I couldn't live without them, so I accept that some things you just live with. As far as 'you're throwing the baby out with the bath water if you damn pragmas for poor tool support' is concerned, I'm going to reiterate that Smalltalk, in it's VW incarnation is only as good as it's tools, so on that basis I 'damn' pragmas as a development facility until they have decent tool support, because IMO they're only partially implemented without tool support. No offense intended. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 When I hear somebody sigh, 'Life is hard,' I am always tempted to ask, 'Compared to what?' -- Sydney Harris _______________________________________________ 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 |