[plt-scheme] Class methods and class fields

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
>
>