Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
* Re: Class variables in O'Caml??? + questions
@ 1996-05-13 19:04 David Gurr
  0 siblings, 0 replies; 4+ messages in thread
From: David Gurr @ 1996-05-13 19:04 UTC (permalink / raw)
  To: caml-list



Jerome Vouillon <vouillon@clipper.ens.fr>:

> On Fri, 10 May 1996, Thorsten Ohl wrote:
> > Sure, it us possible to do it.  But, IMHO, class variables should be
> > declared in the class and be opaque.  
> > ...
> > I'm just curious if (and why) this syntactic sugar has been left out
> > intentionally.
> 
> It has not been left out intentionally. Many object-oriented languages 
> (C++, Objective C and Modula 3, for instance) do not have class variables, 

C++ does have class variables but since everything is renamed in C++
they are called static member variables or static data members or ... .

> ... they can be easily simulated using references as you noticed.

Why not make class variables exactly that,  slots of the class object?

-D





^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Class variables in O'Caml??? + questions
  1996-05-10 15:13   ` Thorsten Ohl
@ 1996-05-13 16:36     ` Jerome Vouillon
  0 siblings, 0 replies; 4+ messages in thread
From: Jerome Vouillon @ 1996-05-13 16:36 UTC (permalink / raw)
  To: Thorsten Ohl; +Cc: caml-list


On Fri, 10 May 1996, Thorsten Ohl wrote:
> 
> >>>>> "Christian" == Christian Boos <boos@gr6.u-strasbg.fr> writes:
> 
> Christian> IMO, the use of references is not so unnatural. Together
> Christian> with structs, it provides a clean way to encapsulate global
> Christian> state and actions for classes.
> 
> Sure, it us possible to do it.  But, IMHO, class variables should be
> declared in the class and be opaque.  If you put several classes in a
> module, the use of module wide references makes much less sense.
> Another hack is to define a sub-module for each class, but that's not
> nice either ...
> 
> I'm just curious if (and why) this syntactic sugar has been left out
> intentionally.

It has not been left out intentionally. Many object-oriented languages 
(C++, Objective C and Modula 3, for instance) do not have class variables, 
so I did not even thought of adding them.
But I do not plan to implement class variables. I don't want to add too 
many features, and I don't think they are an important one: in my 
opinion, they are not commonly used, and they can be easily simulated 
using references as you noticed.

  Jerome Vouillon





^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Class variables in O'Caml??? + questions
  1996-05-10 12:57 ` Class variables in O'Caml??? + questions Christian Boos
@ 1996-05-10 15:13   ` Thorsten Ohl
  1996-05-13 16:36     ` Jerome Vouillon
  0 siblings, 1 reply; 4+ messages in thread
From: Thorsten Ohl @ 1996-05-10 15:13 UTC (permalink / raw)
  To: caml-list


>>>>> "Christian" == Christian Boos <boos@gr6.u-strasbg.fr> writes:

Christian> IMO, the use of references is not so unnatural. Together
Christian> with structs, it provides a clean way to encapsulate global
Christian> state and actions for classes.

Sure, it us possible to do it.  But, IMHO, class variables should be
declared in the class and be opaque.  If you put several classes in a
module, the use of module wide references makes much less sense.
Another hack is to define a sub-module for each class, but that's not
nice either ...

I'm just curious if (and why) this syntactic sugar has been left out
intentionally.
-- 
Thorsten Ohl, Physics Department, TH Darmstadt --- PGP: AF 38 FF CE 03 8A 2E A7
http://crunch.ikp.physik.th-darmstadt.de/~ohl/ -------- 8F 2A C1 86 8C 06 32 6B





^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Class variables in O'Caml??? + questions
  1996-05-10 10:46 Class variables in O'Caml??? Thorsten Ohl
@ 1996-05-10 12:57 ` Christian Boos
  1996-05-10 15:13   ` Thorsten Ohl
  0 siblings, 1 reply; 4+ messages in thread
From: Christian Boos @ 1996-05-10 12:57 UTC (permalink / raw)
  To: caml-list; +Cc: Thorsten Ohl

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3171 bytes --]



Hello, 

Thorsten Ohl writes:
 > (...)
 > 
 > The typical application is a class of non-uniform random number
 > generators, where the distribution to be generated would be an
 > instance variable, while the state of the underlying uniform
 > generator should be a class variable.  This way, differrent instances
 > will generate different distributions, but draw from the _same_ source
 > of random numbers.
 > 
 > It is possible to emulate this with references, of course.  But it
 > would be somewhat unnatural ...
 > 

I played with O'Caml too ...

IMO, the use of references is not so unnatural. Together with structs,
it provides  a clean way  to encapsulate global  state and actions for
classes.

I would illustrate this on a small example, a simple unique identifier
generator:

 #module Identifier :
 #  sig
 #    class identifier (unit) =
 #      val id : int
 #      val mutable nb_queries : int
 #      method id : int
 #      method nb : int
 #    end
 #  end =
 #  struct
 #    let state = ref 0
 #
 #    class identifier () = 
 #       val mutable nb_queries = 0
 #       val id = let s = !state in incr state; s
 #
 #       method id = nb_queries <- succ nb_queries; id
 #       method nb = nb_queries
 #     end
 # end 
 #;;
 module Identifier :
   sig
     class identifier (unit) =
       val id : int
       val mutable nb_queries : int
       method id : int
       method nb : int
   end
 end
 #


----

By the way, I've  perhaps discovered a bug, or  at least an unpleasant
feature:

It seems   that you  can't  hide the  internal    val's of your  class
definition, when exporting its signature.  What I expected is that the
previous example could be written:

 #module Identifier :
 #  sig
 #    class identifier (unit) =
 #      method id : int
 #      method nb : int
 #    end
 #  end = ...

thereby hiding completely  the way an identifier  is implemented.  But
the compiler isn't happy with that:

 Class types do not match:
   class identifier (unit) =
     val id : int
     val mutable nb_queries : int
     method id : int
     method nb : int
 end
 is not included in
 class identifier (unit) =
   method id : int
   method nb : int
 end


This is strange, since  in other situations,  type checking on classes
doesn't care of 'val's, as seen in the following example:

 #class a () = val a = 0 method get = a end;;
 class a (unit) =
   val a : int
   method get : int      (* val a : ... *)
 end
 #class b () = method get = 0 end;;
 class b (unit) =
   method get : int      (* no val *)
 end
 #new a () = new b ();;  (* but same type !! *)
 - : bool = false


But that's a minor point. 

Another  one  is that the  very   interesting contribution of  Jacques
Garrigue   and  Jun P.  Furuse  (labeled  and   optional  arguments to
functions) hasn't  merged with the   mainstream. Will this happen  one
day, at least optionaly (sort of -withlabels option) ?

Anyway, Caml is still going better and better ... That's great !


-----------------------------------------------------------------------------
- Christian Boos, 
- Etudiant en Thèse d'Informatique
- http://dpt-info.u-strasbg.fr/~boos/                                 





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~1996-05-14  8:06 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-05-13 19:04 Class variables in O'Caml??? + questions David Gurr
  -- strict thread matches above, loose matches on Subject: below --
1996-05-10 10:46 Class variables in O'Caml??? Thorsten Ohl
1996-05-10 12:57 ` Class variables in O'Caml??? + questions Christian Boos
1996-05-10 15:13   ` Thorsten Ohl
1996-05-13 16:36     ` Jerome Vouillon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox