April 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] how to model this a better way

by Richard O'Keefe

PS: in this thread nobody has disagreed about what OO programming is. The disagreement was about *how to apply it*. There actually seems to be quite a lot of agreement that the answer depends on what your underlying goal is: - is this throw-away code for a specific problem? - is this code to be included in a useful program? - is this just for practice in an unfamiliar language where you already understand all the concepts? - is this for learning about radically new concepts? And everyone agrees that test cases are good for all of these. You might find it useful to join another exercism thread and solve some of these problems in a language that you are comfortable with, then solve them in Smalltalk (or Ruby). This will help to separate "how do I solve this problem?" from "how do I express this solution in language X?" Another thing you might find useful, having solved a problem, is to try to solve it a different way. For example, in a functional language, you might solve a problem first in a C-like way using mutable objects freely. Then you might solve it again using immutable values. And then you might solve it again using higher-order functions. And then you might solve it again using point-free style as much as you can. For another example, in R, or Fortran 90, or Matlab, you might solve a problem first in an element-at-a-time way, and then you might try it again using vectorisation to eliminate as many loops as you can. And in *this* example, don't suppose that there is One Right Way To Do It. Get ONE solution going. ANY solution. I would suggest my approach, because (a) of course I would, and (b) it really is a struggle with exercism to find out what the problem actually is, and you want to get to SOME solution quickly. But it doesn't matter so much, because the point is to try it MORE ways than one. This is one way to learn design. Try more than one approach and discover which ones work out better. I started out using Point. Then I tried again just using bare coordinates. I started with position and velocity as instance variables. Then I tried again with them as method temporaries. I eliminated one thing after another until I was left with obviously correct code, and I felt no shame in using #caseOf: to classify characters, even though there are books that will tell you that using "if" and "case" is anti-OO. I could do it again eliminating #caseOf: in terms of "if" if I saw any value in doing so. In this particular exercise, you are simulating ONE instance (the robot) of ONE kind of thing (Robots). That strongly suggests that your solution might have ONE class: Robot, or perhaps TWO: Robot and RobotTest. That's the one active thing. This thing has properties: where it is and which way it is going. Now from the point of view of differential geometry, points and directions are different things and live in different abstract spaces, so I would have a lot of sympathy for having two classes: Place (x,y) and Direction (dx,dy) with #turnLeft and #turnRight as operations on Direction and place plus: distance in: direction as an operation on Place returning a new Place. But a good programmer is a lazy programmer, and looks for existing code to use. And the classic Point class in Smalltalk combines Place and Direction in one "two-dimensional vector" concept, originally designed for 2D computer graphics rather than geometry. It's good enough, and Smalltalk programmers can be expected to know that Point exists (just as Java programmers can be expected to know about Java's point classes), so I'd use it. So now, from one mind, we have designs with 1 Robot 2 Robot, RobotTest 3 Robot, RobotTest, Point 4 Robot, RobotTest, Place, Direction classes. ANY of them could be defended as a good design, depending on what the ultimate aim is.

April 25, 2019

Re: [Pharo-users] how to model this a better way

by Andres Valloud

