Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #13364 > unrolled thread

diamond operator

Back to article view | Back to comp.lang.java.programmer

Contents

  diamond operator Roedy Green <see_website@mindprod.com.invalid> - 2012-04-03 18:54 -0700
    Re: diamond operator Arne Vajhøj <arne@vajhoej.dk> - 2012-04-03 22:06 -0400
    Re: diamond operator Silvio Bierman <silvio@moc.com> - 2012-04-04 13:12 +0200
      Re: diamond operator David Lamb <dalamb@cs.queensu.ca> - 2012-04-04 08:23 -0400
        Re: diamond operator Silvio Bierman <silvio@moc.com> - 2012-04-04 15:40 +0200
        Re: diamond operator Arne Vajhøj <arne@vajhoej.dk> - 2012-04-04 19:41 -0400
          Re: diamond operator David Lamb <dalamb@cs.queensu.ca> - 2012-04-05 08:03 -0400
    Re: diamond operator Jim Janney <jjanney@shell.xmission.com> - 2012-04-04 10:23 -0600
      Re: diamond operator Lew <lewbloch@gmail.com> - 2012-04-04 18:15 -0700
        Re: diamond operator David Lamb <dalamb@cs.queensu.ca> - 2012-04-05 15:44 -0400
          Re: diamond operator Jim Janney <jjanney@shell.xmission.com> - 2012-04-05 14:54 -0600
      Re: diamond operator Silvio Bierman <silvio@moc.com> - 2012-04-06 12:06 +0200
        Re: diamond operator Lew <lewbloch@gmail.com> - 2012-04-06 10:53 -0700
          Re: diamond operator Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-04-06 21:35 -0500
            Re: diamond operator Arne Vajhøj <arne@vajhoej.dk> - 2012-05-05 20:07 -0400
        Re: diamond operator Jim Janney <jjanney@shell.xmission.com> - 2012-04-06 19:56 -0600
          Re: diamond operator Jim Janney <jjanney@shell.xmission.com> - 2012-04-06 20:02 -0600
    Re: diamond operator Arivald <NOSPAMarivald@interia.pl> - 2012-04-05 10:11 +0200
      Re: diamond operator Lew <lewbloch@gmail.com> - 2012-04-05 11:34 -0700
        Re: diamond operator Arivald <NOSPAMarivald@interia.pl> - 2012-04-05 22:02 +0200
          Re: diamond operator ObeseeExpen <ObeseeExpen.5ibto0@no-mx.forums.yourdomain.com.au> - 2012-09-03 12:39 -0400
        Re: diamond operator Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-04-05 18:18 -0500
        Re: diamond operator Arne Vajhøj <arne@vajhoej.dk> - 2012-04-05 19:38 -0400
        Re: diamond operator Silvio Bierman <silvio@moc.com> - 2012-04-06 17:07 +0200
          Re: diamond operator Thufir <hawat.thufir@gmail.com> - 2012-04-06 08:51 -0700
            Re: diamond operator Silvio Bierman <silvio@moc.com> - 2012-04-08 15:12 +0200
      Re: diamond operator Arne Vajhøj <arne@vajhoej.dk> - 2012-04-05 19:41 -0400

Page 2 of 2 — ← Prev page 1 [2]

#18519

