Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (741)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (823)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 3 [4] 5
  ignore  |  Print  
  Move to Kotlin?  (Read 4794 times)
Zeldar and 1 Guest are viewing this topic.
Offline nsigma
« Reply #90 - Posted 2017-11-09 14:04:28 »

for example a method that adds a list of subclasses to a list of superclasses.

I'm sure there are good examples of this feature, but unless I'm missing something that doesn't seem like one?

1  
2  
3  
List<SubClass> subClasses = new ArrayList<>();
List<SuperClass> superClasses = new ArrayList<>();
superClassses.addAll(subClasses);

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline h.pernpeintner

JGO Knight


Medals: 64



« Reply #91 - Posted 2017-11-09 14:13:14 »

Can you try this with List<? super SubClass> and List<? extends SuperClass> ? Smiley
Offline nsigma
« Reply #92 - Posted 2017-11-09 14:37:55 »

Can you try this with List<? super SubClass> and List<? extends SuperClass> ? Smiley

Why?  Like, seriously, provide an example of why you'd be doing that?  I do get the thoughts behind this feature, but your screed up there is either things I can't understand any reason for doing, or are an example that I just showed works fine in Java thanks very much.  Grin

Praxis LIVE - hybrid visual IDE for (live) creative coding
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #93 - Posted 2017-11-09 15:54:41 »

I always just end up using every combination of super, extends and ? till it compiles Wink
More seriously, most of the issues with generics boil down to type erasure or not being able to use primitive types, rather than the slightly unintuitive way their class hierarchies work, and they're moving towards fixing erasure and primitives in Java anyway.

Cas Smiley

Offline phunni

Senior Newbie


Exp: 17 years



« Reply #94 - Posted 2017-11-09 16:00:41 »

Late to the discussion here - sorry!

I've been seriously considering moving to Kotlin recently, or, at least, evaluating it. In fact, I've been thinking of moving away from Java to another JVM language for a while and, to be honest, the main reason is Oracle - along with a little bit of boredom. I actually still really love Java, although I really should learn another language after coding for so long (C# doesn't count since it's basically a broken version of Java imho!).  Many of the things about Java that others don't like such as verbosity, jar dependency "hell and checked exceptions don't bother even a little bit - I actually like checked exceptions as a feature, although I've long resigned myself to the fact that no-one else seems to and they won't be a feature in any other new langauges. Anyway, as I say, I'd like my future to be less controlled by Oracle, plus boredom and pragmatism make me feel like I should learn something else.

I was interested in looking at Clojure because everyone I know who uses it raves about it and I've heard repeated comments about how beautiful Lisp is. Having recently looked into it a little bit more, though, it looks like Clojure simply doesn't have the same level of support (community or otherwise) or the same number of online examples.  Not a deal breaker, but a significant negative.

So Kotlin looks like a good possibility.  I've been reading around, although I figure the only way to really evaluate it is to give it a go.
Offline abcdef
« Reply #95 - Posted 2017-11-09 16:17:19 »

The good bit of news about java is that oracle is handing a lot of it over to the community, j2ee will be moving to the eclipse foundation, java (from what i understand) will be more managed by the openjdk project and the netbeans ide is moving to Apache (alpha release of the open sourced version should be released soon).

Sounds like Google is promoting kotlin (as well at jetbrains who are the maintainers of the language) so i can see the language improving in positive ways. From a distribution perspective it won't matter whether you use java or kotlin. I also believe someone is writing some bindings for lwjgl to work with kotlin rather than java (I could be wrong here as I haven't been tracking things much here).

I'm hoping with java being managed by the openjdk community some good things will happen to the language. But kotlin does sound fun to get in to as an experiment.
Offline nsigma
« Reply #96 - Posted 2017-11-09 16:34:13 »

The good bit of news about java is that oracle is handing a lot of it over to the community, j2ee will be moving to the eclipse foundation, java (from what i understand) will be more managed by the openjdk project and the netbeans ide is moving to Apache (alpha release of the open sourced version should be released soon).

To be clear, NetBeans was pretty much always open source.  And just because it's moving to Apache, don't assume Oracle are less invested - I've heard there are more people working on NetBeans related work since the move than before.