Perhaps what's been unsaid in this thread is that sometimes exercises put some solution above all others (because it's presented as "the" answer). On the one hand, maybe the messages here make it seem like there's no single answer, as if the language was at fault. On the other hand, one learns more from exploring multiple avenues to solve a problem. I suspect that, after a while, one takes the latter attitude for granted. So, to be explicit, the cookbook way to programming will only get one so far. It's much better to consider multiple avenues, then weigh pros and cons. On 4/24/19 16:19 , Richard O'Keefe wrote: > Please don't quit Smalltalk. > I never said not to use classes. > That would be insane. > I said that *this specific exercise* is one > where *extra classes do not pay off. > This is in no way whatsoever a debate about > Pharo or Smalltalk. > We'd be having exactly the same discussion > in a list devoted to Java, Python, Ruby, or > any other OO programming language. > Please read > http://www.cs.otago.ac.nz/cosc345/bickerton.htm > It's a short page about learning. > > If you want to learn about OOP, the problem is not > Pharo or Smalltalk or even me. It's that exercism > is not designed to do that. It's designed to give > people who already know what they are doing in one > or more other languages practice in a new one. > > Do a web search for something like "How to learn OO design". > You will find little things like > <quote> > > qwertyuiop924 <https://news.ycombinator.com/user?id=qwertyuiop924> on > Sept 14, 2016 <https://news.ycombinator.com/item?id=12495808> [-] > > Here's the OOP model: > > A program can be modelled as a set of communicating black-box objects, > with their own state. > > The idea is to separate concerns, abstracting away implementation behind > well-defined interfaces, which can in turn be implemented by other > objects to cleanly replace parts of the application. > > The rest of OO is pretty much just understanding Design Patterns (a set > of names for common interactions between objects, and methods for > setting these interactions up), grokking inheritance, and the difference > between inheritance and composition, and grasping how to design a good > OO system (how thickly to layer your classes, how much abstraction and > what sorts, etc.) > > The best languages for learning OO are Ruby and Smalltalk. > > </quote> > > in https://news.ycombinator.com/item?id=12495117 > > You will find articles like > > https://medium.com/@richardeng/the-consequences-of-learning-oop-the-wrong-w… > > You will find courses. > > And look at the Pharo web site again: Stephan Ducasse has put up free > copies of several books about Smalltalk. I think he now has every one > I've heard of. Here's one link to get to them: > > http://stephane.ducasse.free.fr/FreeBooks.html > > > > > Smalltalk and Object Orientation: an Introduction > <http://sdmeta.gforge.inria.fr/FreeBooks/STandOO/Smalltalk-and-OO.pdf>, > > may be particularly helpful. > > > > On Thu, 25 Apr 2019 at 04:56, Roelof Wobben <r.wobben(a)home.nl > <mailto:r.wobben@home.nl>> wrote: > > Thanks all. > > Because of all the differences of oponion here what Object Oriented is > and im still very stuck at some exercises of exercism , I have to > decide > to quit smalltalk. > > One says to not use classes , the other says use classes. im more and > more confused. > > Maybe later I come back when I have a beter understanding what Object > Oriented is and how I can use it to solve more difficult problems. > > Roelof > > > Op 24-4-2019 om 18:07 schreef Ben Coman: > > On Wed, 24 Apr 2019 at 16:52, Richard O'Keefe <raoknz(a)gmail.com > <mailto:raoknz@gmail.com>> wrote: > >> The one method needed to solve the problem is 18 lines. > >> The test code, including all available test cases, is 27 > >> lines, of which 18 lines is the test data. Tests were > >> needed primarily to sort out what the problem actually *was*; > >> exercism doesn't even try to provide good specifications. > >> No debugging time at all was needed, precisely because the > >> code was so simple and obvious. > > But we do want to showcase our debugger and demonstrate how to get the > > most out of it. > > The way the exercises are structured is to sequentially enable one > > test at a time, see how that fails and fix it, so students will be > > regularly interacting with debugger. > > > > > >> If it *had* been needed, > >> viewing the result right next to the expression that yielded > >> it would have given me all the context I needed, in one window. > >> > >> If you want to learn how to design a good set of classes, > >> this is an absolutely dreadful problem. In fact ALL of the > >> exercism problems are going to be dreadful for *that* > >> purpose because they are provided for languages that do not > >> *have* classes. > > Yes, we noticed that. > > Do you have any problems more suited to class creation that we might > > contribute to the Exercism problem specifications? > > > > > >> If you want to learn how to *solve problems*, > >> then you need to learn to write code that is simple, clear, > >> testable, and so on. You certainly need to learn how to use > >> what is already there in the language (except where that is > >> expressly forbidden). > > My understanding of the Exercism's purpose is: > > * not to teach how to solve programming problems; but > > * to facilitate existing programmers to develop fluency in new > > languages (although that doesn't preclude complete beginners using > > it). > > [ref: search "fluency" at > > > https://opensource.com/article/17/1/interview-katrina-owen-founder-exercism] > > > > > >> I completely agree that designing a good set of classes is > >> a very very important skill for anyone who wants to do OOP. > >> I completely agree that practising this on problems you can > >> hold in your head is a good idea. > >> I completely agree that if *that* is your objective, > >> writing minimalist code is not the best strategy. > >> On Wed, 24 Apr 2019 at 16:59, Richard O'Keefe <raoknz(a)gmail.com > <mailto:raoknz@gmail.com>> wrote: > >>> TL;DR version: > >>> "But if the purpose of problems is to lead students in new > ways of > >>> thinking about structuring OO solutions for maintainability" > >>> It would be very good > >>> if somebody did craft such a set of exercises, and Pharo would > be a very > >>> good environment for them. The exercism exercises will not do. > > If the existing set of exercises is not great for this, hopefully we > > can produce some to demonstrate Pharo's facility for it. > > > > > >> The problem with exercism is that while it does have a > >> criterion by which you can tell whether you have *solved the > >> problem*, it provides *no* way to assess your class design. > >> You don't get told "this is good, that is bloated"; there is > >> no feedback about the *quality* of your code except via > >> comments from those few people who can be bothered to look > >> at other people's solutions and comment on them. And since > >> many of them will also be beginners, their comments may not > >> always help. > > Hopefully we can grow participation of experienced mentors > > to share the load providing *quality* feedback to distinguish the > > benefits of Pharo. > > > >> This particular problem is very similar to a "Langton's Ant" > >> problem my old department gave to students, who were expected > >> to solve it in two or three hours. And ALWAYS, the thing that > >> held them back was creating classes they didn't need and > >> agonising over what data and methods should go where (and then > >> getting it wrong, such is the nature of Java). > > My immediate reaction to that is that agonizing and getting it > wrong > > are a useful part of the learning process, but I recognize I could > > just be being contrary :) . > > I'll keep your observations in mind. > > > >> When a problem can be solved quite directly in 18 lines of > >> clean code, you are going to have a very hard time persuading > >> me that even one more class pays for itself, especially in a > >> system with a rich class library of stuff you don't have to write. > > Not trying to persuade you personally. > > Just providing an alternative viewpoint for anyone to consider. > > > > cheers -ben > > > > > >

