The original app is in Python with GTK as the interface. It maintains
a list of accounts and their starting balances. Transactions are saved
in a list in an object called the TransactionManager (TM).
At reconciliation time, each account queries the TM for transactions
referring to said account. The amount is extracted from the
transaction, and added to (or subtracted from) the balance. Simple.
First, in Python, when each account object is created, it receives a
reference to the TransactionManager. In Lisp, should this just be a
global variable that each account object calls when needed, or should
it be stored in a slot within the account object? What precedent would
there be for this kind of decision?
Second, what can I look for that would be an indication of too much
like Python or C, where I should try to be more Lisp-ish, such as using
macros, closures, etc?
jonathon wrote:
> The original app is in Python with GTK as the interface. It maintains
> a list of accounts and their starting balances. Transactions are saved
> in a list in an object called the TransactionManager (TM).
>
> At reconciliation time, each account queries the TM for transactions
> referring to said account. The amount is extracted from the
> transaction, and added to (or subtracted from) the balance. Simple.
>
> First, in Python, when each account object is created, it receives a
> reference to the TransactionManager. In Lisp, should this just be a
> global variable that each account object calls when needed, or should
> it be stored in a slot within the account object? What precedent would
> there be for this kind of decision?
I am not sure why the object has to know the TM. The code posting
transactions should know that. Sounds like you are trying to make
account objects self-sufficient for some reason. Anyway, I would have a
slot for TM in the Account class only if I planned to have several TMs,
to have Account instances accept transactions from only one TM, and if
my logic was going to be regularly posting to multiple accounts managed
by different TMs. ie, Hard to imagine.
But this is all OO design, not Lisp vs. Python.
>
> Second, what can I look for that would be an indication of too much
> like Python or C, where I should try to be more Lisp-ish, such as using
> macros, closures, etc?
>
You should consider writing a macro if you find yourself writing
repeated patterns of code (boilerplate) which cannot be functions
because they wrap variable chunks of code. Note that a closure
containing the variable code could be passed to a function instead of
using a macro, so a macro just looks a little cleaner.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
"jonathon" <···········@bigfoot.com> writes:
> The original app is in Python with GTK as the interface. It maintains
> a list of accounts and their starting balances. Transactions are saved
> in a list in an object called the TransactionManager (TM).
>
> At reconciliation time, each account queries the TM for transactions
> referring to said account. The amount is extracted from the
> transaction, and added to (or subtracted from) the balance. Simple.
IMO, in OO applications, the high level structure (the entreprise
objects) won't depend on the implementation language.
Some mechanisms might be implemented differently and more elegantly in
lisp than in other languages, some low level classes might disappear
in favor of lisp constructs, but the application structure will stay
the same (unless there was an analysis problem, in which case of
course you'd correct it while reimplementing the application in lisp).
> First, in Python, when each account object is created, it receives a
> reference to the TransactionManager. In Lisp, should this just be a
> global variable that each account object calls when needed, or should
> it be stored in a slot within the account object? What precedent would
> there be for this kind of decision?
The dataflow decisions, such as whether to pass an object used by
other objects as a global, an attribute or a message argument doesn't
depend on the implementation language, but rather on the "variability"
of this object:
- if the object is the same for the whole application, a global would do.
- if the object stays the same for a subset of the other objects (and
different subsets have a stable relationship with a different
object), then associating it thru attributes would do.
- if the object is someone else everytime the message is sent, passing
it as argument would be better.
> Second, what can I look for that would be an indication of too much
> like Python or C, where I should try to be more Lisp-ish, such as using
> macros, closures, etc?
You could take the design of the application (the UML analysis
diagrams!), an re-design and re-implement the application from scratch
in lisp. But since it might be slower than first translating Python
or C code directly to Lisp, you might prefer to do direct translation
first. When I tried to translate a library of 30 modules (abstract
data types) to lisp, it resulted that only two of them contained
abstractions not found already in lisp in one form or another. So
even if you try a direct translation, you might find a quite
measurable code reduction if you don't try to reimplement (low-level)
stuff that's already in the language.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.