Likewise, "handing" a lot of Java over to the community suggests they're disinvesting, and I'm not sure that's the case.  I've heard this multiple times now (paraphrased) "Oracle is not Sun.  Oracle wouldn't have open-sourced Java.  But as it is open-sourced, we're going to make the most of that".

And there are some massively good things happening to the language ...  Grin

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline phunni

Senior Newbie


Exp: 17 years



« Reply #97 - Posted 2017-11-09 17:20:33 »

"Oracle is not Sun.  Oracle wouldn't have open-sourced Java."

I find that extremely easy to believe and it's part of the reason I don't like them.
Offline CJC

Junior Devvie


Medals: 9
Exp: 7 years


Just press buttons until it works.


« Reply #98 - Posted 2017-11-09 21:55:20 »

Actually, over 55% of LWJGL is already written in Kotlin. I was surprised to find that out (I found it by chance when looking for Open Source Kotlin projects a while back).

I personally have loved developing in Kotlin over the past year or so. It's been really fun, it's really made me aware of NPEs in my other code, and it's made numerous tasks easier with some of the functions in the standard library. The ability to easily add extension/global functions is immensely helpful. The way that functions are treated as objects is so useful. The way that it forces certain "best practices" did annoy me at first, but I've found that it has helped me program with less "duh" errors (not none, but certainly less). I also like how it removes a lot of boilerplate code and how handles things like data classes for me.

One of the other things I enjoy about it is how it is being made to compile to JVM, JS, and Native, meaning that for my projects that already exist cross-platform, I can reduce some of the basic functions.

Obviously, everyone has their own preferences, some people prefer PHP for Pete's sake. Tongue
Offline nsigma
« Reply #99 - Posted 2017-11-10 10:13:19 »

"Oracle is not Sun.  Oracle wouldn't have open-sourced Java."

I find that extremely easy to believe and it's part of the reason I don't like them.

I can dislike leisure-suit Larry and his yachts as much as the next person, but I'd rather have their blatant commercialism than Sun's token lip-service to open-source.  At least when Oracle does open-source it does it properly, even if it is in its own self interest (like the massive contribution to the Linux kernel, rather than Sun's licensing everything GPL incompatible so Linux can't "steal" it).  Java (and the JVM) feels in a far healthier position now than under the last few years of Sun.

And don't think that JetBrains' development of Kotlin is some sort of altruism - it's the same blatant commercialism to strengthen sales.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline phunni

Senior Newbie


Exp: 17 years



« Reply #100 - Posted 2017-11-10 11:40:45 »

I agree and I have no problem with companies acting in their own self-interest - I'd be (pleasantly) surprised if that were not the case. But open source Java is better for all the rest of us than closed source Java fully in the hands of Oracle.

It's possible I overstated things earlier.  I'm not comfortable with the main language I use being held in such control by a corporation who, naturally, will act in their self-interest and not in the interests of Java developers - except where those interests collide.  Were Java still closed source and owned by Oracle I'd be extremely uncomfortable - would I definitely move away from Java though?  It depends on what options there were.  I'm not sure that any other JVM languages could easily or legally exist without an OS JVM.  The Oracle/closed source factor would be a significant negative for Java in my mind, but not necessarily enough to make me jump.

That all said, it is OS and I am considering a move away to other languages...
Offline h.pernpeintner

JGO Knight


Medals: 64



« Reply #101 - Posted 2017-11-10 15:59:56 »

Why?  Like, seriously, provide an example of why you'd be doing that?  I do get the thoughts behind this feature, but your screed up there is either things I can't understand any reason for doing, or are an example that I just showed works fine in Java thanks very much.  Grin

If you never had any issues with wildcards, then all the better xD I tried to say that there are cases where you need variant collections. Maybe this example is simple enough?

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
    static class SuperClass {}
    static class SubClass extends SuperClass {
        public void subClassMethod() {}
    }
    static List<SuperClass> doSomething() {
        List<SubClass> result = new ArrayList();
        result.add(new SubClass());
        for (SubClass current: result) {
            current.subClassMethod();
        }
        return result; // Won't compile
    }


You can't return the collection here because of invariance. May look like an artificial example for some - if you or they don't have had problems in this regard, complex generics can be skipped cocmpletely and stuff is unnecessary Smiley