April 25, 2019

Re: [Pharo-users] how to model this a better way

by Richard O'Keefe

Please don't quit Smalltalk. I never said not to use classes. That would be insane. I said that *this specific exercise* is one where *extra classes do not pay off. This is in no way whatsoever a debate about Pharo or Smalltalk. We'd be having exactly the same discussion in a list devoted to Java, Python, Ruby, or any other OO programming language. Please read http://www.cs.otago.ac.nz/cosc345/bickerton.htm It's a short page about learning. If you want to learn about OOP, the problem is not Pharo or Smalltalk or even me. It's that exercism is not designed to do that. It's designed to give people who already know what they are doing in one or more other languages practice in a new one. Do a web search for something like "How to learn OO design". You will find little things like <quote> qwertyuiop924 <https://news.ycombinator.com/user?id=qwertyuiop924> on Sept 14, 2016 <https://news.ycombinator.com/item?id=12495808> [-] Here's the OOP model: A program can be modelled as a set of communicating black-box objects, with their own state. The idea is to separate concerns, abstracting away implementation behind well-defined interfaces, which can in turn be implemented by other objects to cleanly replace parts of the application. The rest of OO is pretty much just understanding Design Patterns (a set of names for common interactions between objects, and methods for setting these interactions up), grokking inheritance, and the difference between inheritance and composition, and grasping how to design a good OO system (how thickly to layer your classes, how much abstraction and what sorts, etc.) The best languages for learning OO are Ruby and Smalltalk. </quote> in https://news.ycombinator.com/item?id=12495117 You will find articles like https://medium.com/@richardeng/the-consequences-of-learning-oop-the-wrong-w… You will find courses. And look at the Pharo web site again: Stephan Ducasse has put up free copies of several books about Smalltalk. I think he now has every one I've heard of. Here's one link to get to them: http://stephane.ducasse.free.fr/FreeBooks.html Smalltalk and Object Orientation: an Introduction <http://sdmeta.gforge.inria.fr/FreeBooks/STandOO/Smalltalk-and-OO.pdf>, may be particularly helpful. On Thu, 25 Apr 2019 at 04:56, Roelof Wobben <r.wobben(a)home.nl> wrote: > Thanks all. > > Because of all the differences of oponion here what Object Oriented is > and im still very stuck at some exercises of exercism , I have to decide > to quit smalltalk. > > One says to not use classes , the other says use classes. im more and > more confused. > > Maybe later I come back when I have a beter understanding what Object > Oriented is and how I can use it to solve more difficult problems. > > Roelof > > > Op 24-4-2019 om 18:07 schreef Ben Coman: > > On Wed, 24 Apr 2019 at 16:52, Richard O'Keefe <raoknz(a)gmail.com> wrote: > >> The one method needed to solve the problem is 18 lines. > >> The test code, including all available test cases, is 27 > >> lines, of which 18 lines is the test data. Tests were > >> needed primarily to sort out what the problem actually *was*; > >> exercism doesn't even try to provide good specifications. > >> No debugging time at all was needed, precisely because the > >> code was so simple and obvious. > > But we do want to showcase our debugger and demonstrate how to get the > > most out of it. > > The way the exercises are structured is to sequentially enable one > > test at a time, see how that fails and fix it, so students will be > > regularly interacting with debugger. > > > > > >> If it *had* been needed, > >> viewing the result right next to the expression that yielded > >> it would have given me all the context I needed, in one window. > >> > >> If you want to learn how to design a good set of classes, > >> this is an absolutely dreadful problem. In fact ALL of the > >> exercism problems are going to be dreadful for *that* > >> purpose because they are provided for languages that do not > >> *have* classes. > > Yes, we noticed that. > > Do you have any problems more suited to class creation that we might > > contribute to the Exercism problem specifications? > > > > > >> If you want to learn how to *solve problems*, > >> then you need to learn to write code that is simple, clear, > >> testable, and so on. You certainly need to learn how to use > >> what is already there in the language (except where that is > >> expressly forbidden). > > My understanding of the Exercism's purpose is: > > * not to teach how to solve programming problems; but > > * to facilitate existing programmers to develop fluency in new > > languages (although that doesn't preclude complete beginners using > > it). > > [ref: search "fluency" at > > > https://opensource.com/article/17/1/interview-katrina-owen-founder-exercism > ] > > > > > >> I completely agree that designing a good set of classes is > >> a very very important skill for anyone who wants to do OOP. > >> I completely agree that practising this on problems you can > >> hold in your head is a good idea. > >> I completely agree that if *that* is your objective, > >> writing minimalist code is not the best strategy. > >> On Wed, 24 Apr 2019 at 16:59, Richard O'Keefe <raoknz(a)gmail.com> wrote: > >>> TL;DR version: > >>> "But if the purpose of problems is to lead students in new ways of > >>> thinking about structuring OO solutions for maintainability" > >>> It would be very good > >>> if somebody did craft such a set of exercises, and Pharo would be a > very > >>> good environment for them. The exercism exercises will not do. > > If the existing set of exercises is not great for this, hopefully we > > can produce some to demonstrate Pharo's facility for it. > > > > > >> The problem with exercism is that while it does have a > >> criterion by which you can tell whether you have *solved the > >> problem*, it provides *no* way to assess your class design. > >> You don't get told "this is good, that is bloated"; there is > >> no feedback about the *quality* of your code except via > >> comments from those few people who can be bothered to look > >> at other people's solutions and comment on them. And since > >> many of them will also be beginners, their comments may not > >> always help. > > Hopefully we can grow participation of experienced mentors > > to share the load providing *quality* feedback to distinguish the > > benefits of Pharo. > > > >> This particular problem is very similar to a "Langton's Ant" > >> problem my old department gave to students, who were expected > >> to solve it in two or three hours. And ALWAYS, the thing that > >> held them back was creating classes they didn't need and > >> agonising over what data and methods should go where (and then > >> getting it wrong, such is the nature of Java). > > My immediate reaction to that is that agonizing and getting it wrong > > are a useful part of the learning process, but I recognize I could > > just be being contrary :) . > > I'll keep your observations in mind. > > > >> When a problem can be solved quite directly in 18 lines of > >> clean code, you are going to have a very hard time persuading > >> me that even one more class pays for itself, especially in a > >> system with a rich class library of stuff you don't have to write. > > Not trying to persuade you personally. > > Just providing an alternative viewpoint for anyone to consider. > > > > cheers -ben > > > > > > >

