Beautiful Code [68]
We can use this fact to create a simple method syntax that implicitly binds the name this to the first (object) argument:
(define-syntax method
(lambda (x)
(syntax-case x ()
[(k (x ...) e1 e2 ...)
(with-syntax ([this (datum->syntax #'k 'this)])
#'(lambda (this x ...) e1 e2 ...))])))
By using the keyword k, extracted from the input, as the template variable, the variable this is treated as if it were present in the method form, so that:
(method (a) (f this a))
is treated as the equivalent of:
(lambda (this a) (f this a))
with no renaming to prevent the introduced binding from capturing the source-code reference.
The with-syntax form used in the definition of method creates local pattern-variable bindings. It is a simple macro written in terms of syntax-case:
(define-syntax with-syntax
(lambda (x)
(syntax-case x ()
[(_ ((p e0) ...) e1 e2 ...)
#'(syntax-case (list e0 ...) ()
[(p ...) (begin e1 e2 ...)])])))
The datum->syntax procedure can be used for arbitrary expressions, as illustrated by the following definition of include:
(define-syntax include
(lambda (x)
(define read-file
(lambda (fn k)
(let ([p (open-input-file fn)])
(let f ([x (read p)])
(if (eof-object? x)
(begin (close-input-port p) '())
(cons (datum->syntax k x) (f (read p))))))))
(syntax-case x ()
[(k filename)
(let ([fn (syntax->datum #'filename)])
(with-syntax ([(e ...) (read-file fn #'k)])
#'(begin e ...)))])))
The form (include "filename") has the effect of treating the forms within the named file as if they were present in the source code in place of the include form. In addition to using datum->syntax, include also uses its inverse operator, syntax->datum, to convert the filename subform into a string it can pass to open-input-file.
Labor-Saving Architecture: An Object-Oriented Framework for Networked Software > Sample Application: Logging Service
26. Labor-Saving Architecture: An Object-Oriented Framework for Networked Software
William R. Otte and Douglas C. Schmidt
Developing software for networked applications is hard, and developing reusable software for networked applications is even harder. First, there are the complexities inherent to distributed systems, such as optimally mapping application services onto hardware nodes, synchronizing service initialization, and ensuring availability while masking partial failures. These complexities can stymie even experienced software developers because they arise from fundamental challenges in the domain of network programming.
Unfortunately, developers must also master accidental complexities, such as low-level and nonportable programming interfaces and the use of function-oriented design techniques that require tedious and error-prone revisions as requirements and/or platforms evolve. These complexities arise largely from limitations with the software tools and techniques applied historically by developers of networked software.
Despite the use of object-oriented technologies in many domains, such as graphical user interfaces and productivity tools, much networked software still uses C-level operating system (OS) application programmatic interfaces (APIs), such as the Unix socket API or the Windows threading API. Many accidental complexities of networked programming stem from the use of these C-level OS APIs, which are not type-safe, often not reentrant, and not portable across OS platforms. The C APIs were also designed before the wide-spread adoption of modern design methods and technologies, so they encourage developers to decompose their problems functionally in terms of processing steps in a top-down design, instead of using OO design and programming techniques. Experience over the past several decades has shown that functional decomposition of nontrivial software complicates maintenance and evolution