[Grace-core] Collection naming

Kim Bruce kim at cs.pomona.edu
Mon Jun 30 13:54:41 PDT 2014


I must admit that I don't see a real problem with the original naming (aside from the fact that it requires the "." notation which Andrew has been arguing is unnecessary for classes!)

A couple of points:
1) Having both set and set(1,2,3) be valid calls seems like asking for trouble -- a minor typo will likely set in motion very strange effects that will be hard to decipher by the programmer.

2) If you are intent on avoiding the "." notation then emptySet and setWith(...) seem quite reasonable names.  I also don't find setFromCollection(...) too bad for creating a set from another collection.  I don't really see the point of using the other names.  Hence I don't find it troubling about not having an "exploding" argument list.  Adding it in seems intuitively as something that couldn't be done in the language, so I'm reluctant to add it to the language without stronger motivation.

3)  I think naming is important and think we should try to come up with some recommended naming scheme for classes.  Types seem to be fine as nouns starting with capital letters:  Point, Graphic, Number, Set, ...   But should our classes be aPoint, point,  or ????

Kim



On Jun 30, 2014, at 5:37 AM, James Noble <kjx at ecs.vuw.ac.nz> wrote:

>> It occurred to me that it would be more graceful to just let students write
>> 
>> 	set(2, 4, 6, 8)
> 
> I like this, and this is (close to) Scala
> (actually scala involves calling a set.apply(2,4,6,8) by magic...
> 
>> or
>> 	set()
> 
> () in Grace is a syntax error, although minigrace accepts it.
> 
>> rather than  aSet.with(2, 4, 6, 8), or aSet.empty, and that if we did that, then perhaps James would stop threatening to add some special syntax for collection literals.  So I set out to do it.
>> 
>> And that's when I realized the problem with the lack of a mechanism for "exploding" an argument list.   We can get rid of .with and .empty and replace them by direct requests on the class, but we really must have .withall.
> 
> so the issue here is passing in a collection, and making a new set with the instances of that collection.
> 
> I think this is the python?  ruby?  "splat" operator: *foo assumes foo is some kind of collection (or tuple)?
> and pastes it in to the argument list.   I can see how this works dynamically, not so sure how it can be checked statically
> (although I guess you could follow scala, which has a splat that *only* works to call varargs.
> (Scala's syntax is ":_*" (apparently repeated type ascription)   which I don't suggest for Grace.
> 
> 
>> This doesn't stop me defining a method set(...) as a synonym for aSet.with(...).  But it does stop me from getting rid of the factory methods completely.
> 
> there are probably some evil, evil, options:
> 
>      set // returns an emptyset
>      set(1,2,4) // set of 1,2,4 
> 
> being varags methods.  Note that you'd need to give a type explicitly if you wanted it  
> 
>        set<Number>(1,2,4) 
> 
> as Grace can't infer the type
> 
> set.addAll(c) - adds all collection into the empty set:  a **mutating** operation, but it could be special cased.
>  Not as efficient as sizing the set from the beginning, but hopefully not too bad.
> 
> If set was immutable, presumably you couldn't call "addAll" - but you'd have a "set +" operation or something.
> potentially set ++ c, which again could be special cased.
> 
> or for even more evilness:
>  set[1,2,3] // could overload indexing operations on the _class_ to act as a literal
>  set[] // Not permitted syntatically
>  set<Number>[1,2,3] // Dynamic types cannot be inferred
>  set.empty  // can have other methods on the _class_
>  set.withAll( collection )   //like this one too
> 
> I hate to say it, but I actually quite like this, even though it is more than a bit evil. 
> It's probably just too late at night.   But it does argue strongly against special literal syntax
> (unless that special syntax infers types or something  (yes Tim, I can say HLIST) 
> 
> 
>> I'm getting more and more unhappy with the asymmetry of variable arity methods.
> 
> well, sure, but this isn't close to the top of my list of unhappinesses.
> 
> such as: only now did I realise we use "++" in a completely different way to other C-family languages.  Oops. 739 times in minigrace. 
> 
> James
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core




More information about the Grace-core mailing list