[plt-scheme] Class methods and class fields

Yes, this scenario makes sense in principle.

No, I wouldn't use Scheme classes to do templates UNLESS the number  
of defaults is large and yet overriding a few of them at a time is  
needed. Even then, I'd consider keyword arguments with default values  
instead to do what you want to do.

And also see Neil's answer.

-- Matthias



On Apr 30, 2008, at 8:02 PM, Eddie Sullivan wrote:

> Well, here's the scenario I had in mind when I originally posed the  
> question about class variables. I've since come up with a way to  
> accomplish this without using classes at all, so this may be a moot  
> point, but here it is.
>
> My idea was an x-expression based template library, where each  
> template was enclosed in a class. The concept was based on some  
> existing text templating languages, where a template can contain  
> "blocks" that a derived template can override, and "parameters"  
> that can be set on a per-instance basis. In this case the template  
> expression would be associated with the class itself, while the  
> parameter values would be associated with an instance.
>
> I wanted a syntax where default block and parameter values could be  
> specified in-line in the template rather than as default parameters  
> to a function. And I wanted to be able to nest blocks.
>
> I should mention that if this were to be implemented using  
> protected static fields, they would be treated as read-only. I have  
> not been able to come up with a realistic use case for *mutable*  
> protected static fields, which in fact sound a little scary.
>
> A simple example of one of these templates would look something like:
>
> '(html
>  (head
>   (block: head
>    (title (param: title "Page title"))
>    (link ((rel "StyleSheet")
>    ("/static/base.css"))
>    (type "text/css"))))
>   (block: morehead)) ; ... etc
>
> -Eddie
>
> ----- Original Message ----- From: "Matthias Felleisen"  
> <matthias at ccs.neu.edu>
> To: "Eddie Sullivan" <eddieSull at hotmail.com>
> Cc: "Robby Findler" <robby at cs.uchicago.edu>; <plt- 
> scheme at list.cs.brown.edu>
> Sent: Wednesday, April 30, 2008 11:29 AM
> Subject: Re: [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
>>
>