okbcaflvq 
'コーチ(Coach),コーチ アウトレット,コーチ
店舗-coachfashionjp.com' (http://www.coachfashionjp.com/)  
コーチ
'こちらでは新作グッチ(gucci)のバッグと財布をセールしております！'
(http://www.guccifashionshow.com/)   グッチ
新作
'アディダス[adidas]のスポーツウェアとジャージ、アディダスオリジナルス（adidas
originals）スニーカーの専営ショップ!'
(http://www.adidasjpshow.com/)  
アディダス
ジャージ
'当店はグッチ(gucci)専門店です|人気のグッチ(gucci)
バッグとグッチ 財布とグッチ
アウトレットが販売します!'
(http://www.guccibagsoutletjapan.com/)   グッチ
メンズ
'gucci' (http://www.guccihotsalejp.com/)   グッチ
バッグ

wxcaftehx 
<a href=http://www.cheapcoachbagsjapan.com/>&#12467;&#12540;&#12481;
&#36001;&#24067;</a>
<a href=http://www.coachvipmall.com/>&#12467;&#12540;&#12481;
&#12513;&#12531;&#12474;</a>
<a href=http://www.coachnewfashion.com/>&#12467;&#12540;&#12481;
coach</a>
<a href=http://www.guccibagsshow.com/>&#12464;&#12483;&#12481;
&#36001;&#24067;</a>
<a href=http://www.coachbestbag.com/>coach &#36001;&#24067;</a>

qtzeybned 
'gucci &#36001;&#24067;' (http://www.guccibagsshow.com/)
'&#12464;&#12483;&#12481;' (http://www.topguccionsale.com/)
'&#12467;&#12540;&#12481; &#36001;&#24067;'
(http://www.coachhandbagsmany.com/)
'&#12467;&#12540;&#12481; &#12496;&#12483;&#12464;'
(http://www.cheapcoachbagsjapan.com/)
'&#12486;&#12451;&#12501;&#12449;&#12491;&#12540;'
(http://www.tiffanybuyjp.com/)


-- 
ObeseeExpen
------------------------------------------------------------------------
ObeseeExpen's Profile: http://forums.yourdomain.com.au/member.php?userid=960
View this thread: http://forums.yourdomain.com.au/showthread.php?t=4121

[toc] | [prev] | [next] | [standalone]

#13426

On 4/5/2012 1:34 PM, Lew wrote:
> Arivald wrote:
>> It will be better to provide "auto" type detector, like in C++. For
>> example, instead of: Map<Integer, List<String>>  map = new
>> HashMap<Integer, List<String>>(); use: auto map = new
>> HashMap<Integer, List<String>>();
>>
>> ...and "map" variable will be resolved at compile time to
>> HashMap<Integer, List<String>>.
>>
>> This allow very handy construct, like:
>>
>> auto data = SomeService.getProviders();
>
> If 'auto' is a type, it should begin with an upper-case letter. If
> it's not, you should explain what you intend.

The `auto' comes from C++11, where the type of the variable is defined 
to be the type of the static value being assigned to it [1]. It is a lot 
more powerful in C++, where the language can define some obscene, opaque 
hidden types whose exact signatures are left unspecified by the 
specification. The largest set of these are the STL iterators, where 
iterators look like `std::map<A, B>::iterator', but, when expanded, tend 
to be a class with five or six template parameters and a name with way 
too many underscores to be sane. The following all refer to the same type:
std::map<A, B>::iterator
std::_Rb_tree<A, std::pair<A, B>, std::_Select1st<std::pair<A, B> >, 
std::less<A>, std::allocator<std::pair<const A, B> > >::iterator
std::_Rb_tree_iterator<std::pair<A, B> >

Given that A and B can be very long types themselves, it quickly becomes 
obscene just to write a simple for each loop, although C++11 also 
introduces a version of for-each loops that ameliorate this.

The other reason for auto is lambda expressions: the type of a lambda 
expression is "a unique, unnamed class that has the following 
properties", much as the actual type of an anonymous inner class in Java 
is a unique, unnamed class which is only guaranteed to inherit from some 
method.

> This idea is incompatible with the current direction of type
> inference, which is in the other direction, and with Java's strong
> typing philosophy, and apparently the Powers That Be disagreed that
> your idea is better, as they didn't implement it.

The C++11 auto keyword is still fully strongly typed. It's meaning is 
best described is "the compiler already knows the precise type of this 
variable, and I know what I can do with this type, but I don't want to 
spend 15 minutes fighting the compiler to figure out what the right type 
actually is." In C++, because of the magic of templates and typedefs, 
you can actually spend several minutes just trying to figure out how to 
tell the compiler the proper name of a type.

In short, auto is not a matter of dynamic versus static typing, it's a 
matter of implicit versus explicit typing. C++ has a fairly complex type 
system that has lots of edge cases which happen surprisingly often, 
while Java's type system is cleaner, even if you throw in generics. 
Given also that I suspect templates are much more abused than Java's 
generics, I don't think the auto is as useful in Java as it is in C++.

[1] If you really want to play language lawyer, it's the same type for 
the initializer expression as would be derived for template argument 
inference.

-- 
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#13427

On 4/5/2012 2:34 PM, Lew wrote:
> Arivald wrote:
>> It will be better to provide "auto" type detector, like in C++.
>> For example, instead of:
>>     Map<Integer, List<String>>  map = new HashMap<Integer, List<String>>();
>> use:
>>     auto map = new HashMap<Integer, List<String>>();
>>
>> ...and "map" variable will be resolved at compile time to
>> HashMap<Integer, List<String>>.
>>
>> This allow very handy construct, like:
>>
>>     auto data = SomeService.getProviders();
>
> If 'auto' is a type, it should begin with an upper-case letter. If it's not, you should explain what you intend.

Given that it is a C++ keyword, then ....

>> In this case type of "data" will be deducted [sic] from return type of
>> SomeService.getProviders().
>>
>> This will save lot of typing. And save refactoring time in case if
>
> It will save virtually no typing compared to current Java idioms.

It will certainly save some typing.

But saving typing is not really important.

> Your suggestion:
>> auto map = new HashMap<Integer, List<String>>();
>
> Current idiom:
>
>    Map<Integer, List<String>>  map = new HashMap<>();
>
> Not much difference in typing, certainly not enough to get your knickers in a twist over.
>
> Your suggestion:
>> auto data = SomeService.getProviders();
> which you describe as "very handy", but violates strong typing, which requires that the compiler know the type of 'data'. If the (presumably static) method you describe were to change its return type, it would break the client code that relies on knowledge of the type of 'data'.

It is completely strong typed.

The compiler just infer the type instead of the programmer typing it.

It is available in lots of languages: C++, C#, Scala etc..

> The current inference direction is that the generics of a method declaration are resolved by the invocation context, when possible:
>
>    Map<Integer, List<String>>  data = getProviders();
>
> where the declaration of the method is something like:
>
>    public Map<T, U>  getProviders();
>
> Type inference tells 'getProviders()' what types 'T' and 'U' are.
>
> Your suggestion would break those.

No.

That could still work.

But you can obviously not infer on both L and R side.

> You should understand that changes to the Java language must meet at least two criteria, irrespective of whether they even provide value (which I don't see that yours does):
>
>   - they must not break Java (which yours does), at least not too much,

It will not break Java.

C# got it in 3.0 and it did not break anything.

>   - they must provide enough value to justify making any change at all (which yours doesn't).

That is more an opinion than a fact.

Arne

[toc] | [prev] | [next] | [standalone]

#13436

On 04/05/2012 08:34 PM, Lew wrote:
>
> This idea is incompatible with the current direction of type inference, which is in the other direction, and with Java's strong typing philosophy, and apparently the Powers That Be disagreed that your idea is better, as they didn't implement it.
>

Wrong if you are speaking about type inference in general. Languages 
like Scala and Haskell do it exactly this way and for good reasons.

If you talk about type inference for Java, maybe.

> Current idiom:
>
>    Map<Integer, List<String>>  map = new HashMap<>();
>
> Not much difference in typing, certainly not enough to get your knickers in a twist over.

Typing is irrelevant. Laving out the left hand type increases 
readability by removing redundancy. In a different world your example 
could have been

auto map = new Map<Integer,List<String>>();

Any keyword as a replacement for auto would work.

>
> Your suggestion:
>> auto data = SomeService.getProviders();
> which you describe as "very handy", but violates strong typing, which requires that the compiler know the type of 'data'. If the (presumably static) method you describe were to change its return type, it would break the client code that relies on knowledge of the type of 'data'.
>

Wrong in two ways. What you describe is static typing, which is a 
specific form of strong typing.

And Arivalds example conforms to static typing. The compiler can deduce 
the type of the right hand side expression and uses that is the static 
type for the variable. Again Scala and Haskell do it the same way.


> The current inference direction is that the generics of a method declaration are resolved by the invocation context, when possible:
>
>    Map<Integer, List<String>>  data = getProviders();
>
> where the declaration of the method is something like:
>
>    public Map<T, U>  getProviders();
>
> Type inference tells 'getProviders()' what types 'T' and 'U' are.

Type inference can work in two ways. It can either use an expected type 
to resolve the type of a (sub)expression but it can also use the type of 
a (sub)expression to deduce the type of a variable or function.

What you describe is the first way using the expected type to determine 
what T and U should be. You can have it both ways without breaking 
stuff. In Scala you could have:

      val x1 : Set[Int] = new HashSet
      val x2 = new HashSet[Int]

given a generic type HashSet taking a type parameter. The first one 
brings the x1's expected type into the new expression, the second one 
uses the type of the new expression to deduce the type of x2.



>
> Your suggestion would break those.

Nope, it would not have to break any existing code.
>
> So it won't happen for those big reasons.
>
> You should understand that changes to the Java language must meet at least two criteria, irrespective of whether they even provide value (which I don't see that yours does):
>
>   - they must not break Java (which yours does), at least not too much,
>   - they must provide enough value to justify making any change at all (which yours doesn't).
>


I do not think it would be a worthwhile change to the Java language. 
Then again, the only reason why I value Java language changes is that 
they will sooner promote adoption of the JVM than create opposition.

The JVM is our strategic choice. Java is our workhorse for maintaining 
legacy code. For everything new we have moved on to other languages, 
mainly Scala. Turning Java into something akin Scala is impossible and 
unnecessary.

[toc] | [prev] | [next] | [standalone]

#13438

On Fri, 06 Apr 2012 17:07:49 +0200, Silvio Bierman wrote:

> Typing is irrelevant. Laving out the left hand type increases
> readability by removing redundancy. In a different world your example
> could have been
> 
> auto map = new Map<Integer,List<String>>();
> 
> Any keyword as a replacement for auto would work.

While I'm familiar with neither Scala nor Haskell, that seems a bad 
idea.  What happened to the idea of using a, for example, Ferrari 
interface on a Car instance?  Sure, the object is a Car, but that Ferrari 
interface is used, well, not for convenience per se, but as a reminder 
that this Car is not *just* a Car.

You're suggestion is completely contrary to that principle.  While I 
appreciate that it's easier, I don't get the point.

That being said, in Ruby you instantiate with:

foo = Bar.new

which is quite nice and simple.



-Thufir

[toc] | [prev] | [next] | [standalone]

#13451

On 04/06/2012 05:51 PM, Thufir wrote:
> On Fri, 06 Apr 2012 17:07:49 +0200, Silvio Bierman wrote:
>
>> Typing is irrelevant. Laving out the left hand type increases
>> readability by removing redundancy. In a different world your example
>> could have been
>>
>> auto map = new Map<Integer,List<String>>();
>>
>> Any keyword as a replacement for auto would work.
>
> While I'm familiar with neither Scala nor Haskell, that seems a bad
> idea.  What happened to the idea of using a, for example, Ferrari
> interface on a Car instance?  Sure, the object is a Car, but that Ferrari
> interface is used, well, not for convenience per se, but as a reminder
> that this Car is not *just* a Car.
>
> You're suggestion is completely contrary to that principle.  While I
> appreciate that it's easier, I don't get the point.
>
> That being said, in Ruby you instantiate with:
>
> foo = Bar.new
>
> which is quite nice and simple.
>
>
>
> -Thufir

I will counter this with a Scala example.

This is the minimal version:

      val map = new HashMap[Int,List[String]]

giving "map" the "Ferrari" type.

But you could also have:

      val map : Map[Int,List[String]] = new HashMap[Int,List[String]]

giving "map" the "car" type explicitly.

Ruby is a completely different animal being dynamically typed. It is 
however an example of the power of type inference that Scala and Haskell 
can approach the notational convenience of Ruby while being statically 
typed.

[toc] | [prev] | [next] | [standalone]

#13428

On 4/5/2012 4:11 AM, Arivald wrote:
> It will be better to provide "auto" type detector, like in C++.
> For example, instead of:
> Map<Integer, List<String>> map = new HashMap<Integer, List<String>>();
> use:
> auto map = new HashMap<Integer, List<String>>();
>
> ...and "map" variable will be resolved at compile time to
> HashMap<Integer, List<String>>.
>
> This allow very handy construct, like:
>
> auto data = SomeService.getProviders();
>
> In this case type of "data" will be deducted from return type of
> SomeService.getProviders().
>
> This will save lot of typing. And save refactoring time in case if
> getProviders return type changes. And will auto-adapt to changes in
> libraries.

Scala does that. And so does most other new functional languages.

But I am somewhat concerned about readability.

In the example the reader may not remember what getProviders()
return and therefor not know what type data is without looking
it up.

Arne

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web