One could now return List<? extends SuperClass> and everything is fine. But the user will have to deal with this, because he wants to use the result Smiley A better way would be to be able to declare the variance on type definition side. For example a readonly list would never ever allow to put elements into... For this case in comparison, Kotlin implements List as
1  
interface List<out E>

so the type is automatically a producer and the user doesn't have to look at variance stuff.

Yea, maybe not that important for most people, especially people new to the language. Nvm what I say Smiley

Offline Icecore
« Reply #102 - Posted 2017-11-10 18:56:23 »

I dont like in kotlin 2 dots ":" and name var before type and return of function at the end
this was keep me away from kotlin, scala, groovy and other ^^
they all have same strange pattern in syntax(like they all was parsed by Xtext Wink)

up: hm groovy don't have them)) maybe in some past i find something different to not use it - need recheck ^^
Y, now i remember) it have some compile nightmares and this one of them
http://www.gmarwaha.com/blog/2009/02/02/groovy-private-is-not-private/
(i even don't know if they fix this and other bugs ^^)

Last known State: Reassembled in Cyberspace
End Transmission....
..
.
Offline nsigma
« Reply #103 - Posted 2017-11-10 19:21:23 »

If you never had any issues with wildcards, then all the better xD I tried to say that there are cases where you need variant collections. ... May look like an artificial example for some

I didn't say I hadn't had issues with wildcards, or didn't understand the reasoning behind adding this (hey, I'm looking forward to JEP 300  Wink ) ... but that you were providing examples of doing things that are either not a problem to implement already or don't make sense to do (including your last example).

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline h.pernpeintner

JGO Knight


Medals: 64



« Reply #104 - Posted 2017-11-10 20:38:36 »

I'm trying to give examples for the exact thing that JEP300 targets to solve, I thought!? I don't have better examples than the one with the readonly list. In Java, one would have to change the return type of the doSomething() method and return a wildcard type. This is totally discouraged, because the problem then shifts to the user - could continue like this afterwards:
Quote
public static void printList(List<SuperClass> input) {
}

static void bla() {
    List<? extends SuperClass> theList = doSomething();
    printList(theList); // Won't compile
}

In Kotlin, exactly this scenario can be copy pasted (and auto transformed) and the code will compile, because type T in List is defined as...con...co...I don't know, as out, so it is only produced. Smiley
Offline nsigma
« Reply #105 - Posted 2017-11-10 21:08:59 »

In Java, one would have to change the return type of the doSomething() method and return a wildcard type.

No, you wouldn't, you'd not create the wrong list in the first place (in your contrived example!).  Of course there are real-world examples where this feature is necessary, but they're thankfully quite rare, particularly with Streams, lambdas and better inference

eg. this works (peek is horrible, but so are side effects  Wink )

1  
2  
3  
List<SuperClass> doSomething() {
  return Stream.of(new SubClass()).peek(SubClass::subClassMethod).collect(toList());
}


Now, in the context of writing things like (reactive) stream APIs then this feature (JEP 300) would be great.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline h.pernpeintner

JGO Knight


Medals: 64



« Reply #106 - Posted 2017-11-11 21:57:33 »

Yea I'm sorry, I can't give you better examples than the ones I already gave you Tongue First of all, there are scenarios where you can't use Java 8 features. Second, there absolutely is no "wrong" list in my example. Exactly this case appeared on my job where a deserializer returned a list of implementations (code not under my control). I ....uhm.. okay I don't think I can satisfy your questions with proper examples, so maybe let's stop pingpong here. However, distinction between consumer and producer is the heal to invariance. Declaration-site variance (and type projections), as available in Kotlin, eliminate the need for wildcards, hence eliminate said problems in a very simple and natural way, mostly without the user having to bother with it.
Offline Icecore
« Reply #107 - Posted 2017-11-11 23:36:14 »

Yea I'm sorry, I can't give you better examples than the ones I already gave you Tongue
We everyone knows that Java have problems
like no primitive types in List and etc,
don't need create post about its every day)