April 24, 2019

Re: [Pharo-users] Baseline subclasses

by Dale Henrichs

On 4/24/19 3:08 PM, Norbert Hartl wrote: > I donât have an idea how to achieve this with a group. It is about changing the number of dependencies of one package. There's load order and there's grouping... If you are using #linear loads for a BaselineOf then hard dependencies (Metacello requires:) dictate loadÂ order and load order is important. If you are using #atomic loads, then load order for packages is not important ... for #atomic loads you only need to specify which set of packages you want to have loaded together ... so if you have a baseline where you don't use #requires: anywhere and simply define different groups for each set of package to want to have loaded together (one for productA and another for productB) ... you should be able to get what you want ... If this is a public baseline, then you have to warn users of your project that the only legally loadable entities are the set of groups that you've created, then things should work well ... ... I'd think:) > > So no way of making Metacello load a package with one name and load a baseline with another name? Not sure what you are thinking about here ... i think I need a concrete example of what you mean here... Dale

April 24, 2019

Re: [Pharo-users] Baseline subclasses

by Norbert Hartl

> Am 24.04.2019 um 19:40 schrieb Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > > Do I understand you correctly that the BaselineOfWhiteLabelProduct is a subclass of BaselineOfCoreProduct? > Yes as I wrote. > If so, I have no idea what would happen and it certainly has never been tested ... and as I think about this I can see that there would definitely be problems ... I think you are lucky that you ran into problems right off the bat:) > If tried other ways like complete separate baseline. But referencing all entities from a foreign baseline to reuse is cumbersome. > I know that a BaselineOf is a class and folks have been having fun partitioning their BaselineOf "code" into different methods ... but the fact that a BaselineOf is a class was a matter of convenience way back when the only thing that could be versioned was a package and packages only held onto classes ... and with a class, the browser could be leveraged as a tool ... > > If STON had existed back then and we had been using a disk based SCM, I would have chosen STON for project specifications instead of a package and a class (as I'm doing today with Rowan) ... > > I understand what you are trying to do (I think) and I am (hopefully) addressing what you are trying to do in Rowan, but I'm afraid that you are just be out of luck trying to do this sort of thing with Metacello ... > The basic thing I would bewd is to load one package and execute a baseline with a different name. > You might be able to hack a solution that would _appear_ to work by using a shared abstract superclass of both products and include the superclass in both packages ... but I'm afraid that this approach would more than likely just give you a bit more rope to hang yourself with down the road:) ... of course putting the same class in two different packages is problematic all by itself ... > > I think that your best bet is to create a single BaselieOf and differentiate your two products with two groups ... I know it's not ideal, but at least this kind of thing has been pretty heavily tested ... I had something like this but defining the number of packages to load is easy to do in a polymorphic way. I donât have an idea how to achieve this with a group. It is about changing the number of dependencies of one package. So no way of making Metacello load a package with one name and load a baseline with another name? Thanks, Norbert > > Dale > >> On 4/24/19 9:24 AM, Norbert Hartl wrote: >> Iâm trying to customize our current project with multiple baselines meaning BaselineOfCoreProduct and BaselineOfWhiteLabelProduct. The latter is a subclass of the former. My problem is that I donât know which way to choose for loading because >> >> Metacello new >> baseline: #WhiteLabelProduct >> load >> >> that does not work if BaselineOfCoreProduct is in its own package because that is not loaded but the superclass is in there. I saw that I can provide an array to baseline: but regardless in which order I put them the wrong is always loaded first. So order of the array seem not to matter. >> >> >> I could still load BaselineOfCoreProduct first and then BaselineOfWhiteLabelProduct but I would like to have a better way of doing. I could also image putting both baselines in the same package but I donât know how to use Metacello to say it should load a package name and use another named Baseline. >> >> Any help appreciated, >> >> Norbert >

April 24, 2019

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

by TedVanGaalen

@Esteban: Of course you are right that there are cases a standalone app would be more convenient e.g. as you mentioned: graphical (image processing) apps, digital audio workstations, like Cubase. In most cases these are the kind of apps that deal with personal (local) data, which mostly is not connected to a central data storage on a hosting system. In other cases that is for users having real time access to data stored on a central point, web apps are preferable. Like the banking app, Internet shops. Also on a smaller scale as browser intranet apps e.g. small independent firms, clinics Law firms, accountancies and so on. Of course these should have web apps running in the firm's intranet only. These used to be client server apps, mostly with thin clients or ven just terminals (VT100) for example running on a mini computer e.g. DEC PDP 11/xx. Even today, mainframe applications all run on the host. Access is by terminal only. This is the most secure environment you can get. I initially grew up with mainframe application programming btw. So to me, it seems logical that -at least in a business environment- a single application (or a group of those) running on a central system (server) is preferable. There are many blogs and articles on the web that describe the pro and contra of web apps versus standalone apps. For example this blog: http://www.paulgraham.com/road.html (It's a bit of a long read, but I do recommend it) Paul Graham describes this theme much better than I ever can do. Note that this blog is written 18 years ago and he had to work with the technical limitations of 2000 and before. Today web technology is far more advanced, enabling us to make really professional web apps. Most limitations are gone. Seen in this perspective, Pharo (or some other Smalltalk versions) combined with Seaside are excellent tools to create versatile web apps in a relatively short amount of time. I think the limitations of designing and building professional web apps are perhaps much less than one might think. Like with many other challenges, one gets better by actually doing it. Some other points I'd like to react on: Dependency on 3rd party tools in combination with Pharo/Seaside? As far as I know now, in Seaside itself that would be only Javascript and jQuery? It is unlikely that these will disappear because the whole web world depends on these two. In Pharo image itself that would in most cases be at least a database like Postgress. If the need arises for special GUI web elements, these could be made relatively easy in Smalltalk. And of course it all relies heavily on CSS which is very advanced, but that's a good thing! A good book about CSS is helpful. Yet another reason for me to make -even stand alone- apps with Pharo as Seaside web apps is, that (at least for me) it is much harder to make a native GUI app within Pharo. Using the browser as GUI is much easier. Honestly, I doubt if this would be better if GTK is deployed as GUI? Also one would be bound to the GTK style/appearance and some themes they might provide. No such limitations exist using Seaside with good CSS styling. Also GTK does not work on mobile devices. So for me GTK or any other native GUI are out because of that. On a Mac (similar on Windows btw) GTK needs an extra layer. It uses the Quartz backend. GTK is not feature complete, riddled with bugs e.g. Wacom tablets with GIMP), new releases are not compatible etc. See for yourself. Don't stick your heads in a wasp nest. I don't understand why one would have to, because Pharo has excellent GUI elements. You could subclass Morph classes.? (I am not aware of most further GUI enhancements in Pharo, because I still cannot run Pharo 7 on my mac mini due to a VM problem since 2017, same with Squeak btw. (see other thread) still using pre-Spur Pharo 5) Imho, by coupling GTK to Pharo one creates an unstable big dependency situation. This stands opposite on having Smalltalk as autonomously and independent as possible. Errm, note btw that if you change addressing me as "fanatic" into "racing a bit too fast" i can accept this :o) (By "fanatic" I think of much worse things happening on our planet all the time. So sad) The "always as web app, whenever possible" is something I strive for, not that the whole world must do this. Thanks TedvG -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 24, 2019

