self

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

self

interaction-designer
Hi List,

It would be nice if there would be an implementation of self. It's advantages are comparable with new (haxe) over using the classname for a constructor (as with as3: class Bar { public function Bar(){}}).  

for instance I have some class:

class TreeSet <T>{
  public static function create<T>():TreeSet<T>{
     return new TreeSet();
  }
  public static function factory<T>(): Factory<TreeSet<T>> {
    return function() {
      return TreeSet.create(order, equal, hash, show);
    }
  }
  private function new(){
  }
}


If I have to refactor things and change the classname, than most probably TreeSet must be renamed. Comparable as with the vanilla AS3 constructors.
It would be easier to refer to static fields of the same class with Self, like this:

class TreeSet <T>{
  public static function create<T>():Self<T>{
     return new Self();
  }
  public static function factory<T>(): Factory<Self<T>> {
    return function() {
      return Self.create(order, equal, hash, show);
    }
  }
  private function new(){
  }
}

I think it also makes it more readable too.

Or am I proposing something really stupid?
If no, how hard is it to implement it? Any ideas on implementation strategies?
If yes, can please tell me why?

Greetings, Simon

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: self

interaction-designer
Hi List

And it would be cool if both ways (Bar, Self and automatically) are possible:

class Bar<T> {
   public static function create():Self<T>{
       var s=new Self();
       s=Bar.hash(s);
       doSomething(s);
       return new Self();
   }
   public static function factory():Factory<Self<T>>{
      return function(){
      return Self.create();
      }
   }
   public static function hash(instance:Bar):Bar{
   }
   public static function doSomething(instance:Self){
   }
}

This way it doesn't break existing code and a maybe less relevant benefit is that I can explicitly point to Self and Bar. This means the Self means it really must refer to the same class and Bar doesn't. This can make refactoring algo's also easier I think.  

Greetings, Simon

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: self

MarcWeber
In reply to this post by interaction-designer
Excerpts from interaction-designer's message of Sat Sep 25 13:27:16 +0200 2010:
> It would be nice if there would be an implementation of self.
Yes, its missing. I would have used it several times as myself if it
existed.

Marc Weber

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: self