take this code its compiles fine
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
public static void main(String[] args){
   List<SuperClass> l = doSomething();
   List<SuperClass> l2 = (List<SuperClass>) doSomething2();
   List<SuperClass> l3 = (List<SuperClass>) doSomething3();
   List l4 = doSomething();
   print(l);
   print(l2);
   print(l3);
   print(l4);
}

static class SuperClass {}
static class SubClass extends SuperClass {
public void subClassMethod() {}
}

static List doSomething() {
   List<SubClass> result = new ArrayList<>();
   result.add(new SubClass());
   for (SubClass current: result) {
      current.subClassMethod();
   }
   return result;
}
static List<? extends SuperClass> doSomething2() {
   List<SubClass> result = new ArrayList<>();
   result.add(new SubClass());
   for (SubClass current: result) {
      current.subClassMethod();
   }
   return result;
}
static List<? super SubClass> doSomething3() {
   List<SubClass> result = new ArrayList<>();
   result.add(new SubClass());
   for (SubClass current: result) {
      current.subClassMethod();
   }
   return result;
}

static void print(List<SuperClass> l) {
   System.out.println("List:" + l);
}

Last known State: Reassembled in Cyberspace
End Transmission....
..
.
Offline h.pernpeintner

JGO Knight


Medals: 64



« Reply #108 - Posted 2017-11-12 01:07:53 »

We everyone knows that Java have problems
like no primitive types in List and etc,
don't need create post about its every day)

take this code its compiles fine

Oah, slowly I'm getting really annoyed here and I'm starting to understand why everybody hates us Java guys.
I'm a Java guy myself - so could we please stop with this "we know Java has faults" stuff and "Java can do things just fine" and have a talk about language design like adults? I clearly showed some examples, where a concept doesn't work out. Since Java uses this concept only (yet), there's no way around its downsides in first instance. It really doesn't matter if you (or the guy next to you, or his friend) encounter this problem often or rarely, or if there exist some suspicious workarounds or (for the user) more than necessary complex solutions. If you guys (and me too) would be honest, the answer is "yes, this problem can't be solved in a nice way with Java and we got used to it, because we have to suffer from it rarely". Than nice for you. Are other people nevertheless allowed to talk about concepts, better solutions in a thread particularly dedicated to a language that doesn't suffer (some of) these problems?

And your answer is exactly the reason why it's necessary to post again and again. All your examples actually don't compile fine. They compile with a warning. The first solution returns a raw type, which effectively means that no one can use the result in a typesafe way, as seen in example 4. If the interna of the doSomething method changes, the user's code will fail at runtime with a cast exception. Example two and three are better, because you have higher chances to get a compile error when things change. However, the consumer/producer intention is gone now, as the user can afterwards freely add arbitrary subclass instances to list l2, or even arbitrary superclass instances to l3.

However. My only intention to post in this thread was to show people that Kotlin is at least on par with Java performance and code quality wise, and later to show phunni that Kotlin's generics really make a lot of sense. I don't have desire to post anything further as it seems the majority here isn't interested in an exchange ... just keep on coding however you want.
Offline Icecore
« Reply #109 - Posted 2017-11-12 11:12:32 »

the user's code will fail at runtime with a cast exception...
However, the consumer/producer intention is gone now, as the user can afterwards freely add arbitrary subclass instances to list l2
I what look how you broke list l2 at runtime after its exit Fun with class cast XD
up: Nope sorry - i don't care XD

I know that generics is only compile time
– and clases don’t have any values from it
so you can’t check class in runtime with generic.class
I doubt that kotlin change this
https://stackoverflow.com/questions/34122450/how-to-get-generic-parameter-class-in-kotlin
So if its fails in java it may same fails in kotlin
You can’t count on generics - its only compile advices(same like annotations) – not 100% type save
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
public static void main(String[] args){
   List<SuperClass> l2 = (List<SuperClass>) doSomething2();
   //crash it runtime here
   List<? extends SuperClass> l3 = doSomething2(); //and this
}

static class SuperClass {}
static class SubClass extends SuperClass {
public void subClassMethod() {}
}
//or after exit function
static List<? extends SuperClass> doSomething2() {
   List<SubClass> result = new ArrayList<>();
   result.add(new SubClass());
   for (SubClass current: result) {
      current.subClassMethod();
   }
   return result;
}

