call superclass constructor in clojure class generation with defrecord

[coco]

Hi everybody, I need implement this java code in clojure

     public class MyWindow extends Window

     {

        public MyWindow()

         {

          super("My Window!");

         }

    }

    MyWindow myWindow = new MyWindow();

unfortunately the clojure documentation for generate classes is not so complete or straightforward for my understand...must I use gen-class or can I use defrecord for this task?...how can I call super class constructors??...

thanks

[Michael Blume]

(defn my-window []
  (proxy [Window] []))

should do the trick

Proxy takes a vector of implemented interfaces and at most one superclass (in your case, Window), and then a second vector of arguments to pass to the superclass constructor (in your case, an empty vector) and then a series of methods implemented/overridden on the parent class/interfaces -- in your case there's none of those.

My understanding is that proxy is not quite as performant as reify/defrecord, but it's the only game in town if you actually want to subclass something.

Hope this helps =)

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[coco]

thanks Michael this does the job...in this code, now I've other doubt

public class MyWindow extends Window
{

    public MyWindow()  // <--- not clear where I need declare it
    {
        super("My Window!");
        Panel horizontalPanel = new Panel(new Border.Invisible(), Panel.Orientation.HORIZONTAL);
        Panel leftPanel = new Panel(new Border.Bevel(true), Panel.Orientation.VERTICAL);
        Panel middlePanel = new Panel(new Border.Bevel(true), Panel.Orientation.VERTICAL);
        Panel rightPanel = new Panel(new Border.Bevel(true), Panel.Orientation.VERTICAL);

        horizontalPanel.addComponent(leftPanel);
        horizontalPanel.addComponent(middlePanel);
        horizontalPanel.addComponent(rightPanel);

        addComponent(horizontalPanel); // <----this is a confusing part too
    }
}

in this code addComponent(horizontalPanel)  is basically something like

this.addComponent(horizontalPanel)

does clojure have the "this" reference??...how can I call the constuctor...I'm thinkingin something like this

  (defn MyWindow []

  (proxy [Window] ["My windows!!"]

    (MyWindow [] (. this addComponent (Label. "Bang!!") )))) 

is it wrong no? :D

thanks!!!

[Michael Blume]

The defn wrapping the call to proxy basically is the constructor, so you wind up with something roughly like

(defn get-window []

  (let [this (proxy [Window] ["My Window!"]

                  ; any methods you want to override on Window go here

                  )

    ; stuff making panels goes here

         ]

    (.addComponent this horizontal-panel)

    this))

Note, I'm calling a variable 'this' but it's *just a variable, the only reason I called it 'this' was to make it look more like the java version.

[Fluid Dynamics]

On Saturday, January 31, 2015 at 6:34:10 PM UTC-5, Michael Blume wrote:

The defn wrapping the call to proxy basically is the constructor, so you wind up with something roughly like

(defn get-window []

  (let [this (proxy [Window] ["My Window!"]

                  ; any methods you want to override on Window go here

                  )

    ; stuff making panels goes here

         ]

    (.addComponent this horizontal-panel)

    this))

Note, I'm calling a variable 'this' but it's *just a variable, the only reason I called it 'this' was to make it look more like the java version.

 
Did either of the last two posters read the docs for proxy? :)

https://clojure.github.io/clojure/clojure.core-api.html#clojure.core/proxy

... "Each method fn takes an additional implicit first arg, which is bound to 'this."

[Michael Blume]

Yes, but that's for methods you're overriding and OP wants a constructor

--

[Fluid Dynamics]

On Sunday, February 1, 2015 at 11:08:19 AM UTC-5, Michael Blume wrote:

Yes, but that's for methods you're overriding and OP wants a constructor

For that you just replace

(proxy foo ...)

with

(doto
  (proxy foo ...)
  (.doThisThingy x)
  (.addThatComponent y)
  (.etc))

I would expect.

[Gary Verhaegen]

The short answer is no, there is no way to override the constructor.
proxy is not meant to create a class, it is meant to create an object.

You have an API that requires an object of type A. So you can pass it
either an object of type A, or an object of a subclass of A. You do
not want to create a new class for some reason.* So what (proxy [A]
[]) is doing, in effect, is creating an object of an anonymous class,
which is a subclass of A. Let's call that anonymous class C. But you
do not yourself define C, and cannot affect its implementation. All
you can do is specify the parameters of the constructor of the
superclass, because if the superclass constructor needs parameters,
well, proxy has to get them from somewhere.

So far this may sound pretty useless, but the C class is not just the
equivalent of

public class C extends A {}

Imagine that class C has an instance variable, which we'll call _m,
which is a Map<String, Function<List<Object>, Object>, if it was
implemented in Java 8 (Function is java.util.function.Function), and
for which each method is implemented as follows. Assuming there is a
method

public String myMethod(Integer a, String b) {...}

in class A, the equivalent method for class C would be:

public String myMethod(Integer a, String b) {
if _m.contains("myMethod") {
List<Object> args = new LinkedList<>();
args.add(a);
args.add(b);
return (String) _m.get("myMethod").apply(args);
} else {
return super(a, b);
}
}

That is, for every method in A, C has a method with the same signature
which looks up an implementation in _m and uses that.

Within the (proxy ...) form, when defining method bodies, you can use
the symbol "this" to refer to the object itself. When you define a
method with

(proxy [A] ["MyWindow"]
(someMethod [arg1 arg2] (some-code this arg1 arg2)))

what you get in the proxy mappings will be the equivalent of (ignoring
other entries):

{"someMethod" (fn [this arg1 arg2] (some-code this arg1 arg2))}

so the "this" magic is only done by the proxy macro itself. (For that
reason, I personally would not recommend using the proxy macro within
a let that actually defines a local this binding; there will be some
confusion at some point.)

So you basically have two options to emulate your constructor: create
the proxy object, then call methods on it, if all of the work of your
constructor can be done by calling methods, or close over some
variables, if you want the equivalent of new instance variables for
your object. So, for example:

(defn date-from [origin]
(proxy [java.util.Date] []
(toString [] (str (proxy-super toString) " coming from: " origin))))

user=> (.toString (date-from "localhost"))
"Sun Feb 01 19:16:12 CET 2015 coming from: localhost"
user=> (proxy-mappings (date-from "localhost"))
{"toString" #<user$date_from$fn__2905 user$date_from$fn__2905@6e3cfc75>}

proxy-super is used to access the superclass of the proxy object, when
you want to skip the proxy class implementation (i.e. exactly in the
same way you would use super in Java).

You can never change C's constructor. You can set the values in _m.
You can actually even change the values in _m after the creation of
the proxy object, with the help of clojure.lang.update-proxy.

I hope this clears things up. The performance hit of proxy versus a
"real" subclass is the dictionary lookup.

With all that said, the code snippets you have shown so far suggest to
me that you do not actually need any subclassing here. It is a pretty
common way of doing GUI things in the Java world, but subclassing GUI
components should, IMHO, be a last resort. You can do everything you
have shown so far just using a Window instance and calling its public
methods.

[coco]

Sorry for don't reply before, thanks so much michael, that works...and gary for the explanation, now it's much more clear to me...thanks guys