This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Syntatic sugar and identifier permissivity


Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> > Others have addressed why that paper in no way calls for what you are
> > seeking to implement
> 
> When?

When you originally posted your thesis.

> Ah, you haven't red it.  We're not talking about final() classes
> (that's what the above quote is about) we are talking about external
> overrides.

Actually no, my comment was not regarding the "Required Methods"
section, but the "Non Overridable Methods" section.

The quote below is from the "Redefining Reserved Words" section.  I'll
re-iterate my disagreement to directly address that quote.

Kiczales is talking about the design of a specification, not the
general behavior of an OO system like GOOPS.  If we attempt to take
this as a guideline for GOOPS and module interaction we will run into
the following problems:

1. No way to distinguish between user and original developer without a
   concept of "freezing".[1] IOW, how would you know if I was a user
   of the application who steps into a module's REPL in order to
   define on of these restricted methods?  If you flat out refuse to
   allow this redefinition, or specialization then how do I as a
   developer of the framework take advantage of the dynamic nature of
   GOOPS during the development cycle?
  
2. Need to distinguish what type of method combination the person was
   defining.  The ability to define methods with a different
   method-combination on these library methods which specialized on
   library classes is not something that should be lightly thrown
   away.  It facilitated debuging, logging, or other additions to the
   library which do not directly collide with it's behavior.
   Enforcing this distinction between method-combination in the module
   system would really suck.  Perhaps allowing an explicit sealing, or
   freezing of a library is a remedy.

[1] Freezing a class hierachy is not neccesarilly bad, but it's not
    something GOOPS presently does to my knowledge.  I believe Dylan
    does this.  At freeze time a class hiearchy and generic functions
    are sealed so that they cannot be canged further.  This allows
    more optimization techniques to be applied to method dispatch for
    isntance.

-- 
Craig Brozefsky                      <craig@red-bean.com>
Free Scheme/Lisp Software  http://www.red-bean.com/~craig
"Hiding like thieves in the night from life, illusions of 
oasis making you look twice.   -- Mos Def and Talib Kweli

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]