IMO can kotlin remove useless ":" overflow? - no? - f** it

up:
However. My only intention to post in this thread was to show people that Kotlin is at least on par with Java performance and code quality wise
I hear same story couple years ago about Groovy – and all be fine until one day when enterprise start crashing in unknown place
– after spend couple weeks they find out that code compiles wrong by parser – no code errors in src code ^^

upp:
and have a talk about language design like adults
Its ok to show features,
but not ok repeat same text over and over every day
– we need move to constructive discussion)
I like Kotlin features, but don't like syntax(text) overflow comparing with java

Last known State: Reassembled in Cyberspace
End Transmission....
..
.
Offline Sickan
« Reply #110 - Posted 2017-11-12 12:52:44 »

I personally found that Kotlin lets me write projects faster, and with better style (pure functions, immutable state). For small, throwaway games and utilities its definitely faster to write them in Kotlin. Type inference is nice but it makes the code less readable. You could write types in Kotlin but then you're writing var or val unnecessarily anyway, so it's a net loss from Java. Ideally you could have IDE support for writing var and it autoconverts to the return type of the expression you assign a variable to.

Kotlin makes it easier to write final variables, I like that, and the if/try/when as expressions as well. I do agree that Kotlin doesn't seem as cohesive and well thought out as Java. I think the Scala style guide got it right in requiring explicit types for everything that isn't assigned to a constructor or a string/int/float literal.

Kotlin eliminates a lot of boilerplate code and I will probably keep using it because of that. Games are write and throw away code most of the time so the loss in readability isn't that bad while the increased development velocity is a big plus.
Offline Spasi
« Reply #111 - Posted 2017-11-12 15:31:44 »

I wanted to post a screenshot here to show how you can make Kotlin render type inference in the IDE. As I was going through my code, I realized in how few places it's actually necessary. If you remove obvious types like literals (val x = 10) and constructor calls (val foo = Foo()), I had a hard time finding a good example in lwjgl3. Probably because there are so many single-arg lambdas and I make extensive use of the implicit "it" argument. Anyway, I was more lucky in lwjgl3-vulkangen:



The grayed-out ": Foo" types are virtual, I didn't have to type them. If the right-hand side expression changes, these types are updated automatically. Lots of "it"s in here too, but note how "feature" at line 114 is annotated. Surely, this convenience will be available for Java vars too.

A few other comments based on the discussion above:

- Declaration/use-site variance and type projections: Yaaaaawn... Kotlin generics are indeed cleaner and more flexible than Java's, and you can write pseudo-reified code with inline functions. But it's still generics. There are no meta-programming features and you start hitting the inherent limitations as soon as you try to do anything half-complicated. Like in Java, I use Kotlin generics as little as possible (basically collection-style), anything else is a waste of time and effort.

- Same for data classes, you can't hear about Kotlin without hearing about data classes, but they are really not a big deal in practice. Btw, they're coming to Java. Having the syntax in place will be useful for value types though.

- Pattern matching is nice syntactic sugar. Very simple in Kotlin (when statement), Scala is more powerful there. But I honestly don't get why people get excited about switching on types... since when is that considered good practice? OK, sucks when you have to do it without syntactic support, but if the support is there, it's a huge magnet for novice programmers writing shitty code. Much more so than local type inference.

- Explicit casts in Kotlin look like:

1  
2  
val src: Any = "test"
val trg = src as String

i.e. you write the type once, not twice.

- % of Kotlin in LWJGL: It's the (offline) code generator and binding templates. The generated Java and C code lives in a different repository. The classes you get when you download LWJGL are 100% javac compiled.

- Top Kotlin features for me: extension functions/properties, null-safety/inference, anything that has to do with parameters (final-by-default, named params, default values, varargs, lambdas).

- Now that @princec mentioned it, I would love to see a thread about Clojure and the practical pros and cons of using it. Also, any tips on how to get used to the alien syntax?
Offline nsigma
« Reply #112 - Posted 2017-11-12 17:01:05 »

But I honestly don't get why people get excited about switching on types... since when is that considered good practice? OK, sucks when you have to do it without syntactic support, but if the support is there, it's a huge magnet for novice programmers writing shitty code. Much more so than local type inference.