Re: [Pharo-users] Baseline subclasses

by Dale Henrichs

Do I understand you correctly that the BaselineOfWhiteLabelProduct is a subclass of BaselineOfCoreProduct? If so, I have no idea what would happen and it certainly has never been tested ... and as I think about this I can see that there would definitely be problems ... I think you are lucky that you ran into problems right off the bat:) I know that a BaselineOf is a class and folks have been having fun partitioning their BaselineOf "code" into different methods ... but the fact that a BaselineOf is a class was a matter of convenience way back when the only thing that could be versioned was a package and packages only held onto classes ... and with a class, the browser could be leveraged as a tool ... If STON had existed back then and we had been using a disk based SCM, I would have chosen STON for project specifications instead of a package and a class (as I'm doing today with Rowan) ... I understand what you are trying to do (I think) and I am (hopefully) addressing what you are trying to do in Rowan, but I'm afraid that you are just be out of luck trying to do this sort of thing with Metacello ... You might be able to hack a solution that would _appear_ to work by using a shared abstract superclass of both products and include the superclass in both packages ... but I'm afraid that this approach would more than likely just give you a bit more rope to hang yourself with down the road:) ... of course putting the same class in two different packages is problematic all by itself ... I think that your best bet is to create a single BaselieOf and differentiate your two products with two groups ... I know it's not ideal, but at least this kind of thing has been pretty heavily tested ... Dale On 4/24/19 9:24 AM, Norbert Hartl wrote: > Iâm trying to customize our current project with multiple baselines meaning BaselineOfCoreProduct and BaselineOfWhiteLabelProduct. The latter is a subclass of the former. My problem is that I donât know which way to choose for loading because > > Metacello new > baseline: #WhiteLabelProduct > load > > that does not work if BaselineOfCoreProduct is in its own package because that is not loaded but the superclass is in there. I saw that I can provide an array to baseline: but regardless in which order I put them the wrong is always loaded first. So order of the array seem not to matter. > > > I could still load BaselineOfCoreProduct first and then BaselineOfWhiteLabelProduct but I would like to have a better way of doing. I could also image putting both baselines in the same package but I donât know how to use Metacello to say it should load a package name and use another named Baseline. > > Any help appreciated, > > Norbert

April 24, 2019

Re: [Pharo-users] how to model this a better way

by Roelof Wobben

Thanks all. Because of all the differences of oponion here what Object Oriented is and im still very stuck at some exercises of exercism , I have to decide to quit smalltalk. One says to not use classes , the other says use classes. im more and more confused. Maybe later I come back when I have a beter understanding what Object Oriented is and how I can use it to solve more difficult problems. Roelof Op 24-4-2019 om 18:07 schreef Ben Coman: > On Wed, 24 Apr 2019 at 16:52, Richard O'Keefe <raoknz(a)gmail.com> wrote: >> The one method needed to solve the problem is 18 lines. >> The test code, including all available test cases, is 27 >> lines, of which 18 lines is the test data. Tests were >> needed primarily to sort out what the problem actually *was*; >> exercism doesn't even try to provide good specifications. >> No debugging time at all was needed, precisely because the >> code was so simple and obvious. > But we do want to showcase our debugger and demonstrate how to get the > most out of it. > The way the exercises are structured is to sequentially enable one > test at a time, see how that fails and fix it, so students will be > regularly interacting with debugger. > > >> If it *had* been needed, >> viewing the result right next to the expression that yielded >> it would have given me all the context I needed, in one window. >> >> If you want to learn how to design a good set of classes, >> this is an absolutely dreadful problem. In fact ALL of the >> exercism problems are going to be dreadful for *that* >> purpose because they are provided for languages that do not >> *have* classes. > Yes, we noticed that. > Do you have any problems more suited to class creation that we might > contribute to the Exercism problem specifications? > > >> If you want to learn how to *solve problems*, >> then you need to learn to write code that is simple, clear, >> testable, and so on. You certainly need to learn how to use >> what is already there in the language (except where that is >> expressly forbidden). > My understanding of the Exercism's purpose is: > * not to teach how to solve programming problems; but > * to facilitate existing programmers to develop fluency in new > languages (although that doesn't preclude complete beginners using > it). > [ref: search "fluency" at > https://opensource.com/article/17/1/interview-katrina-owen-founder-exercism] > > >> I completely agree that designing a good set of classes is >> a very very important skill for anyone who wants to do OOP. >> I completely agree that practising this on problems you can >> hold in your head is a good idea. >> I completely agree that if *that* is your objective, >> writing minimalist code is not the best strategy. >> On Wed, 24 Apr 2019 at 16:59, Richard O'Keefe <raoknz(a)gmail.com> wrote: >>> TL;DR version: >>> "But if the purpose of problems is to lead students in new ways of >>> thinking about structuring OO solutions for maintainability" >>> It would be very good >>> if somebody did craft such a set of exercises, and Pharo would be a very >>> good environment for them. The exercism exercises will not do. > If the existing set of exercises is not great for this, hopefully we > can produce some to demonstrate Pharo's facility for it. > > >> The problem with exercism is that while it does have a >> criterion by which you can tell whether you have *solved the >> problem*, it provides *no* way to assess your class design. >> You don't get told "this is good, that is bloated"; there is >> no feedback about the *quality* of your code except via >> comments from those few people who can be bothered to look >> at other people's solutions and comment on them. And since >> many of them will also be beginners, their comments may not >> always help. > Hopefully we can grow participation of experienced mentors > to share the load providing *quality* feedback to distinguish the > benefits of Pharo. > >> This particular problem is very similar to a "Langton's Ant" >> problem my old department gave to students, who were expected >> to solve it in two or three hours. And ALWAYS, the thing that >> held them back was creating classes they didn't need and >> agonising over what data and methods should go where (and then >> getting it wrong, such is the nature of Java). > My immediate reaction to that is that agonizing and getting it wrong > are a useful part of the learning process, but I recognize I could > just be being contrary :) . > I'll keep your observations in mind. > >> When a problem can be solved quite directly in 18 lines of >> clean code, you are going to have a very hard time persuading >> me that even one more class pays for itself, especially in a >> system with a rich class library of stuff you don't have to write. > Not trying to persuade you personally. > Just providing an alternative viewpoint for anyone to consider. > > cheers -ben > >

April 24, 2019

Baseline subclasses

by Norbert Hartl

Iâm trying to customize our current project with multiple baselines meaning BaselineOfCoreProduct and BaselineOfWhiteLabelProduct. The latter is a subclass of the former. My problem is that I donât know which way to choose for loading because Metacello new baseline: #WhiteLabelProduct load that does not work if BaselineOfCoreProduct is in its own package because that is not loaded but the superclass is in there. I saw that I can provide an array to baseline: but regardless in which order I put them the wrong is always loaded first. So order of the array seem not to matter. I could still load BaselineOfCoreProduct first and then BaselineOfWhiteLabelProduct but I would like to have a better way of doing. I could also image putting both baselines in the same package but I donât know how to use Metacello to say it should load a package name and use another named Baseline. Any help appreciated, Norbert

April 24, 2019

Re: [Pharo-users] Pharo 7.0.3 dialog information at startup

by Ben Coman

On Wed, 24 Apr 2019 at 19:14, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> wrote: > > Ciao, > > i download the last Pharo 70 image ( on Ubuntu 16.04 LTS system ) > > with the commannd: wget -O- https://get.pharo.org/64/70+vm | bash > > > When i launch the relative ./pharo-ui > > after the opening the Pharo window > > the Pharo system open an information with: > > Information > Cannot read stored value of #pharoSystem#delaySchedulerClass. > Exception: KeyNotFound: key #DelaySpinScheduler not found in SystemDictionary > > Should i consider it as an important problem or can i proceed ignoring it? You can ignore. At some time past you saved your Pharo 6.0 preferences when DelaySpinScheduler was the default delay scheduler and its trying to restore that setting but in Pharo 7 DelaySemaphoreScheduler is the default and DelaySpinScheduler has been removed. So its trying to change to an invalid setting. Probably saving preferences again from Pharo 7 will make the error disappear, although may cause a similar error to appear starting Pharo 6 images. Or clear out the preferences folder (I forget its location). To handle this cleanly Preferences needs to be more sophisticated to be able to store certain preferences as version specific. cheers -ben P.S. DelaySpinScheduler had the presumption it was the only process running at highest-priority, which conflicted some code being added to Pharo 7, DelaySemaphoreScheduler removed that restriction.

April 24, 2019