 Patterns for Scripted Applications and scripting
started 10/22/2001; 11:24:17 AM - last post 10/24/2001; 9:01:06 AM
|
|
Adewale Oshineye - Patterns for Scripted Applications and scripting 
10/22/2001; 11:24:17 AM (reads: 442, responses: 4)
|
|
|
I dabble with an open-source text editor called Moleskine [http://www.moleskine.f2s.com] and one of the things that's being considered for the next version is the addition of scripting. Whilst
looking for best-practices for the implementation I found this site.
It contains various patterns that "attempt to capture and describe the design decisions that lead to a successful use of scripts and scripting." The idea is that design patterns must be re-evaluated when they are being used in highly dynamic languages like Python/Perl as opposed to more static languages like C++ and Java.
On the other hand a lot of the initial work with patterns was done with Smalltalk: a language that is very dynamic and supports very sophisticated meta-programming techniques. How far does the dynamic nature of a language affect the essence of a pattern?
The Python Cookbook has at least one example where a fairly fundamental design pattern has been radically re-designed because of linguistic features[http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66531].
Also see Design Patterns in Python[http://www.python.org/workshops/1997-10/proceedings/savikko.html] for an earlier attempt to convert GangOfFour patterns into idiomatic Python.
So basically I'm asking how far should we twist widely-known design patterns to fit languages? And I'm also curious if other language communities have made attempts to either mine their codebases for patterns or attempted to systematically convert GangOfFour patterns into idiomatic code?
|
|
Chris Rathman - Re: Patterns for Scripted Applications and scripting
10/22/2001; 1:36:27 PM (reads: 486, responses: 0)
|
|
|
Two of the GOF patterns seem to be the most common targets for solutions.
First is the iterator pattern. Many feel like the pattern is a must-have for any language that considers itself modern. Any language from CLU, Sather, and Icon have exploited this pattern to good effect. The latest version of Python supports iterators as well.
Second is the visitor pattern. This is by far the most complex pattern in the GOF repository. Languages such as CLOS, Dylan and Cecil feel it is solved via multimethods. AspectJ, OTOH, feels that visitor delegation should be a built in language feature which is on par with inheritance in terms of OO modeling.
|
|
Noel Welsh - Re: Patterns for Scripted Applications and scripting
10/23/2001; 3:52:23 AM (reads: 496, responses: 0)
|
|
|
I believe design patterns were originally presented as solutions to common problems for which the language provides no good default solution. So, for example, inheritance would be a design pattern in C. If you take this view then design patterns must change as languages change. As Chris mentions above, the Visitor pattern doesn't exist in any language with multiple-dispatch, as the language provides a default solution.
Peter Norvig has a good presentation on "Design Patterns in Dynamic Programming" at http://www.norvig.com/design-patterns/
Other languages and language styles have design patterns though they may not be presented as such. I would argue that much of the "Functional Pearls" and related literature are design patterns for functional languages.
|
|
Ehud Lamm - Re: Patterns for Scripted Applications and scripting
10/23/2001; 1:59:36 PM (reads: 470, responses: 0)
|
|
|
The idea that patterns in some sense compensate for language shortcomings is quite well established. We discussed this in the past. Personally, I like to cite the paper coatuhored by Yossi Gil (the title is something like Mining patterns for language features)
However, we must ask ourselves where should we draw the line. Some things will always remain part of programming, and of the programming language.
In fact, I think this related to our recent dicussions re Scheme and other languages (generators etc. etc.)
|
|
Chris Rathman - Re: Patterns for Scripted Applications and scripting
10/24/2001; 9:01:06 AM (reads: 481, responses: 0)
|
|
|
While I'm on the subject of implementing patterns, I thought I'd also mention that the Singleton Pattern is also implemented directly in the Beta Programming Language. Singletons are a fairly simple pattern in most OOP languages, so I don't necessarily see much advantage. I suppose it was just a natural fallout. I also vaguely recall that C# also has a direct singleton pattern. In C++, Structures can be used as Singleton patterns if you really need 'em.
One thing I would recommend for anyone that's interested in the GOF book, is that the "Smalltalk Companion" is worth reading simultaneously with GOF. The companion book concentrates on the variations that are prevalent in ST and gives some perspective that's valuable. Although the GOF does have some ST examples, they are not as prevalent as the C++ examples.
There's also a companion book about patterns and Design by Contract that runs through the examples in Eiffel. From what I've heard, though, the book is mostly a rehash of GOF and really doesn't go into a thorough description of the role of Contracts in developing patterns. I haven't read the book, other than glimpsing through it at the local bookstore. If anyone has read the book, I'd like to hear their opinion.
|
|
|
|