Because structural pattern matching is great (and a bit more than just switching on types).  We've been fooled into thinking using the type system isn't good OOP, rather than the reality that it's currently error prone (compile-time safety isn't just syntactic support) and Java just isn't very good OOP!  Wink

- Now that @princec mentioned it, I would love to see a thread about Clojure and the practical pros and cons of using it. Also, any tips on how to get used to the alien syntax?

+1.  Now interestingly in the context of what I said above (Java not good OOP), I've been looking at the history of OOP a bit recently - I've read multiple people claim that Clojure is more in line with the original idea of OOP than Java is.  Grin

Praxis LIVE - hybrid visual IDE for (live) creative coding
Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #113 - Posted 2017-11-12 17:08:29 »

I guess the only way to really get to grips with Clojure is to use it in anger. It is very alien but I seem to recall taking to it like a fish to water the last time I tried any functional programming.
The main problem with it is that it is not quite so neatly organised and pleasantly or logically named as Java, coming as it does from a background to make old beardy Lispers happy, rather than Java programmers happy.

Also be warned that it is not especially fast or efficient...

Cas Smiley

Offline philfrei
« Reply #114 - Posted 2017-11-12 18:27:46 »

Would love to see (tutorials):

Getting started with game programming with Clojure
Getting started with game programming with Kotlin

and make both oriented for Java programmers.

Get a basic game loop going, and bounce a ball, with keyboard/mouse interaction (as I did with JavaFX).

Learning Clojure was very fun and weird. When I was looking at it, I also went through the first few MIT Structure and Interpretation lectures, and recoded them with Clojure. This was my first introduction to LISP-type structures and programming patterns. It is great help for getting your head around operations using function interfaces in chains. But I didn't see it through to where I could figure out how to make a game with it.

music and music apps: http://adonax.com
Offline h.pernpeintner

JGO Knight


Medals: 64



« Reply #115 - Posted 2017-11-12 18:46:56 »

Lisp-like languages are perfect candidates to write one's own interpreter/compiler for. That's where I used them before. But i really can't imagine how a game written with clojure would look like, so I would be interested in a Tutorial as well Smiley
Offline Sickan
« Reply #116 - Posted 2017-11-12 19:54:48 »

Switching on type is an old Java tradition, it's called the visitor pattern.
Offline h.pernpeintner

JGO Knight


Medals: 64



« Reply #117 - Posted 2017-11-13 08:22:23 »

Yes, But normally it is implemented with inheritance, because business logic for a couple different implementations in one method/class seeeeeeems to be Bad practice. And now everyone wonders why the big switch case returns everywhere xD
Offline orange451

JGO Kernel


Medals: 346
Projects: 6
Exp: 6 years


Your face. Your ass. What's the difference?


« Reply #118 - Posted 2017-11-14 00:07:13 »

This post got me to go look at Kotlin.

I've never actually smashed something and said "But why" before...

First Recon. A java made online first person shooter!
Offline cygnus
« Reply #119 - Posted 2017-11-15 21:29:04 »

Man did I really not mention that virtual type rendering from the IDE? I should have. It does seem to address at least some of the problems mentioned here. Not yet in 7 months of programming in Kotlin has something being the wrong type been an issue that wasn't just design-related.

I could make a basic tutorial for getting some stuff working too - maybe I'll start work on that now?

Edit - first part of the tutorial is out: http://www.java-gaming.org/topics/game-design-in-kotlin-for-java-programmers/38484/msg/367416/view.html#msg367416
Pages: 1 2 3 [4] 5
  ignore  |  Print  
 
 

 
xxMrPHDxx (18 views)
2017-11-21 16:21:00

xxMrPHDxx (11 views)
2017-11-21 16:14:31

xxMrPHDxx (14 views)
2017-11-21 16:10:57

Ecumene (114 views)
2017-09-30 02:57:34

theagentd (148 views)
2017-09-26 18:23:31

cybrmynd (248 views)
2017-08-02 12:28:51

cybrmynd (248 views)
2017-08-02 12:19:43

cybrmynd (244 views)
2017-08-02 12:18:09

Sralse (258 views)
2017-07-25 17:13:48

Archive (878 views)
2017-04-27 17:45:51
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!