On Jul 15, 10:00 am, Christian Vest Hansen <[email protected]>
wrote:
> Some thoughts:
>
> * How about letting "module my.pkg" translate into a class "pkg" in
> the package "my"? I think this will expose a saner interface to
> Java-land. For instance, considering the case where a library is
> written in this language, and then used from Java.
Would this not affect the ability to create more classes within the
pkg? I assume you are suggesting that all classes declared within the
package would kind of become nested classes. Have to try this out.
Understand the issue about calling from Java. I was thinking that the
transformation will be well defined, so you call a static method from
Java as follows:
my.pkg.Statics.foo();
Your suggestion would get rid of Statics, but would mean that call
classes defined in my.pkg will be nested classes.
>
> * How about reserving the := operator for things that are truly
> mutable, and then letting constants/finals be defined with = instead
> of "const <identifier> := <expression>"?
>
Sounds good. I think Go does it this way as well.
> * Why are the methods of a class (MyLock) outside the type
> definition? If they were inside the definition, then it would clearly
> signal what scope they were operating on, and I wouldn't have to
> prefix the method names with the type name. Also, the syntax looks
> inspired from languages that have multimethods or algebraic datatypes
> - these features do not appear to be present in this language, as far
> as I have been able to discern.
>
I am following Go syntax here - although slightly amended. In go, the
methods are declared outside the type definition. Also the receivers
are explicitly named.
So for example:
type Myint int
func (s Myint) foo() {
}
Above is a method named foo() that can be invoked on type Myint.
I have modified the syntax slightly as don't see the benefit of
explicitly named receivers. So my suggested syntax is:
func Myint.foo() {
// receiver is named this
}
I find the need to put methods inside class bodies annoying sometimes
- as code keeps getting indented. Not having to put methods inside the
class body also means that you can quickly see what the data fields
are. And if all public methods are specified using interfaces then the
methods should be clear from the interfaces implemented.
I am not sure yet which approach is better.
> * On that note, having syntax for simulating algebraic datatypes
> (this is called case-classes in Scala, is it not?) sure would be nice.
>
> * How do you decide when a func-definition should produce a static
> method, or a class that implements runnable?
Actually that's a mistake. The producer and consumer functions should
be static methods in Statics class, and the Runnables should be
anonymous - and should invoke the static methods. I will fix that
example.
>
> * In the expression new map[string] int { "a": 1, "b": 2, "c": 3};
> why is the 'int' part of the type outside the [] ?
>
Following Go syntax for declarations this reads map indexed by string
returning int. So it is like saying Map<String,Integer> in Java.
> * How do I define generic types? In your MyLock example, it seems
> that [] are used to specify the interfaces that a type implements
> while in the "map" expression above the [] are used for type
> parameters.
>
Still thinking about generics. I was thinking of maybe only supporting
use of generics rather than letting generic types be defined in the
language.
Generics are quite hard (I still don't fully get the Java
implementation) and I don't fancy trying to implement these.
Regards
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