MarcWeber
In reply to this post by interaction-designer
Excerpts from interaction-designer's message of Sat Sep 25 13:46:50 +0200 2010:
> [ class Bar { ..  ]
> And it would be cool if both ways (Bar, Self and automatically) are possible:

Think about it: There is no choice: You have to support both. HaXe tries
to be compatible as much as possible. So give a reason why you thought
the old behaviour could have been dropped ?

Marc Weber

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: self

interaction-designer
Hi Marc, List

I am not saying anything like the old behavior could be dropped! And I am not suggesting it either! Despite of the fact that their would be no choice to have them both, i am even making a point that there are more benefits of having them both than just because of compatibility!

I only say what I am literally saying, there is nothing to be found between the lines. No reasons to make things more complicated than necessary. I am very open and explicit about my assumptions. Which is also why I was asking if my idea about Self was stupid or not in the first place.

Anyway good to hear that you miss it too, than I can at least feel less stupid of missing such functionality.

Greetings Simon.

----- Oorspronkelijk bericht -----
Van: "Marc Weber" <[hidden email]>
Aan: "haxe" <[hidden email]>
Verzonden: Zaterdag 25 september 2010 14:03:38 GMT +01:00 Amsterdam / Berlijn / Bern / Rome / Stockholm / Wenen
Onderwerp: Re: [haXe] self

Excerpts from interaction-designer's message of Sat Sep 25 13:46:50 +0200 2010:
> [ class Bar { ..  ]
> And it would be cool if both ways (Bar, Self and automatically) are possible:

Think about it: There is no choice: You have to support both. HaXe tries
to be compatible as much as possible. So give a reason why you thought
the old behaviour could have been dropped ?

Marc Weber

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: self

MarcWeber
> I only say what I am literally saying, there is nothing to be found between the lines.
Sorry. Will not happen again. I missed some words.

I don't think its very hard to implement.

About Self.create(): Are you aware that you could omit Self. Here
because self.* is in scope by default?

Of course this does not apply for new Self().

The funny thing is: If HaXe used Ruby Style: Name.new() instead of new
Name() then you could just use

  function create(){
    return new();
  }


Does soemone dislike the Self proposal made by Simon?

Marc Weber

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: self

interaction-designer
In reply to this post by interaction-designer
List,

I am not necessarily saying I want the same style as Ruby, I don't know Ruby by heart.

I was suggesting, as I posted earlier, a Self functionality so it would be possible to do:

class TreeSet <T>{
  public static function create<T>():Self<T>{
     return new Self();
  }
  public static function factory<T>(): Factory<Self<T>> {
    return function() {
      return Self.create(order, equal, hash, show);
    }
  }
  private function new(){
  }
}


And by having also supporting the current way even this:


class Bar<T> {
   public static function create():Self<T>{
       var s=new Self();
       s=Bar.hash(s);
       doSomething(s);
       return new Self();
   }
   public static function factory():Factory<Self<T>>{
      return function(){
      return Self.create();
      }
   }
   public static function hash(instance:Bar):Bar{
   }
   public static function doSomething(instance:Self){
   }
}

@Marc, previous post you said:
I wasn't aware of the omitting you speak of. Can you explain it a bit. I am really confused by your last post. Now I am afraid I the one being jailed between the lines ;)
This is what you wrote:

> About Self.create(): Are you aware that you could omit Self. Here
> because self.* is in scope by default?

> The funny thing is: If HaXe used Ruby Style: Name.new() instead of new
> Name() then you could just use
>
>  function create(){
>    return new();
>  }

Such is already possible if you would use this:

class Bar extends Foo{
  function create(){
    new();
  }
  function new(){
    super();
  }
}

Or does your code example mean this?

class Bar extends Foo{
 static function create(){
    new();
 }
 function new(){
   super()
 }
}

Please explain the omitting, scope, and please by a hard to misinterpret code example. Utterly confused I am. Help me out please!

Greetings, Simon

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: self

MarcWeber
Hi Simon,

class Test {

  var arg:String;
  public function new(arg) { this.arg = arg; }

  static public function create() {
    return new Test("tho");
  }
 
  static public function main() {
    trace(create()); // <<<<<
  }

}

I was talking about that call to create usage. This is the same as
Test.create. That's what I mean by saying "self.*" is in scope. You can
call all static functions of the same class without prefixing Self.

Both Ruby and HaXe have new constructors. The difference is the way you
call them:

Ruby:
Test.new(arg); // creates a new Test instance

HaXe:
new Test(); // does the same.


The <<<<< example above illustrated how to omit the self reference
"Test.". However this can't be done for instantiating an object AFAIK.

if you try your create(){
  // valid:
  return Test.new();
  // I could imagine this syntax:
  return new();
  // If we had Ruby like new syntax this would be natural - but we
  // don't.
}


Summary:

- When calling static members you don't need a self reference
  cause you can access them without class name using the function name
  only.
  Self could be added for the same reason as this. exists.


- new ClassName() is the only way thus new Self() would be more HaXe
  like way we could introduce. However new() could be an alternative
  interesting syntax cause its shorter.


Thus patching the compiler is only required for the new Self() usage.

Marc Weber

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: self

Yanis Benson
In reply to this post by interaction-designer
On 09/25/2010 03:27 PM, [hidden email] wrote:
Hi List,

It would be nice if there would be an implementation of self. It's advantages are comparable with new (haxe) over using the classname for a constructor (as with as3: class Bar { public function Bar(){}}).  

for instance I have some class:

class TreeSet <T>{
  public static function create<T>():TreeSet<T>{
     return new TreeSet();
  }
  public static function factory<T>(): Factory<TreeSet<T>> {
    return function() {
      return TreeSet.create(order, equal, hash, show);
    }
  }
  private function new(){
  }
}


If I have to refactor things and change the classname, than most probably TreeSet must be renamed. Comparable as with the vanilla AS3 constructors. 
It would be easier to refer to static fields of the same class with Self, like this:

class TreeSet <T>{
  public static function create<T>():Self<T>{
     return new Self();
  }
  public static function factory<T>(): Factory<Self<T>> {
    return function() {
      return Self.create(order, equal, hash, show);
    }
  }
  private function new(){
  }
}

I think it also makes it more readable too.

Or am I proposing something really stupid? 
If no, how hard is it to implement it? Any ideas on implementation strategies?
If yes, can please tell me why?

Greetings, Simon

And another thing...

I love construction like
var thing = new Thing(..).move(...).size(...).doSomethingElse();
and just calling methods in this way:
    thing.move(...).size(...);
where move, size, doSomethiungElse return pointer to "this". It's both fast and good looking in the code.
But when we have class SubThing extends Thing{...} then everything gets broken, since
var subthing = new SubThing(...).move(...).size(...).doSomethingElse();
return Thing, not SubThing, so we can't use SubThing methods and also in example above when we append this method calls just after creating an instance var thing is typed as Thing, so:
var subthing:SubThing;
function ...(...){
    subthing = new SubThing(...).move(...);
    }
throws a compile time error.

It's possible to implement Self in a way that it all will go ok, thus reducing many pains(since currently this behavior I like very much is achievable only by implementing a copy of base class methods in subclasses or by using Dynamic which aren't fast to code nor safe).

                                                               ---------------- Yanis.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: self

Nathan
Yanis Benson wrote:

>  On 09/25/2010 03:27 PM, [hidden email] wrote:
>> Hi List,
>>
>> It would be nice if there would be an implementation of self. It's
>> advantages are comparable with new (haxe) over using the classname for
>> a constructor (as with as3: class Bar { public function Bar(){}}).
>>
>> for instance I have some class:
>>
>> class TreeSet<T>{
>>    public static function create<T>():TreeSet<T>{
>>       return new TreeSet();
>>    }
>>    public static function factory<T>(): Factory<TreeSet<T>>  {
>>      return function() {
>>        return TreeSet.create(order, equal, hash, show);
>>      }
>>    }
>>    private function new(){
>>    }
>> }
>>
>>
>> If I have to refactor things and change the classname, than most
>> probably TreeSet must be renamed. Comparable as with the vanilla AS3
>> constructors.
>> It would be easier to refer to static fields of the same class with
>> Self, like this:
>>
>> class TreeSet<T>{
>>    public static function create<T>():Self<T>{
>>       return new Self();
>>    }
>>    public static function factory<T>(): Factory<Self<T>>  {
>>      return function() {
>>        return Self.create(order, equal, hash, show);
>>      }
>>    }
>>    private function new(){
>>    }
>> }
>>
>> I think it also makes it more readable too.
>>
>> Or am I proposing something really stupid?
>> If no, how hard is it to implement it? Any ideas on implementation
>> strategies?
>> If yes, can please tell me why?
>>
>> Greetings, Simon
>>
> And another thing...
>
> I love construction like
>
>    var thing = new Thing(..).move(...).size(...).doSomethingElse();
>
> and just calling methods in this way:
>     thing.move(...).size(...);
> where move, size, doSomethiungElse return pointer to "this". It's both
> fast and good looking in the code.
> But when we have class SubThing extends Thing{...} then everything gets
> broken, since
>
>    var subthing = new SubThing(...).move(...).size(...).doSomethingElse();
>
> return Thing, not SubThing, so we can't use SubThing methods and also in
> example above when we append this method calls just after creating an
> instance var thing is typed as Thing, so:
>
>    var subthing:SubThing;
>    function ...(...){
>         subthing = new SubThing(...).move(...);
>         }
>
> throws a compile time error.
>
> It's possible to implement Self in a way that it all will go ok, thus
> reducing many pains(since currently this behavior I like very much is
> achievable only by implementing a copy of base class methods in
> subclasses or by using Dynamic which aren't fast to code nor safe).

this is where coding to interfaces rather than implementations comes in
rather handy :)

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: self

Nathan
In reply to this post by MarcWeber
Marc Weber wrote:
> Excerpts from interaction-designer's message of Sat Sep 25 13:27:16 +0200 2010:
>> It would be nice if there would be an implementation of self.
> Yes, its missing. I would have used it several times as myself if it
> existed.

snap, haxe is missing a few very common keywords, self being a notable one.

also, haxe prevents usage of keywords in some very strange places which
is a complete PITA

   public function import( c:Array<T> ) ..

fail!

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: self

Simon Asselbergs
In reply to this post by Yanis Benson
Hi Yanis, Nicholas & List,

I am curious what people like or not like about this idea.
Please no +1 or -1 votes, or a oneliner, but please a response which evaluates the idea (like Yanis and Marc have done).

Yanis and Marc: Nice to see you look beyond the possibilities I imagined. Thank you for constructive contribution to this discussion.

Cordially greetings, Simon

On Thu, Sep 30, 2010 at 8:01 PM, Yanis Benson <[hidden email]> wrote:
On 09/25/2010 03:27 PM, [hidden email] wrote:
Hi List,

It would be nice if there would be an implementation of self. It's advantages are comparable with new (haxe) over using the classname for a constructor (as with as3: class Bar { public function Bar(){}}).  

for instance I have some class:

class TreeSet <T>{
  public static function create<T>():TreeSet<T>{
     return new TreeSet();
  }
  public static function factory<T>(): Factory<TreeSet<T>> {
    return function() {
      return TreeSet.create(order, equal, hash, show);
    }
  }
  private function new(){
  }
}


If I have to refactor things and change the classname, than most probably TreeSet must be renamed. Comparable as with the vanilla AS3 constructors. 
It would be easier to refer to static fields of the same class with Self, like this:

class TreeSet <T>{
  public static function create<T>():Self<T>{
     return new Self();
  }
  public static function factory<T>(): Factory<Self<T>> {
    return function() {
      return Self.create(order, equal, hash, show);
    }
  }
  private function new(){
  }
}

I think it also makes it more readable too.

Or am I proposing something really stupid? 
If no, how hard is it to implement it? Any ideas on implementation strategies?
If yes, can please tell me why?

Greetings, Simon

And another thing...

I love construction like
var thing = new Thing(..).move(...).size(...).doSomethingElse();
and just calling methods in this way:
    thing.move(...).size(...);
where move, size, doSomethiungElse return pointer to "this". It's both fast and good looking in the code.
But when we have class SubThing extends Thing{...} then everything gets broken, since
var subthing = new SubThing(...).move(...).size(...).doSomethingElse();
return Thing, not SubThing, so we can't use SubThing methods and also in example above when we append this method calls just after creating an instance var thing is typed as Thing, so:
var subthing:SubThing;
function ...(...){
    subthing = new SubThing(...).move(...);
    }
throws a compile time error.

It's possible to implement Self in a way that it all will go ok, thus reducing many pains(since currently this behavior I like very much is achievable only by implementing a copy of base class methods in subclasses or by using Dynamic which aren't fast to code nor safe).

                                                               ---------------- Yanis.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: self

Raoul Duke
On Thu, Sep 30, 2010 at 12:52 PM, Simon Asselbergs
<[hidden email]> wrote:
>> I love construction like
>> var thing = new Thing(..).move(...).size(...).doSomethingElse();

demeter would be proud ;-)

--
haXe - an open source web programming language
http://haxe.org