Prerequisites and Class Inheritance
Locked
Prerequisites and Class Inheritance
 
|
I have a class TestA defined in package ProjectA with subclass TestB
defined in package ProjectB. TestA implements #boo. I also have package ProjectC. Here I define a class TestC which has this method: #initialize TestB new boo Now, using the Prerequisite tab (VisualWorks 7.8.1) on ProjectC, I can see that ProjectB is a prerequisite, since there is an “Object Reference” to TestB. This makes sense. However, since the method also performs #boo, there is a prerequisite to ProjectA, due to a “Unique Message Send”. I wonder if this is conceptually correct… I mean, when dealing with a class, should I really need to add dependencies for methods that happen to be defined in its super classes? As a client to the class, I should need to add dependencies as I keep using more of its methods? (Note that I see the need to add dependencies if I start using methods which are extended, but that is a topic for a separate thread…) Note that in .Net, simply referring TestB (and not sending #boo) would require a reference to ProjectA: http://stackoverflow.com/questions/4445213/net-inheritance-automatic-dependency-referencing-behavior-issue I am therefore wondering whether the calculation of “Object Reference” in VisualWorks should include all super classes’ packages too, and not only the class’ package. Making this change would be in line with .Net, and would mean you do not need adding prerequisites as you access additional methods. Kind regards Runar _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Prerequisites and Class Inheritance
|
|
Please keep in mind there are two kind of prerequisites; run time and load
time. You want load time prerequisites to be looser than run time. Requiring a run time prerequisites to be loaded first, can make it difficult to organize packages with lots of extensions. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Runar Jordahl > Sent: Thursday, May 10, 2012 8:08 AM > To: [hidden email] > Subject: [vwnc] Prerequisites and Class Inheritance > > I have a class TestA defined in package ProjectA with subclass TestB defined > in package ProjectB. > > TestA implements #boo. > > I also have package ProjectC. Here I define a class TestC which has this > method: > > #initialize > TestB new boo > > Now, using the Prerequisite tab (VisualWorks 7.8.1) on ProjectC, I can see > that ProjectB is a prerequisite, since there is an Object Reference to > This makes sense. > > However, since the method also performs #boo, there is a prerequisite to > ProjectA, due to a Unique Message Send. I wonder if this is conceptually > correct I mean, when dealing with a class, should I really need to add > dependencies for methods that happen to be defined in its super classes? As > a client to the class, I should need to add dependencies as I keep using more > of its methods? > > (Note that I see the need to add dependencies if I start using methods which > are extended, but that is a topic for a separate thread ) > > Note that in .Net, simply referring TestB (and not sending #boo) would > require a reference to ProjectA: > http://stackoverflow.com/questions/4445213/net-inheritance-automatic- > dependency-referencing-behavior-issue > > I am therefore wondering whether the calculation of Object Reference > in VisualWorks should include all super classes packages too, and not only > the class package. Making this change would be in line with .Net, and would > mean you do not need adding prerequisites as you access additional > methods. > > Kind regards > Runar > > _______________________________________________ > 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: Prerequisites and Class Inheritance
|
|
In reply to this post by Runar Jordahl
On May 10, 2012, at 5:08 AM, Runar Jordahl wrote: I have a class TestA defined in package ProjectA with subclass TestB One of my design principles about the prereq computation in VisualWorks was that it be relatively simple and straightforward. Some have called them "deep." I think that's trying to be nice. They really just are simple and exact. Well, as exact as they can be, the whole unique-message-sends is not guaranteed or exact, but it's a heuristic that works surprisingly well a LOT of the time. There are ways to "reduce" prerequisites. The most common one, is if PackA needs PackB and PackC, and PackB needs PackC, then should we really need to specify that PackA needs PackB and let PackC be inferred through PackB. What you note here, is another special case, where we could apply a reduction. My personal reasons for avoiding reduction of any kind, is that once you start down that slide, it's difficult to tell when you get off. You start writing more and more algorithms, to detect patterns where reduction is legal and apply them. I'm not convinced you'd be ever be able to find all of them. So you start ending up with results where sometimes you scratch your head and ask "wait, why isn't it grabbing PackZ?" or the opposite "it shouldn't be grabbing PackY, what is it doing?" Keeping it simple and straightforward seemed the best approach. If it's simple, I can look at it, realize why it differed from what my higher level pattern matching brain can do, and throw something in Disregard. The other half of the simplicity card was sheer pragmatism. The more complex the reduction engine becomes, the more opportunity for error, the more time it would have taken to write, and the more time it would take to do the actual computation. I wanted the computation to proceed pretty quickly. So, I guess to put it short, I don't disagree at all with the opportunity you see for prerequisite direction, it makes sense to me. I just took the approach when designing it, that I'd avoid reduction of any sort completely. -- Travis Griggs Objologist Simplicity is the Ultimate Sophistication -- Leonardo da Vinci _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Prerequisites and Class Inheritance
|
|
Dear Runar,
a related idea, on which your (and others') views would be of interest, is the half-way house of showing some indication - a fairly loud indicator, like underlining some prereqs but not others, or a more quiet one, like putting tiny icons on the icons - to distinguish between 'strong' and 'weak' prereqs. As Travis says, you can offer reasons for cutting down what makes a prereq, but you can also worry about whether you're trading not getting irrelevant information in some cases for not getting important information in others. In his example (PackageA prereqs PackageB which prereqs PackageC, which is also directly used by PackageA): - In one case, PackageA's direct use of PackageC may naturally, inevitably be mediated by PackageB. SUnit and SUnitPreload would be an example. Almost all prereqers of SUnit only want SUnitPreload because they want SUnit. One day, thanks to increasing ANSI conformance, SUnitPreload could disappear. It would be a pity if anyone found they had to redo all their test packages' prereqs because they'd been encouraged to include SUnitPreload explicitly as a prereq. - In another case, PackageA's direct use of PackageC may have nothing to do with PackageB. It may be a pure coincidence that Package B both happens to use PackageC and also to be used by PackageA - and it may cease being true in the next version of PackageB. Another way of saying this is the distinction between asking, "Have I enough prereqs to ensure this will load?" (so at this moment, I need only prereq package B), as against, "Have I prereqed everything I truly depend upon?", or the refactoring question "Forget loading/running - I want to understand what code I'm using because I'm about to rewrite things?" (Perhaps the aim of the rewrite is to reduce dependencies - in that case, hiding PackageC does you no favours.) So for Travis' example and also for yours, it would be interesting to get your personal preference on what you'd like to see: - as is - show all, but with indications of which items are only 'weakly' prerequisited - don't show only-weakly-prerequisited items The dread word settings had better be mentioned before someone else does, but with the obvious comment that settings could lead you back into Travis' point about maybe not seeing what you need to see - yes there's a setting to show it but will you turn it on for that case where you (don't know that you) need to? HTH Niall Ross >On May 10, 2012, at 5:08 AM, Runar Jordahl wrote: > > > >>I have a class TestA defined in package ProjectA with subclass TestB >>defined in package ProjectB. >> >>TestA implements #boo. >> >>I also have package ProjectC. Here I define a class TestC which has this method: >> >>#initialize >> TestB new boo >> >>Now, using the Prerequisite tab (VisualWorks 7.8.1) on ProjectC, I can >>see that ProjectB is a prerequisite, since there is an “Object >>Reference” to TestB. This makes sense. >> >>However, since the method also performs #boo, there is a prerequisite >>to ProjectA, due to a “Unique Message Send”. I wonder if this is >>conceptually correct… I mean, when dealing with a class, should I >>really need to add dependencies for methods that happen to be defined >>in its super classes? As a client to the class, I should need to add >>dependencies as I keep using more of its methods? >> >> > >One of my design principles about the prereq computation in VisualWorks was that it be relatively simple and straightforward. Some have called them "deep." I think that's trying to be nice. They really just are simple and exact. Well, as exact as they can be, the whole unique-message-sends is not guaranteed or exact, but it's a heuristic that works surprisingly well a LOT of the time. > >There are ways to "reduce" prerequisites. The most common one, is if PackA needs PackB and PackC, and PackB needs PackC, then should we really need to specify that PackA needs PackB and let PackC be inferred through PackB. What you note here, is another special case, where we could apply a reduction. > >My personal reasons for avoiding reduction of any kind, is that once you start down that slide, it's difficult to tell when you get off. You start writing more and more algorithms, to detect patterns where reduction is legal and apply them. I'm not convinced you'd be ever be able to find all of them. So you start ending up with results where sometimes you scratch your head and ask "wait, why isn't it grabbing PackZ?" or the opposite "it shouldn't be grabbing PackY, what is it doing?" Keeping it simple and straightforward seemed the best approach. If it's simple, I can look at it, realize why it differed from what my higher level pattern matching brain can do, and throw something in Disregard. > >The other half of the simplicity card was sheer pragmatism. The more complex the reduction engine becomes, the more opportunity for error, the more time it would have taken to write, and the more time it would take to do the actual computation. I wanted the computation to proceed pretty quickly. > >So, I guess to put it short, I don't disagree at all with the opportunity you see for prerequisite direction, it makes sense to me. I just took the approach when designing it, that I'd avoid reduction of any sort completely. > >-- >Travis Griggs >Objologist >Simplicity is the Ultimate Sophistication -- Leonardo da Vinci > > > > >------------------------------------------------------------------------ > >_______________________________________________ >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 |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |