Originally posted by: <a href="mailto:"></a>
> Syntactically we wanted it to be extremely concise, so we avoided a
> keyword.

You mean you chose a concise keyword. I don't think (re)using ':', which
is often used as a separator, is a good idea, though. The examples made
me feel something is missing before the ':'... I admit it may be
difficult to find a good keyword, due to the construct's dual usage of
binding and/or creating and object.

for (x : expr) {
}

x : expr {
}

:x : expr {
}

> And also the expression is optional if it can be inferred from the
> context (i.e. expected type). The default strategy is that if the
> expected type is a concrete Java type and has a default constructor that
> one is called implicitly:

So val Person p = :{} will mean val Person p = new Person()? What about
collection types casting, will that introduce an expectation, e.g. will
<Person>newArrayList(:{}) create an ArrayList<Person> with one Person
element? And casting, will (:{} as Person) evaluate to a Person?

> The language specific strategy however can be more sophisticated. For
> instance Xtend allows to have a field declared with a keyword 'instance
> factory'. In that case any operations with null arguments serve as
> factory methods. That allows for using this approach with EMF:
>
> // Xtend and EMF

.... concerning EMF, how will this relate to Xcore? Will you allow :{ ...
} out-of-the-box without a factory declaration? Will you also allow an
ordinary new call?

> instancefactory LibraryFactory f

So it looks up any method in f without arguments that returns the
desired type?

> That's it. We tried to avoid any special treatment of expressions in
> that context like flat scoping, special collection literals, etc.

Yes, in general this is desirable. Since Collections are used so much, I
still think it deserves special support, or, since you're using Google's
Collection library, operators for Iterable values, like more
operator_plus methods:

IterablesExtensions:
public static <E> Iterable<? extends E> operator_plus(Iterable<? extends
E> it, E t) {
return Iterables.concat(it, Collections.<E>singletonList(t));
}

ObjectExtensions:
public static <E> Iterable<? extends E> operator_plus(E e1, Iterable<?
extends E> it) {
return Iterables.concat(Collections.<E>singletonList(e1), it);
}

public static <E> Iterable<E> operator_plus(E e1, E e2) {
return Iterables.concat(Collections.<E>singletonList(e1),
Collections.<E>singletonList(e1));
}

> I am aware that this solutions although very general doesn't solve the
> heavy-cross-linking-case. You'll have to declare elements you want to
> refer to up front.

I think heavy cross linking is an important use case. This means it will
be difficult to use it as a serialization format, like HUTN is?

> It's going to be released in October. So there's still some time to
> discuss this and incorporate feedback

Well, I guess you can consider my own proposal a kind of 'feedback',
although I was hoping it would be used in the forward direction.

> 2) the expression will often be used in the context of object creation.
> In that case the val keyword doesn't fit.
> This becomes even more evident if you use all defaults:
>
> val Person p = val {
> name = "Halvard"
> }

But wouldn't you write this as val p = new Person() { ... } instead of
having two levels of val?

> We also considered 'let' and 'with' btw. and generally a keyword seem to
> be too noisy.

What is considered "noisy" is person dependent (I know, with a 15 year
old son who likes rap. In fact, he thinks Motorpsycho is noisy .