Where to put the complexity?
Locked
 
|
I've been peeking around the image a bit lately and ran across something
that got me thinking about this question: several of the exception subclasses seem to be largely one-shot affairs. Granted, the main categories like Notification, Error, Halt etc. are used all over the place, have different behaviors and given the importance of what they convey, provide value. However, when you start looking at the 3rd+ level Exception subclasses, some of them look a little sketchy to me. I'm not talking about more widely used exceptions like ZeroDivide but rather things like ReparseAfterSourceEditing... unless I'm missing something, it is raised in 3 places (in 2 classes) and handled in 1 just so that a very specific message can be sent to what appears to be a single listener. Is it worth having a class for this vs. raising the more general Notification and then checking for a #ReparseAfterSourceEditing signal, and if it isn't, re-raise Notification in its sole handler? This is a specific example of the more general question of where to draw the line on having single, or very limited, use classes and methods vs. adding a tiny bit of complexity in one or two methods to simplify the overall image or package in question. Thoughts? The core image part of the question is directed to Juan (i.e. should I bother reworking things like this and submitting pull requests when I see them?) but I was also curious what others thought about this from the standpoint of general coding style... Thanks, Phil _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
On Mon, 29 Jun 2015 07:09:43 -0400
"Phil (list)" <[hidden email]> wrote: > .. Is it > worth having a class for this vs. raising the more general Notification > and then checking for a #ReparseAfterSourceEditing signal, and if it > isn't, re-raise Notification in its sole handler? > .. > This is a specific example of the more general question of where to draw > the line on having single, or very limited, use classes and methods vs. > adding a tiny bit of complexity in one or two methods to simplify the > overall image or package in question. Thoughts? I would say the overriding goal is clarity. It is important work to refactor code to have the same behavior but be easier to understand. A Smalltalk style goal is to have small methods which do things clearly. This tends to lead to lots of small methods. Specializing classes for one or just a few methods may seem wasteful, but computer resources are cheap. Look at class #PartsBinMorph. Would you say the having the additional class is wasteful? It is a tough balance. Aesthetics and restraint require judgement and we don't always get it right. It takes time. I only have so many life hours left. I feel my time is valuable. I prefer to understand. Thank you so much for taking the time to make Cuis more comprehensible. $0.02 -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
Re: Where to put the complexity?
|
|
Hi folks,
On 6/29/2015 10:51 AM, Ken.Dickey wrote: > On Mon, 29 Jun 2015 07:09:43 -0400 > "Phil (list)"<[hidden email]> wrote: >> .. Is it >> worth having a class for this vs. raising the more general Notification >> and then checking for a #ReparseAfterSourceEditing signal, and if it >> isn't, re-raise Notification in its sole handler? >> .. >> This is a specific example of the more general question of where to draw >> the line on having single, or very limited, use classes and methods vs. >> adding a tiny bit of complexity in one or two methods to simplify the >> overall image or package in question. Thoughts? > I would say the overriding goal is clarity. > > It is important work to refactor code to have the same behavior but be easier to understand. > > A Smalltalk style goal is to have small methods which do things clearly. This tends to lead to lots of small methods. > > Specializing classes for one or just a few methods may seem wasteful, but computer resources are cheap. > > Look at class #PartsBinMorph. Would you say the having the additional class is wasteful? > > It is a tough balance. Aesthetics and restraint require judgement and we don't always get it right. It takes time. > > I only have so many life hours left. I feel my time is valuable. I prefer to understand. > > Thank you so much for taking the time to make Cuis more comprehensible. > > $0.02 > -KenD I fully support Ken. I don't think that a general answer is correct in all cases here. It is a matter of making code easy to understand. But also making it consistent and pretty. In general, I don't like making general classes know much about details of specific use cases. But there might be exceptions. If you feel like experimenting with this kind of stuff, send your suggestions to the mail list so we can discuss. In the particular case of ReparseAfterSourceEditing, I agree that a class that does nothing is a bit strange. But, what is the alternative? How would the sole exception handler know what to do with a general Notification? I think the handler looks quite reasonable right now. And the pollution of the global space might be tolerable if the alternative is more convoluted code... $0.02, not really a strong opinion. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On Mon, 2015-06-29 at 13:23 -0300, Juan Vuletich wrote:
> Hi folks, > > On 6/29/2015 10:51 AM, Ken.Dickey wrote: > > On Mon, 29 Jun 2015 07:09:43 -0400 > > "Phil (list)"<[hidden email]> wrote: > >> .. Is it > >> worth having a class for this vs. raising the more general Notification > >> and then checking for a #ReparseAfterSourceEditing signal, and if it > >> isn't, re-raise Notification in its sole handler? > >> .. > >> This is a specific example of the more general question of where to draw > >> the line on having single, or very limited, use classes and methods vs. > >> adding a tiny bit of complexity in one or two methods to simplify the > >> overall image or package in question. Thoughts? > > I would say the overriding goal is clarity. > > > > It is important work to refactor code to have the same behavior but be easier to understand. > > > > A Smalltalk style goal is to have small methods which do things clearly. This tends to lead to lots of small methods. > > > > Specializing classes for one or just a few methods may seem wasteful, but computer resources are cheap. > > > > Look at class #PartsBinMorph. Would you say the having the additional class is wasteful? > > > > It is a tough balance. Aesthetics and restraint require judgement and we don't always get it right. It takes time. > > > > I only have so many life hours left. I feel my time is valuable. I prefer to understand. > > > > Thank you so much for taking the time to make Cuis more comprehensible. > > > > $0.02 > > -KenD > Thanks for the feedback Ken. I wasn't concerned with the computing resources (at all) but rather the overall system complexity that results from these one-shot types of classes and methods. i.e. is it worth an extra class or method here and there to save 1-2 lines of code in a single, or even a couple, method(s). Just spit-balling there are probably ~100 (maybe as many as 200) classes, and who knows how many methods, like this left in Cuis. Agreed that this is getting into an area of diminishing returns. One thing that is different to me about PartsBinMorph, at least at first glance, is that it involves both state and behavior. I was really thinking more of the extremes where classes exist purely to do one or the other since they are often at best saving 1-2 lines of code somewhere else. > I fully support Ken. I don't think that a general answer is correct in > all cases here. It is a matter of making code easy to understand. But > also making it consistent and pretty. > > In general, I don't like making general classes know much about details > of specific use cases. But there might be exceptions. > > If you feel like experimenting with this kind of stuff, send your > suggestions to the mail list so we can discuss. > > In the particular case of ReparseAfterSourceEditing, I agree that a > class that does nothing is a bit strange. But, what is the alternative? > How would the sole exception handler know what to do with a general > Notification? I think the handler looks quite reasonable right now. And > the pollution of the global space might be tolerable if the alternative > is more convoluted code... > And thank you Juan. In the case of these one-shot exceptions, I was thinking that the information could be communicated via the signal: text. i.e. rather than raising ReparseAfterSourceEditing, one could instead raise Notification signal: #ReparseAfterSourceEditing. However, that would require that the exception handler trigger on Notification, check the signal text in the handler, and if it isn't #ReparseAfterSourceEditing re-raise the Notification if it determines that it's not handling it after all. > $0.02, not really a strong opinion. I could go either way on this as well which is why I asked... > > Cheers, > Juan Vuletich > Thanks, Phil _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
In reply to this post by Juan Vuletich-4
On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
> Hi folks, > > On 6/29/2015 10:51 AM, Ken.Dickey wrote: > > On Mon, 29 Jun 2015 07:09:43 -0400 > > "Phil (list)"<[hidden email]> wrote: > >> .. Is it > >> worth having a class for this vs. raising the more general > Notification > >> and then checking for a #ReparseAfterSourceEditing signal, and if > it > >> isn't, re-raise Notification in its sole handler? > >> .. > >> This is a specific example of the more general question of where > to draw > >> the line on having single, or very limited, use classes and > methods vs. > >> adding a tiny bit of complexity in one or two methods to simplify > the > >> overall image or package in question. Thoughts? > > I would say the overriding goal is clarity. > > > > It is important work to refactor code to have the same behavior > but be easier to understand. > > > > A Smalltalk style goal is to have small methods which do things > clearly. This tends to lead to lots of small methods. > > > > Specializing classes for one or just a few methods may seem > wasteful, but computer resources are cheap. > > > > Look at class #PartsBinMorph. Would you say the having the > additional class is wasteful? > > > > It is a tough balance. Aesthetics and restraint require judgement > and we don't always get it right. It takes time. > > > > I only have so many life hours left. I feel my time is valuable. > I prefer to understand. > > > > Thank you so much for taking the time to make Cuis more > comprehensible. > > > > $0.02 > > -KenD > > I fully support Ken. I don't think that a general answer is correct > in > all cases here. It is a matter of making code easy to understand. > But > also making it consistent and pretty. > > In general, I don't like making general classes know much about > details > of specific use cases. But there might be exceptions. > > If you feel like experimenting with this kind of stuff, send your > suggestions to the mail list so we can discuss. > > In the particular case of ReparseAfterSourceEditing, I agree that a > class that does nothing is a bit strange. But, what is the > alternative? > How would the sole exception handler know what to do with a general > Notification? I think the handler looks quite reasonable right now. > And > the pollution of the global space might be tolerable if the > alternative > is more convoluted code... > Making code easy to understand is very valuable. Simple things should be simple to accomplish, but achieving this in an API may not always be easy. This weekend I spent lots of "quality time" with the debugger, trying to figure out why I could not get a new window with a PluggableListMorph to work like another one which had exactly the behavior I wanted. The bug was that a method referred to by the #indexSetter: keyword needed to send the #selectedItem: message, which is not mentioned by keyword. Not sure what the answer is for that one but I'm working on notes to try to avoid that stupid mistake in the future. :) I'm just saying we should do anything we can to enhance clarity as well as simplify. - Dan _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Where to put the complexity?
|
|
2015-06-30 0:17 GMT+02:00 Dan Norton <[hidden email]>:
Since you are using the right keywords, maybe it's time to view it again
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Where to put the complexity?
|
|
Hi all, I believe that a class can be justified simply because it gives you an intention revealing name in the code, and room to put a class comment (possibly an extensive one). Especially with exceptions it can be difficult to understand what exactly the exception is for, and a class comment can be extremely helpful. So, one thing that I am saying is that a class with NO behavior but a well-chosen name, superclass and a clear class comment, can be a very valuable part of a system. Another thing I believe is that a class by itself is not very complex. Complex in the sense of adding to the overall complexity of the system. I have been interested in complexity and reducing it for a very long time (since before I started with Smalltalk) and I have often thought about the rules one would put into a tool that automatically measured the complexity of a system of code. One application of such a tool would be refactoring. Generally, after I refactor, all my old tests should still run, but also, my overall complexity should be lower. At least, that was my thinking, and a tool that measures complexity could help with that. In a sense it would be a more sophisticated version of the "rule of three". In any case, I never implemented such a tool, but did develop a set of heuristics/rules that I let guide me to decide whether I should extract methods, extract classes, etc. Part of these heuristics was that a class by itself did not add that much. I don't remember most of my rules although I probably still follow them intuitively. Perhaps a class added more complexity than a method, but not more than two methods, I don't really know. I wonder what others do to decide how to factor code. Cheers, Peter On Wed, Jul 1, 2015 at 2:52 PM, Nicolas Cellier <[hidden email]> wrote:
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On Wed, 2015-07-01 at 22:10 +0200, Peter van Rooijen wrote:
> Hi all, > > > I believe that a class can be justified simply because it gives you > an intention revealing name in the code, and room to put a > class comment (possibly an extensive one). > I believe that's the thinking that results in most of the current Exception subclasses. I personally don't care for it, but will go with the consensus which seems to be OK with it. > > Especially with exceptions it can be difficult to understand > what exactly the exception is for, and a class comment can > be extremely helpful. > But Exceptions have a #signal: value which could also easily convey that information. (that's not always true, but the point is there are other ways to convey the information other than subclassing) Also keep in mind that many exceptions, such as the one I was pointing out, are never even seen by the user: they are used as an alternate messaging channel by the code. > > So, one thing that I am saying is that a class with NO behavior > but a well-chosen name, superclass and a clear class comment, can > be a very valuable part of a system. > > > Another thing I believe is that a class by itself is not very complex. > Complex in the sense of adding to the overall complexity of the > system. > True, a single class by itself is not very complex. Multiply that by 100x or more and the story changes. To me, one of the more obvious aspects of complexity is the aggregate # of classes/methods/lines of code in a system. In this particular case, I was wondering out loud if this particular trade-off (i.e. creating a class to save 1-2 lines of code) was worth it. I find it interesting that exception handling is one of the younger parts of Smalltalk and, to me at least, it really stands out as being rather strangely implemented in terms of the class hierarchy. > > I have been interested in complexity and reducing it for a very long > time > (since before I started with Smalltalk) and I have often thought about > the rules one would put into a tool that automatically measured the > complexity of a system of code. > > > One application of such a tool would be refactoring. Generally, after > I > refactor, all my old tests should still run, but also, my overall > complexity > should be lower. > > > At least, that was my thinking, and a tool that measures > complexity could help with that. In a sense it would be a more > sophisticated version of the "rule of three". > > > In any case, I never implemented such a tool, but did develop a set of > heuristics/rules that I let guide me to decide whether I should > extract > methods, extract classes, etc. Part of these heuristics was that a > class > by itself did not add that much. > > > I don't remember most of my rules although I probably still follow > them > intuitively. Perhaps a class added more complexity than a method, but > not > more than two methods, I don't really know. > > > I wonder what others do to decide how to factor code. > You might want to take a look at Moose http://www.moosetechnology.org/ It's a tool to help you analyze and understand a given body of code. It's a bit fragile/brittle/incomplete, but right now it's about the best I've found to date to try to analyze and quantify complexity. Also, you could take a look at the work VPRI is doing related to FoNC/STEPS as minimizing complexity is core to what they are working on. > > Cheers, Peter > > > > > > On Wed, Jul 1, 2015 at 2:52 PM, Nicolas Cellier > <[hidden email]> wrote: > > > 2015-06-30 0:17 GMT+02:00 Dan Norton <[hidden email]>: > On 29 Jun 2015 at 13:23, Juan Vuletich wrote: > > > Hi folks, > > > > On 6/29/2015 10:51 AM, Ken.Dickey wrote: > > > On Mon, 29 Jun 2015 07:09:43 -0400 > > > "Phil (list)"<[hidden email]> wrote: > > >> .. Is it > > >> worth having a class for this vs. raising the > more general > > Notification > > >> and then checking for a > #ReparseAfterSourceEditing signal, and if > > it > > >> isn't, re-raise Notification in its sole handler? > > >> .. > > >> This is a specific example of the more general > question of where > > to draw > > >> the line on having single, or very limited, use > classes and > > methods vs. > > >> adding a tiny bit of complexity in one or two > methods to simplify > > the > > >> overall image or package in question. Thoughts? > > > I would say the overriding goal is clarity. > > > > > > It is important work to refactor code to have the > same behavior > > but be easier to understand. > > > > > > A Smalltalk style goal is to have small methods > which do things > > clearly. This tends to lead to lots of small > methods. > > > > > > Specializing classes for one or just a few methods > may seem > > wasteful, but computer resources are cheap. > > > > > > Look at class #PartsBinMorph. Would you say the > having the > > additional class is wasteful? > > > > > > It is a tough balance. Aesthetics and restraint > require judgement > > and we don't always get it right. It takes time. > > > > > > I only have so many life hours left. I feel my > time is valuable. > > I prefer to understand. > > > > > > Thank you so much for taking the time to make Cuis > more > > comprehensible. > > > > > > $0.02 > > > -KenD > > > > I fully support Ken. I don't think that a general > answer is correct > > in > > all cases here. It is a matter of making code easy > to understand. > > But > > also making it consistent and pretty. > > > > In general, I don't like making general classes know > much about > > details > > of specific use cases. But there might be > exceptions. > > > > If you feel like experimenting with this kind of > stuff, send your > > suggestions to the mail list so we can discuss. > > > > In the particular case of ReparseAfterSourceEditing, > I agree that a > > class that does nothing is a bit strange. But, what > is the > > alternative? > > How would the sole exception handler know what to do > with a general > > Notification? I think the handler looks quite > reasonable right now. > > And > > the pollution of the global space might be tolerable > if the > > alternative > > is more convoluted code... > > > > > Making code easy to understand is very valuable. > Simple things should be simple to > accomplish, but achieving this in an API may not > always be easy. > > This weekend I spent lots of "quality time" with the > debugger, trying to figure out why I could > not get a new window with a PluggableListMorph to work > like another one which had exactly > the behavior I wanted. The bug was that a method > referred to by the #indexSetter: keyword > needed to send the #selectedItem: message, which is > not mentioned by keyword. Not sure > what the answer is for that one but I'm working on > notes to try to avoid that stupid mistake in > the future. :) > > I'm just saying we should do anything we can to > enhance clarity as well as simplify. > > - Dan > > > > > Since you are using the right keywords, maybe it's time to > view it again > > Simple made easy > http://www.infoq.com/presentations/Simple-Made-Easy > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Where to put the complexity?
|
|
In reply to this post by Nicolas Cellier
On 7/1/2015 9:52 AM, Nicolas Cellier wrote:
> ... > > Since you are using the right keywords, maybe it's time to view it again > Simple made easy > http://www.infoq.com/presentations/Simple-Made-Easy Thanks Nicolas. This is absolutely wonderful! Really inspiring. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Where to put the complexity?
|
|
In reply to this post by Peter van Rooijen-2
On 7/1/2015 5:10 PM, Peter van Rooijen wrote:
> ... > > I don't remember most of my rules although I probably still follow them > intuitively. Perhaps a class added more complexity than a method, but not > more than two methods, I don't really know. > > I wonder what others do to decide how to factor code. > > Cheers, Peter To me Smalltalk code is an expression of human knowledge. I refactor code when I understand better, to express that new understanding. Writing code is like writing course material, or a technical book on some subject. Good code is like a good book. You read it and understand. That's the gold standard. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Nicolas Cellier
Hi,
I would like to view this, especially since it is recommended by Nicolas, Paul, and Juan. The question is how to view it without disabling my antivirus plus surrendering a bunch of "required" info. BTW I'm running Win7, IE, and ESET. Any other possibilities? - Dan On 1 Jul 2015 at 14:52, Nicolas Cellier wrote: > > > > 2015-06-30 0:17 GMT+02:00 Dan Norton <[hidden email]>: > On 29 Jun 2015 at 13:23, Juan Vuletich wrote: > > > Hi folks, > > > > On 6/29/2015 10:51 AM, Ken.Dickey wrote: > > > On Mon, 29 Jun 2015 07:09:43 -0400 > > > "Phil (list)"<[hidden email]> wrote: > > >> .. Is it > > >> worth having a class for this vs. raising the more > general > > Notification > > >> and then checking for a #ReparseAfterSourceEditing signal, > and if > > it > > >> isn't, re-raise Notification in its sole handler? > > >> .. > > >> This is a specific example of the more general question of > where > > to draw > > >> the line on having single, or very limited, use classes > and > > methods vs. > > >> adding a tiny bit of complexity in one or two methods to > simplify > > the > > >> overall image or package in question. Thoughts? > > > I would say the overriding goal is clarity. > > > > > > It is important work to refactor code to have the same > behavior > > but be easier to understand. > > > > > > A Smalltalk style goal is to have small methods which do > things > > clearly. This tends to lead to lots of small methods. > > > > > > Specializing classes for one or just a few methods may > seem > > wasteful, but computer resources are cheap. > > > > > > Look at class #PartsBinMorph. Would you say the having > the > > additional class is wasteful? > > > > > > It is a tough balance. Aesthetics and restraint require > judgement > > and we don't always get it right. It takes time. > > > > > > I only have so many life hours left. I feel my time is > valuable. > > I prefer to understand. > > > > > > Thank you so much for taking the time to make Cuis more > > comprehensible. > > > > > > $0.02 > > > -KenD > > > > I fully support Ken. I don't think that a general answer is > correct > > in > > all cases here. It is a matter of making code easy to > understand. > > But > > also making it consistent and pretty. > > > > In general, I don't like making general classes know much > about > > details > > of specific use cases. But there might be exceptions. > > > > If you feel like experimenting with this kind of stuff, send > your > > suggestions to the mail list so we can discuss. > > > > In the particular case of ReparseAfterSourceEditing, I agree > that a > > class that does nothing is a bit strange. But, what is the > > alternative? > > How would the sole exception handler know what to do with a > general > > Notification? I think the handler looks quite reasonable right > now. > > And > > the pollution of the global space might be tolerable if the > > alternative > > is more convoluted code... > > > > Making code easy to understand is very valuable. Simple things > should be simple to > accomplish, but achieving this in an API may not always be > easy. > > This weekend I spent lots of "quality time" with the debugger, > trying to figure out why I could > not get a new window with a PluggableListMorph to work like > another one which had exactly > the behavior I wanted. The bug was that a method referred to by > the #indexSetter: keyword > needed to send the #selectedItem: message, which is not > mentioned by keyword. Not sure > what the answer is for that one but I'm working on notes to try > to avoid that stupid mistake in > the future. :) > > I'm just saying we should do anything we can to enhance clarity > as well as simplify. > > - Dan > > > Since you are using the right keywords, maybe it's time to view it > again > Simple made easy > http://www.infoq.com/presentations/Simple-Made-Easy > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Where to put the complexity?
|
|
Hi Dan,
It plays without problems in Chrome on my Win7 PC. No need to supply any info at all. HTH, Juan vuletich On Thu, July 2, 2015 10:15 pm, Dan Norton wrote: > Hi, > > > I would like to view this, especially since it is recommended by Nicolas, > Paul, and Juan. The > question is how to view it without disabling my antivirus plus > surrendering a bunch of "required" info. BTW I'm running Win7, IE, and > ESET. > > > Any other possibilities? > > > - Dan > > > On 1 Jul 2015 at 14:52, Nicolas Cellier wrote: > > >> >> >> >> 2015-06-30 0:17 GMT+02:00 Dan Norton <[hidden email]>: >> On 29 Jun 2015 at 13:23, Juan Vuletich wrote: >> >> >>> Hi folks, >>> >>> >>> On 6/29/2015 10:51 AM, Ken.Dickey wrote: >>> >>>> On Mon, 29 Jun 2015 07:09:43 -0400 >>>> "Phil (list)"<[hidden email]> wrote: >>>> >>>>> .. Is it >>>>> worth having a class for this vs. raising the more >> general >>> Notification >>> >>>>> and then checking for a #ReparseAfterSourceEditing signal, >> and if >>> it >>>>> isn't, re-raise Notification in its sole handler? .. >>>>> This is a specific example of the more general question of >>>>> >> where >>> to draw >>>>> the line on having single, or very limited, use classes >> and >>> methods vs. >>>>> adding a tiny bit of complexity in one or two methods to >> simplify >>> the >>>>> overall image or package in question. Thoughts? >>>> I would say the overriding goal is clarity. >>>> >>>> >>>> It is important work to refactor code to have the same >>>> >> behavior >>> but be easier to understand. >>>> >>>> A Smalltalk style goal is to have small methods which do >>>> >> things >>> clearly. This tends to lead to lots of small methods. >>>> >>>> Specializing classes for one or just a few methods may >>>> >> seem >>> wasteful, but computer resources are cheap. >>>> >>>> Look at class #PartsBinMorph. Would you say the having >>>> >> the >>> additional class is wasteful? >>>> >>>> It is a tough balance. Aesthetics and restraint require >>>> >> judgement >>> and we don't always get it right. It takes time. >>>> >>>> I only have so many life hours left. I feel my time is >>>> >> valuable. >>> I prefer to understand. >>> >>>> >>>> Thank you so much for taking the time to make Cuis more >>>> >>> comprehensible. >>>> >>>> $0.02 >>>> -KenD >>>> >>> >>> I fully support Ken. I don't think that a general answer is >>> >> correct >>> in all cases here. It is a matter of making code easy to >> understand. >>> But >>> also making it consistent and pretty. >>> >>> In general, I don't like making general classes know much >>> >> about >>> details of specific use cases. But there might be exceptions. >>> >>> If you feel like experimenting with this kind of stuff, send >>> >> your >>> suggestions to the mail list so we can discuss. >>> >>> In the particular case of ReparseAfterSourceEditing, I agree >>> >> that a >>> class that does nothing is a bit strange. But, what is the >>> alternative? How would the sole exception handler know what to do with >>> a >> general >>> Notification? I think the handler looks quite reasonable right >>> >> now. >>> And >>> the pollution of the global space might be tolerable if the alternative >>> is more convoluted code... >>> >> >> Making code easy to understand is very valuable. Simple things >> should be simple to accomplish, but achieving this in an API may not >> always be easy. >> >> This weekend I spent lots of "quality time" with the debugger, >> trying to figure out why I could not get a new window with a >> PluggableListMorph to work like >> another one which had exactly the behavior I wanted. The bug was that a >> method referred to by the #indexSetter: keyword needed to send the >> #selectedItem: message, which is not >> mentioned by keyword. Not sure what the answer is for that one but I'm >> working on notes to try to avoid that stupid mistake in the future. :) >> >> I'm just saying we should do anything we can to enhance clarity >> as well as simplify. >> >> - Dan >> >> >> >> Since you are using the right keywords, maybe it's time to view it >> again Simple made easy >> http://www.infoq.com/presentations/Simple-Made-Easy >> >> >> _______________________________________________ >> Cuis mailing list >> [hidden email] >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> >> > > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Dan Norton
You're probably trying one of the download links. You can stream the
video as long as JavaScript is enabled. If you can't temporarily do this in IE, I'd highly recommend keeping Firefox+NoScript around as it lets you temporarily enable JavaScript & cookies for this type of scenario. On Thu, 2015-07-02 at 21:15 -0400, Dan Norton wrote: > Hi, > > I would like to view this, especially since it is recommended by Nicolas, Paul, and Juan. The > question is how to view it without disabling my antivirus plus surrendering a bunch of > "required" info. BTW I'm running Win7, IE, and ESET. > > Any other possibilities? > > - Dan > > On 1 Jul 2015 at 14:52, Nicolas Cellier wrote: > > > > > > > > > 2015-06-30 0:17 GMT+02:00 Dan Norton <[hidden email]>: > > On 29 Jun 2015 at 13:23, Juan Vuletich wrote: > > > > > Hi folks, > > > > > > On 6/29/2015 10:51 AM, Ken.Dickey wrote: > > > > On Mon, 29 Jun 2015 07:09:43 -0400 > > > > "Phil (list)"<[hidden email]> wrote: > > > >> .. Is it > > > >> worth having a class for this vs. raising the more > > general > > > Notification > > > >> and then checking for a #ReparseAfterSourceEditing signal, > > and if > > > it > > > >> isn't, re-raise Notification in its sole handler? > > > >> .. > > > >> This is a specific example of the more general question of > > where > > > to draw > > > >> the line on having single, or very limited, use classes > > and > > > methods vs. > > > >> adding a tiny bit of complexity in one or two methods to > > simplify > > > the > > > >> overall image or package in question. Thoughts? > > > > I would say the overriding goal is clarity. > > > > > > > > It is important work to refactor code to have the same > > behavior > > > but be easier to understand. > > > > > > > > A Smalltalk style goal is to have small methods which do > > things > > > clearly. This tends to lead to lots of small methods. > > > > > > > > Specializing classes for one or just a few methods may > > seem > > > wasteful, but computer resources are cheap. > > > > > > > > Look at class #PartsBinMorph. Would you say the having > > the > > > additional class is wasteful? > > > > > > > > It is a tough balance. Aesthetics and restraint require > > judgement > > > and we don't always get it right. It takes time. > > > > > > > > I only have so many life hours left. I feel my time is > > valuable. > > > I prefer to understand. > > > > > > > > Thank you so much for taking the time to make Cuis more > > > comprehensible. > > > > > > > > $0.02 > > > > -KenD > > > > > > I fully support Ken. I don't think that a general answer is > > correct > > > in > > > all cases here. It is a matter of making code easy to > > understand. > > > But > > > also making it consistent and pretty. > > > > > > In general, I don't like making general classes know much > > about > > > details > > > of specific use cases. But there might be exceptions. > > > > > > If you feel like experimenting with this kind of stuff, send > > your > > > suggestions to the mail list so we can discuss. > > > > > > In the particular case of ReparseAfterSourceEditing, I agree > > that a > > > class that does nothing is a bit strange. But, what is the > > > alternative? > > > How would the sole exception handler know what to do with a > > general > > > Notification? I think the handler looks quite reasonable right > > now. > > > And > > > the pollution of the global space might be tolerable if the > > > alternative > > > is more convoluted code... > > > > > > > Making code easy to understand is very valuable. Simple things > > should be simple to > > accomplish, but achieving this in an API may not always be > > easy. > > > > This weekend I spent lots of "quality time" with the debugger, > > trying to figure out why I could > > not get a new window with a PluggableListMorph to work like > > another one which had exactly > > the behavior I wanted. The bug was that a method referred to by > > the #indexSetter: keyword > > needed to send the #selectedItem: message, which is not > > mentioned by keyword. Not sure > > what the answer is for that one but I'm working on notes to try > > to avoid that stupid mistake in > > the future. :) > > > > I'm just saying we should do anything we can to enhance clarity > > as well as simplify. > > > > - Dan > > > > > > Since you are using the right keywords, maybe it's time to view it > > again > > Simple made easy > > http://www.infoq.com/presentations/Simple-Made-Easy > > > > _______________________________________________ > > Cuis mailing list > > [hidden email] > > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On 2 Jul 2015 at 22:03, Phil (list) wrote:
> You're probably trying one of the download links. You can stream > the > video as long as JavaScript is enabled. If you can't temporarily > do > this in IE, I'd highly recommend keeping Firefox+NoScript around as > it > lets you temporarily enable JavaScript & cookies for this type of > scenario. > [...] Thanks, Phil. That's better. - Dan _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |