objectionary / eo

EOLANG, an Experimental Pure Object-Oriented Programming Language Based on 𝜑-calculus
https://www.eolang.org
MIT License
1.04k stars 132 forks source link

Java objects inside EO code #217

Open yegor256 opened 3 years ago

yegor256 commented 3 years ago

How about we create a new EO atom, which will represent Java objects. For example:

+alias org.eolang.java

[] > main
  stdout
    sprintf
      "Today is %s"
      (java.new "java.util.Date").toString

Here, java.new will make a new Java object java.util.Date and wrap it the right way, so that it becomes EO object.

We can also make it possible to make static calls:

+alias org.eolang.java

[] > main
  stdout
    sprintf
      "Now is %d msec"
      java.static "java.lang.System" "currentTimeMillis"
andreoss commented 2 years ago

@yegor256 Ready to take this.

yegor256 commented 2 years ago

@andreoss go ahead. But I suggest you start slowly, it's a complex task and it would be great to discuss design decisions before implementing them.

andreoss commented 2 years ago

@yegor256 Instead of dividing methods into static or instance, we could treat new as a method.

((java "String").call "new" 65-66-67).as-string
(((java "Random").call "new).call "nextBoolean").as-bool

Same would go for fields,

((java "Integer").field "MAX_VALUE").as-int # Static field
((java "byte[]").new 1 2 3).field "length))  # Instance field

Over all the object would look like this

# Java interop.
[class] > java
    [method args..] > call  /java
    [name] > field /java
    [] > as-int    /int
    [] > as-float  /float
    [] > as-bool   /bool
    [] > as-string /string

could be more readble, if instead of quoted string, some symbol type would be used.

((java :System).call :currentMillis).as-int
((java :String).call :new 65-66-67).as-string
(((java :Random).call :new).call :nextBoolean).as-bool
yegor256 commented 2 years ago

@andreoss I think would be convenient if we make EO objects already with "methods" as in Java:

(java "Random").new.nextBoolean.as-bool

Isn't it possible?

andreoss commented 2 years ago

@yegor256 Should there be some mechanism which intersects calls to missing attributes? Like method_missing

[] > foo
   [attr] > missing

foo.bar # calls `foo.missing "bar"` '
yegor256 commented 2 years ago

@andreoss but you know what attributes are there in Java, you have this information when you construct an object at new.φ:

@XmirObject(oname = "new")
public class EOnew extends PhDefault {
    public EOnew(final Phi sigma) {
        super(sigma);
        this.add("φ", new AtComposite(this, rho -> {
          // Here you know what is in Java and can build the object
          // exactly as it should be, in EO
        }
    }
}
andreoss commented 2 years ago

@yegor256 Is it still in scope?

andreoss commented 2 years ago

@yegor256 @Graur I want to continue to work on this issue, any objections?

yegor256 commented 2 years ago

@andreoss sure, but 1) we should move this feature to a separate package/repository, I believe, and 2) how will it work if EO is compiled to Rust and then to binaries, for example?