More Multiple Classes per File (was Pretty Format...)

In article <52u355F1qbe5qU1@xxxxxxxxxxxxx>,
anno4000@xxxxxxxxxxxxxxxxxxxxxx wrote:

Put a bare block around each class definition, so you isolate lexicals
and can re-use variable names.

Ah, that's the kind of sweetener that I really appreciate. I avoid
globals like the plague but the block makes the whole multiple-class
approach more palatable. Thank you.


In article <x7d54l7jhe.fsf@xxxxxxxxxxxxxxxx>,
Uri Guttman <uri@xxxxxxxxxxxxxxx> wrote:

you need to understand how these names and calls relate to each
other and not guess and thrash about.

Well, guessing and thrashing is preferred approach for some but I agree
with you that it's good to know what's *really* happening. I will go
over your explanation several times and construct a number of dummy
setups to exercise the limits of these paradigms.

I think key to all of this is that packages that contain subs intended
to be called as functions need to handled a bit differently from
packages that implement classes, whose subs are methods. When I go in, I
go in with both feet, so my current solution is pure OO. I will be
exporting no symbols with EXPORTER.


In article <x7hctx7ksy.fsf@xxxxxxxxxxxxxxxx>,
Uri Guttman <uri@xxxxxxxxxxxxxxx> wrote:

you used a for loop with the implied use of $_ as the loop variable. it
is better to use a named lexical variable...

Well, I won't argue the point. But for now, I'm learning, and it's
better for me to exercise these default variables heavily, so I can
comprehend code that uses them implicitly. Okay?

you don't have to tell us your background regarding declarations. most
of the regulars here know multiple langs and know all about this area.

Better than I, no doubt. That was a "where I'm coming from" snippet.
Maybe it says something about "where I'm going" -- maybe not. Sorry if
you found it digressive. Let's just say I've turned my back firmly on
toggling in commands via front-panel switches. I'm going for maximum
abstraction and extensibility.

They say a caller should not know anything about what's inside an
object; I'm going one better and trying to write methods that don't
assume much about the innards, either. The rubber has to meet the road
sometime, of course.

it is BAD coding to use symrefs if there is a better
way to do it. that is why use strict disallows them.

I couldn't agree more. I don't know how to reject this approach more
explicitly. I did it, I'm glad I did it, I'm glad it worked. I came here
to figure out a better way to do it and, with your help, I did. Thank
you.

Xiong
--
Xiong Changnian
xiong102ATxuefangDOTcom

--
Posted via a free Usenet account from http://www.teranews.com

.

Relevant Pages

  • Re: Understanding CLOS Encapsulation
    ... exporting a class name only exports the symbol. ... accessor functions. ... class may have slots from different packages. ... it is not clear which one you would want to simply refer to as SLOT-X ...
    (comp.lang.lisp)
  • Re: Image versus package savers?
    ... exporting then backing up your packages frequently, ... Things that I consider risky include: newly changed external interfacing; failure of an MVP triad to open correctly; note that you should never save an image if the dreaded prim g2 garbage collector walkback appears. ...
    (comp.lang.smalltalk.dolphin)
  • Re: Help with packages
    ... to use from outside the package implementation fileneeds to be ... Exporting applies only to SYMBOLs. ... symbol FOO means that both ... Packages in lisp are only there to prevent accidental namespace ...
    (comp.lang.lisp)
  • Using answers package to create student solutions manual
    ... I have the code to upload the packages answers and ... What I would like to do is add a command in the preamble so that ... whether the exercise is odd or even. ...
    (comp.text.tex)
  • Re: Read Macro Characters and Packages
    ... I don't have the impression that changing the read table occurs so often that ... My guess would be that exporting ... wondered if perhaps the import itself was considered explicit enough. ...
    (comp.lang.lisp)