[Grace-core] Some notes on pattern matching on the wiki

[Kim Bruce]

On Jul 2, 2011, at 3:46 AM, James Noble wrote:

>> I prefer for classes and types to be different (including having different names).  I can live with myClass.toType as representing the type of the objects generated by the class (if we feel we need it), but I will generally want to give types and classes independent names, e.g. PointClass vs Point.
> 
> So this is an important issue.
> Let's think about an example.
> 
> class Cat { name' : String ->  
> const name : String := name 
> method purr {print "Purr"} 
> method new {print "Meow"}
> } 
> 
> var c : Cat 
> 
> c := Cat.new("Macavity")
> 
> In, say, Java, you can do all this with just the name "Cat"
> 
> 
> Do we want to ensure all first or second week programmers have to type:
> 
> var c : CatType
> c := CatFactory.new("Macavity")
??? Where did CatFactory come from?
> 
> or alternatively
> 
> var c : Cat.type
> c := Cat.factory.new("Macavity") 
???? why not just Cat.new(...)?

> 
> 
> are we really sure? 

I'd also make them specify what CatType is:

type CatType {
      name: String
      purr: Void
}

With your definition of Cat (though I'd likely call it CatClass, leaving the shorter name for the type, which would be used more often):
var c: CatType
c:= CatClass.new("Kitty")

Keep in mind that C++ programmers are already forced to specify the signature of the class in a ".h" file before defining the implementation in a ".cc" file.  I'd teach students to write the type first and then copy and paste the spec to write the class.

As you teach the language, you would first provide students with start-up files that contain the definitions of relevant types and classes, and they would use these to do things.  Then after a week or two, they start defining types and classes themselves.


Kim