[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Scheme/Vim Interface [was: A message from the Scheme Underground]



> >1.  Would it make more sense for Buffers and windows to be 
> >full-fledged MzScheme classes in all their object-oriented glory?
> 
> FWIW, I think that they should be classes if either of these two 
> conditions hold:
> 
>    1, there are many operations on each different kind of 
> data and you want to organize them
>    2. it is possible to instantiate classes derived from the built-in 
> base classes and have a way to tell vim to instantiate those derived 
> classes.
> 
> Case 2. is especially useful when there are observer methods (these 
> are the on-* methods in the mred toolbox).
> 

I'm not either of these hold very well for the Vim interface.

1.  While there are lots of methods related to buffers, they aren't
all that unique.  I suppose it might be nice to say:

(define first-buff (make-object vim-buff% (vim-get-curr-buff)))

And the do things like:

(send first-buff get-line-count)  

To get the current line count.

But I'm not sure that's much easier/helpful than:

(get-buff-line-count first-buff)

I'm open to comments...

2.  I'm not sure that subclassing is really warranted for the
Vim buffers and windows.  They are what they are.  I suppose one
could wrap additional functionality as a "Vim buffer that only
accepts upper-case letters" or similar.  Ingenuity and invention
run rampant in our circles, so I hesitate to ever make something
impossible to do.

In fact, I can imagine people wanting to creat Vim buffer or
window classes as views into the buffer data that provide
special functionality.  Subclassing would be quite helpful in
this case.

I'm starting to think it might be a good idea -- it would be
a good way for me to learn the MzScheme class system better.
Can someone with experience in MzScheme's class system comment
on whether this seems like a good idea?

Thanks,

-Brent