[plt-scheme] Class methods and class fields

You have pretty much characterized the positive side of the game. The  
only thing we are missing is the following:

-- class C lives in module M and comes with a *protected static field*. 
    That is, only instances and subclasses have access to this field.

-- C and M comes as a part of an immutable package 

-- you need to design a class D in some module K and D needs to  
extend C. 

In our world, we must export the quasi-static variable from the  
module and thus make it visible to the whole world. It becomes quasi- 
global.

If we had static class variables (and we do have a generalization of  
protected) we could ensure that only C and D see this static field.

We can approximate the ideal view with programming protocols (lexical  
scope plus accessor methods), but they are just that.

So yes, there is a weakness in our system. If you come up with a  
realistic scenario for the above, we should reconsider our class design.

-- Matthias




On Apr 29, 2008, at 11:09 AM, Eddie Sullivan wrote:

> I think I see what you're saying: that module variables can  
> accomplish what class variables would be used for in other  
> languages, by putting the class(es) in its/their own module, or  
> even replacing each class with an equivalent module. To take it  
> further, a sort-of inheritance can be accomplished by re-providing  
> items from a "parent" module (or is that taking the analogy too far?).
>
> I guess the mental barrier is seeing modules as more than just a  
> way to organize source or object code (sort of like C include-files  
> or .NET assemblies), but as an intrinsic part of the language at  
> the same level as classes and structures.  That and overcoming the  
> C-based aversion to what seem like global variables.
>
> Thanks again, and let me know if I've misunderstood you.
> -Eddie
>
> ----- Original Message ----- From: "Robby Findler"  
> <robby at cs.uchicago.edu>
> To: "Eddie Sullivan" <eddieSull at hotmail.com>
> Cc: <plt-scheme at list.cs.brown.edu>
> Sent: Tuesday, April 29, 2008 9:31 AM
> Subject: Re: [plt-scheme] Class methods and class fields
>
>
>> I think that inheritance is mismatched to what you want and that kind
>> of thing only comes about because languages like you mentioned  
>> earlier
>> don't have anything that isn't attached to a class somehow.
>>
>> For the examples you've described, you really just want lexical scope
>> (plus a module system), IMO. Even for the code you write below, it
>> seems to me that you just want to put my-class and my-derived-class
>> into one module and have db-connection at the top-level of that
>> module.
>>
>> Robby
>>
>> On Tue, Apr 29, 2008 at 8:29 AM, Eddie Sullivan  
>> <eddieSull at hotmail.com> wrote:
>>> That gives some of the functionality, but doesn't specifically  
>>> associate the
>>> variable with the class, and doesn't allow for inheritance the  
>>> way structure
>>> type properties do. To add to your example, I can envision  
>>> something like:
>>>
>>>
>>>  (define my-class%
>>>   (class object%
>>>    ;; Just initialized once ever:
>>>    (static-field [db-connection (init-db)])
>>>
>>>    (define/public (talk-to-db stuff) ... db-connection ...)
>>>    (super-new)))
>>>
>>>  (define my-derived-class%
>>>   (class my-class%
>>>    ;; Provides access to superclass's static field:
>>>    (inherit-static-field db-connection)
>>>    (define/public (more-db-talking stuff) ... db-connection ...)
>>>    (super-new)))
>>>
>>>  (let ([dbc (get-static-field db-connection my-derived-class%)])
>>>   ... dbc ...)
>>>
>>>  ----- Original Message ----- From: "Robby Findler"  
>>> <robby at cs.uchicago.edu>
>>>  To: "Eddie Sullivan" <eddieSull at hotmail.com>
>>>  Cc: <plt-scheme at list.cs.brown.edu>
>>>  Sent: Tuesday, April 29, 2008 8:43 AM
>>>  Subject: Re: [plt-scheme] Class methods and class fields
>>>
>>>
>>>
>>>
>>>
>>> > The PLT Scheme class system is embedded in an ordinary functional
>>> > language, so you can just define functions or database connections
>>> > outside the class an refer to those variables lexically, eg:
>>> >
>>> > (define db-connection (init-db))
>>> > (define my-class%
>>> >  (class object%
>>> >   (define/public (talk-to-db stuff) ... db-connection ...)
>>> >   (super-new)))
>>> >
>>> > Robby
>>> >
>>> > On Tue, Apr 29, 2008 at 7:38 AM, Eddie Sullivan  
>>> <eddieSull at hotmail.com>
>>> wrote:
>>> >
>>> > > Hi.
>>> > >  I'm another long-time programmer trying out scheme. I have  
>>> been > > working
>>> > > with PLT's scheme/class module because I am used to
>>> > >  the object oriented way of thinking about programming.
>>> > >
>>> > >  In every other language I have used that has classes (Python  
>>> and the
>>> C++
>>> > >  family, also [incr tcl] but my memory of that is vague),  
>>> there is > > the
>>> > >  concept of "class variables", that is, variables that are  
>>> associated
>>> with
>>> > >  the class itself rather than with any particular instance,  
>>> and the
>>> similar
>>> > >  concept of "class methods." (They're also often called  
>>> "static", but
>>> that
>>> > >  term can be confusing, IMO.)
>>> > >
>>> > >  It's easy to imagine scenarios where these concepts would be  
>>> very
>>> useful,
>>> > > such as a
>>> > >  shared resource like a database connection, or simply a  
>>> usage > > counter.
>>> > >
>>> > >  Perhaps I'm misreading the documentation, but I can't find  
>>> anything
>>> like
>>> > > that in scheme/class. Structures have "structure type  
>>> properties", so
>>> the
>>> > > idea must be acknowledged to be useful in theory.
>>> > >
>>> > >  Is it there and I'm missing it? If not, is there a simple  
>>> way to
>>> implement
>>> > > this functionality that I haven't figured out? Or is there a
>>> philosophical
>>> > > reason why this was considered a bad idea?
>>> > >
>>> > >  Thanks!
>>> > >  -Eddie Sullivan
>>> > >
>>> > >
>>> > >  _________________________________________________
>>> > >  For list-related administrative tasks:
>>> > >  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>> > >
>>> > >
>>> >
>>> >
>>>
>>>
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme