Getter and Setter Problem

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

Getter and Setter Problem

Heinz Hölzer-2
it should be possible to declare a public property in an interface
and a read/write property in a class that implements this interface.

this is currently not possible:

interface Elem
{
    var x(getX, null):Float;
}

class ElemImpl implements Elem {
   
    public function new () {}
   
    private var _x:Float;
    public var x(getX, setX):Float;
   
    private function getX ():Float { return _x; }
    private function setX (value:Float):Float { _x = value; return _x; }
}

but it should be possible to hide the setter from the interface.

Is there a clean way to get this working?

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

Re: Getter and Setter Problem

Cauê W.
I don't think that is really possible, since the compiler seems to replace every call to a variable to its getter/setter function, so there's no way for it to know, at compile time, that the class implementation has a setter field different from the interface.
So maybe for now we've got to stick with having to declare the getters/setters on the interface itself.

Maybe the opposite would be possible: what could be done is to declare the getter/setter on the interface, and have a special keyword (it could be the default keyword, really), that will generate the function automatically. Meaning:

interface Elem
{
var x(get_x, set_x):Float
function get_x():Float;
function set_x(value:Float):Float;
}

class ElemImpl implements Elem
{
public var x(get_x, default);
public function new() { }

public function get_x():Float
{
trace("getting x");
return this.x;
}

}

This could automatically generate the function

public function set_x(value:Float):Float
{
return this.x = value;
}


That is not the current behaviour, but knowing how haXe works, this seems that could be an option

Oh! And a tip:

In haXe, you don't need to use _x:Float to store values. You can use the same variable name inside the getters and setters, just as it is used in here.

cheers!
Cauê Waneck
2009/8/12 Heinz Hölzer <[hidden email]>
it should be possible to declare a public property in an interface
and a read/write property in a class that implements this interface.

this is currently not possible:

interface Elem
{
  var x(getX, null):Float;
}

class ElemImpl implements Elem {
    public function new () {}
    private var _x:Float;
  public var x(getX, setX):Float;
    private function getX ():Float { return _x; }
  private function setX (value:Float):Float { _x = value; return _x; }
}

but it should be possible to hide the setter from the interface.

Is there a clean way to get this working?

--
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: Getter and Setter Problem

Heinz Hölzer-2
Oh, thx for the tip, good to know.

I know that you can not override the getter or setter in the
implementation,
but for example if the interface declares "null" (just the null case)
for a getter,
then it must be possible "extend" the functionality in your Implementation,

Cauê Waneck schrieb:

> I don't think that is really possible, since the compiler seems to
> replace every call to a variable to its getter/setter function, so
> there's no way for it to know, at compile time, that the class
> implementation has a setter field different from the interface.
> So maybe for now we've got to stick with having to declare the
> getters/setters on the interface itself.
>
> Maybe the opposite would be possible: what could be done is to declare
> the getter/setter on the interface, and have a special keyword (it
> could be the default keyword, really), that will generate the function
> automatically. Meaning:
>
> interface Elem
> {
> var x(get_x, set_x):Float
> function get_x():Float;
> function set_x(value:Float):Float;
> }
>
> class ElemImpl implements Elem
> {
> public var x(get_x, default);
> public function new() { }
>
> public function get_x():Float
> {
> trace("getting x");
> return this.x;
> }
>
> }
>
> This could automatically generate the function
>
> public function set_x(value:Float):Float
> {
> return this.x = value;
> }
>
>
> That is not the current behaviour, but knowing how haXe works, this
> seems that could be an option
>
> Oh! And a tip:
>
> In haXe, you don't need to use _x:Float to store values. You can use
> the same variable name inside the getters and setters, just as it is
> used in here.
>
> cheers!
> Cauê Waneck
> 2009/8/12 Heinz Hölzer <[hidden email]
> <mailto:[hidden email]>>
>
>     it should be possible to declare a public property in an interface
>     and a read/write property in a class that implements this interface.
>
>     this is currently not possible:
>
>     interface Elem
>     {
>       var x(getX, null):Float;
>     }
>
>     class ElemImpl implements Elem {
>         public function new () {}
>         private var _x:Float;
>       public var x(getX, setX):Float;
>         private function getX ():Float { return _x; }
>       private function setX (value:Float):Float { _x = value; return _x; }
>     }
>
>     but it should be possible to hide the setter from the interface.
>
>     Is there a clean way to get this working?
>
>     --
>     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: Getter and Setter Problem

Nicolas Cannasse
In reply to this post by Heinz Hölzer-2
Heinz Hölzer a écrit :
> it should be possible to declare a public property in an interface
> and a read/write property in a class that implements this interface.

I'll see what can be done for that.

Nicolas

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

Re: Getter and Setter Problem

Heinz Hölzer-2
sounds great, thx

Nicolas Cannasse schrieb:
> Heinz Hölzer a écrit :
>> it should be possible to declare a public property in an interface
>> and a read/write property in a class that implements this interface.
>
> I'll see what can be done for that.
>
> Nicolas
>


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

Re: Getter and Setter Problem

Pimm Hogeling
In reply to this post by Cauê W.
This is actually the biggest issue I'm having with haXe. Not too big of an issue, but still, the biggest.

I know this is a known problem because the compiler replaces the getters and the setters, and I don't know if this would be possible, but here are my thoughts. In the ideal world an interface has only two different keywords for getters and setters: "default" (or maybe an other word, such as "existing") meaning there must be a getter or a setter and "null" meaning there might not be a getter or a setter. If default is used, implementations of that interface must have a getter, or a setter. This would allow us to have:
interface IReadableFoo {
    public var property(default, null);
}
And:
IWritableFoo implements IReadableFoo {
    public var property(default, default);
}
Implementations of IReadableFoo must have a getter for property, and may have a setter, too. Implementations of IWritableFoo must have both.

We could keep all the current keywords too, for backwards compatibility. However, I think you only need those two. That would be really sweet, since AS3 does not support that at the moment.

Thanks,

Pimm Hogeling

On Thu, Aug 13, 2009 at 02:26, Cauê Waneck <[hidden email]> wrote:
I don't think that is really possible, since the compiler seems to replace every call to a variable to its getter/setter function, so there's no way for it to know, at compile time, that the class implementation has a setter field different from the interface.
So maybe for now we've got to stick with having to declare the getters/setters on the interface itself.

Maybe the opposite would be possible: what could be done is to declare the getter/setter on the interface, and have a special keyword (it could be the default keyword, really), that will generate the function automatically. Meaning:

interface Elem
{
var x(get_x, set_x):Float
function get_x():Float;
function set_x(value:Float):Float;
}

class ElemImpl implements Elem
{
public var x(get_x, default);
public function new() { }

public function get_x():Float
{
trace("getting x");
return this.x;
}

}

This could automatically generate the function

public function set_x(value:Float):Float
{
return this.x = value;
}


That is not the current behaviour, but knowing how haXe works, this seems that could be an option

Oh! And a tip:

In haXe, you don't need to use _x:Float to store values. You can use the same variable name inside the getters and setters, just as it is used in here.

cheers!
Cauê Waneck
2009/8/12 Heinz Hölzer <[hidden email]>

it should be possible to declare a public property in an interface
and a read/write property in a class that implements this interface.

this is currently not possible:

interface Elem
{
  var x(getX, null):Float;
}

class ElemImpl implements Elem {
    public function new () {}
    private var _x:Float;
  public var x(getX, setX):Float;
    private function getX ():Float { return _x; }
  private function setX (value:Float):Float { _x = value; return _x; }
}

but it should be possible to hide the setter from the interface.

Is there a clean way to get this working?

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


--
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: Getter and Setter Problem

Mark de Bruijn | Dykam
How would the method resolvement be done?

I suggest the C# solution - I know, again C# - which is that for an property getter and setter, the functions are named as follows: get_PropName and set_PropName. Actually C# hides this by the following syntax:
Type PropName {
get {
// Any return code
}
set {
// Any set code with value as value holding keyword.
}
}
Haxefied:
var PropName:Type {
get {
// Any return code
}
set {
// Any set code with value as value holding keyword.
}
}
Both fields are optional, like in haXe, and there isn't a interface problem as there is now, as naming is standardized.
This would be an breaking change, surely, but maybe solve the current problems.

and where haXe has 
public var PropName(default, null):Type
has C# two solutions, depending on your problem.
In case you want a readonly value, you use just
public Type PropName { get { return value; } } 
in case of private setting the following
public Type PropName { get; private set; }
which is automagically transformed into a getter/setter with the appropiate backend variable.

Let me hear your opinions.


2009/8/13 Pimm Hogeling <[hidden email]>
This is actually the biggest issue I'm having with haXe. Not too big of an issue, but still, the biggest.

I know this is a known problem because the compiler replaces the getters and the setters, and I don't know if this would be possible, but here are my thoughts. In the ideal world an interface has only two different keywords for getters and setters: "default" (or maybe an other word, such as "existing") meaning there must be a getter or a setter and "null" meaning there might not be a getter or a setter. If default is used, implementations of that interface must have a getter, or a setter. This would allow us to have:
interface IReadableFoo {
    public var property(default, null);
}
And:
IWritableFoo implements IReadableFoo {
    public var property(default, default);
}
Implementations of IReadableFoo must have a getter for property, and may have a setter, too. Implementations of IWritableFoo must have both.

We could keep all the current keywords too, for backwards compatibility. However, I think you only need those two. That would be really sweet, since AS3 does not support that at the moment.

Thanks,

Pimm Hogeling

On Thu, Aug 13, 2009 at 02:26, Cauê Waneck <[hidden email]> wrote:
I don't think that is really possible, since the compiler seems to replace every call to a variable to its getter/setter function, so there's no way for it to know, at compile time, that the class implementation has a setter field different from the interface.
So maybe for now we've got to stick with having to declare the getters/setters on the interface itself.

Maybe the opposite would be possible: what could be done is to declare the getter/setter on the interface, and have a special keyword (it could be the default keyword, really), that will generate the function automatically. Meaning:

interface Elem
{
var x(get_x, set_x):Float
function get_x():Float;
function set_x(value:Float):Float;
}

class ElemImpl implements Elem
{
public var x(get_x, default);
public function new() { }

public function get_x():Float
{
trace("getting x");
return this.x;
}

}

This could automatically generate the function

public function set_x(value:Float):Float
{
return this.x = value;
}


That is not the current behaviour, but knowing how haXe works, this seems that could be an option

Oh! And a tip:

In haXe, you don't need to use _x:Float to store values. You can use the same variable name inside the getters and setters, just as it is used in here.

cheers!
Cauê Waneck
2009/8/12 Heinz Hölzer <[hidden email]>

it should be possible to declare a public property in an interface
and a read/write property in a class that implements this interface.

this is currently not possible:

interface Elem
{
  var x(getX, null):Float;
}

class ElemImpl implements Elem {
    public function new () {}
    private var _x:Float;
  public var x(getX, setX):Float;
    private function getX ():Float { return _x; }
  private function setX (value:Float):Float { _x = value; return _x; }
}

but it should be possible to hide the setter from the interface.

Is there a clean way to get this working?

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


--

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


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



--
Mark

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

Re: Getter and Setter Problem

Simon Krajewski
In reply to this post by Heinz Hölzer-2
Heinz Hölzer schrieb:

> it should be possible to declare a public property in an interface
> and a read/write property in a class that implements this interface.
>
> this is currently not possible:
>
> interface Elem
> {
>    var x(getX, null):Float;
> }
>
> class ElemImpl implements Elem {
>      public function new () {}
>      private var _x:Float;
>    public var x(getX, setX):Float;
>      private function getX ():Float { return _x; }
>    private function setX (value:Float):Float { _x = value; return _x; }
> }
>
> but it should be possible to hide the setter from the interface.
>
> Is there a clean way to get this working?
I cannot say, but I'm curious about the use case of variables in
interfaces. An interface is supposed to describe how you can interact
with ALL implementing objects from outside. Your Elem interface above
reads: every class implementing Elem has a float variable x that can be
read with method getX, but not written to. Overriding this read/write
behaviour in an implementing class just defeats the very purpose of the
interface. If you want "you can read using getX and I don't care if you
can write or not", just define getX():Float in your interface. Then
implementing classes must provide the getX that returns a float (where
this float is stored is up to them, as it should be because interfaces
should not contain implementation details) and can optionally provide a
setter method for x.

Or maybe I'm just missing the point. I admit I'm not really used to
allowing variables in interfaces, but it just seems like something that
doesn't make any sense to begin with and leads to confusing designs.

Regards
Simon

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

Re: Getter and Setter Problem

Mark de Bruijn | Dykam


On Fri, Aug 14, 2009 at 10:02 AM, Simon Krajewski <[hidden email]> wrote:
Or maybe I'm just missing the point. I admit I'm not really used to allowing variables in interfaces, but it just seems like something that doesn't make any sense to begin with and leads to confusing designs.

If it is confused depends on experiences. I've used interface properties a lot, interfaces is for me one of the reasons to use properties. Or what some C# guru's say, always expose properties, never fields. You get used to it.

--
Mark

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

Re: Getter and Setter Problem

jlm@justinfront.net
In reply to this post by Mark de Bruijn | Dykam
My Quick thoughts.

Currently it can take a lot of code that is not quick to scan, so while more syntax might not be good, letting the compiler infer some would allow code that was much easier to scan.

Taking a typical instance...

        public var up( _get_up, _set_up ):Float;
            
        private function _get_up():Float{ return _plain.up; }
        private function _set_up( r: Float ):Float{ _plain.up = r; return r; }
        
It would be useful to be able to use the following short hand..
        
        public var up( { return _plain.up; }, { _plain.up = r; return r; } ):Float

This is not introducing any new syntax just expecting the compiler to infer some for you, I don't see this would reduce any current possibilities.

Cheers

;j

On 14 Aug 2009, at 08:26, Mark de Bruijn wrote:

How would the method resolvement be done?

I suggest the C# solution - I know, again C# - which is that for an property getter and setter, the functions are named as follows: get_PropName and set_PropName. Actually C# hides this by the following syntax:
Type PropName {
get {
// Any return code
}
set {
// Any set code with value as value holding keyword.
}
}
Haxefied:
var PropName:Type {
get {
// Any return code
}
set {
// Any set code with value as value holding keyword.
}
}
Both fields are optional, like in haXe, and there isn't a interface problem as there is now, as naming is standardized.
This would be an breaking change, surely, but maybe solve the current problems.

and where haXe has 
public var PropName(default, null):Type
has C# two solutions, depending on your problem.
In case you want a readonly value, you use just
public Type PropName { get { return value; } } 
in case of private setting the following
public Type PropName { get; private set; }
which is automagically transformed into a getter/setter with the appropiate backend variable.

Let me hear your opinions.


2009/8/13 Pimm Hogeling <[hidden email]>
This is actually the biggest issue I'm having with haXe. Not too big of an issue, but still, the biggest.

I know this is a known problem because the compiler replaces the getters and the setters, and I don't know if this would be possible, but here are my thoughts. In the ideal world an interface has only two different keywords for getters and setters: "default" (or maybe an other word, such as "existing") meaning there must be a getter or a setter and "null" meaning there might not be a getter or a setter. If default is used, implementations of that interface must have a getter, or a setter. This would allow us to have:
interface IReadableFoo {
    public var property(default, null);
}
And:
IWritableFoo implements IReadableFoo {
    public var property(default, default);
}
Implementations of IReadableFoo must have a getter for property, and may have a setter, too. Implementations of IWritableFoo must have both.

We could keep all the current keywords too, for backwards compatibility. However, I think you only need those two. That would be really sweet, since AS3 does not support that at the moment.

Thanks,

Pimm Hogeling

On Thu, Aug 13, 2009 at 02:26, Cauê Waneck <[hidden email]> wrote:
I don't think that is really possible, since the compiler seems to replace every call to a variable to its getter/setter function, so there's no way for it to know, at compile time, that the class implementation has a setter field different from the interface.
So maybe for now we've got to stick with having to declare the getters/setters on the interface itself.

Maybe the opposite would be possible: what could be done is to declare the getter/setter on the interface, and have a special keyword (it could be the default keyword, really), that will generate the function automatically. Meaning:

interface Elem
{
var x(get_x, set_x):Float
function get_x():Float;
function set_x(value:Float):Float;
}

class ElemImpl implements Elem
{
public var x(get_x, default);
public function new() { }

public function get_x():Float
{
trace("getting x");
return this.x;
}

}

This could automatically generate the function

public function set_x(value:Float):Float
{
return this.x = value;
}


That is not the current behaviour, but knowing how haXe works, this seems that could be an option

Oh! And a tip:

In haXe, you don't need to use _x:Float to store values. You can use the same variable name inside the getters and setters, just as it is used in here.

cheers!
Cauê Waneck
2009/8/12 Heinz Hölzer <[hidden email]>

it should be possible to declare a public property in an interface
and a read/write property in a class that implements this interface.

this is currently not possible:

interface Elem
{
  var x(getX, null):Float;
}

class ElemImpl implements Elem {
    public function new () {}
    private var _x:Float;
  public var x(getX, setX):Float;
    private function getX ():Float { return _x; }
  private function setX (value:Float):Float { _x = value; return _x; }
}

but it should be possible to hide the setter from the interface.

Is there a clean way to get this working?

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


--

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


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



--
Mark
--
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: Getter and Setter Problem

Mark de Bruijn | Dykam
Hmm, nice. Though I suggest it as anonymous functions:
        public var up( function(){ return _plain.up; }, function(r){ _plain.up = r; return r; } ):Float
Just because that would be even less breaking.

On Fri, Aug 14, 2009 at 11:33 AM, Justin Lawerance Mills <[hidden email]> wrote:
My Quick thoughts.

Currently it can take a lot of code that is not quick to scan, so while more syntax might not be good, letting the compiler infer some would allow code that was much easier to scan.

Taking a typical instance...

        public var up( _get_up, _set_up ):Float;
            
        private function _get_up():Float{ return _plain.up; }
        private function _set_up( r: Float ):Float{ _plain.up = r; return r; }
        
It would be useful to be able to use the following short hand..
        
        public var up( { return _plain.up; }, { _plain.up = r; return r; } ):Float

This is not introducing any new syntax just expecting the compiler to infer some for you, I don't see this would reduce any current possibilities.

Cheers

;j

On 14 Aug 2009, at 08:26, Mark de Bruijn wrote:

How would the method resolvement be done?

I suggest the C# solution - I know, again C# - which is that for an property getter and setter, the functions are named as follows: get_PropName and set_PropName. Actually C# hides this by the following syntax:
Type PropName {
get {
// Any return code
}
set {
// Any set code with value as value holding keyword.
}
}
Haxefied:
var PropName:Type {
get {
// Any return code
}
set {
// Any set code with value as value holding keyword.
}
}
Both fields are optional, like in haXe, and there isn't a interface problem as there is now, as naming is standardized.
This would be an breaking change, surely, but maybe solve the current problems.

and where haXe has 
public var PropName(default, null):Type
has C# two solutions, depending on your problem.
In case you want a readonly value, you use just
public Type PropName { get { return value; } } 
in case of private setting the following
public Type PropName { get; private set; }
which is automagically transformed into a getter/setter with the appropiate backend variable.

Let me hear your opinions.


2009/8/13 Pimm Hogeling <[hidden email]>
This is actually the biggest issue I'm having with haXe. Not too big of an issue, but still, the biggest.

I know this is a known problem because the compiler replaces the getters and the setters, and I don't know if this would be possible, but here are my thoughts. In the ideal world an interface has only two different keywords for getters and setters: "default" (or maybe an other word, such as "existing") meaning there must be a getter or a setter and "null" meaning there might not be a getter or a setter. If default is used, implementations of that interface must have a getter, or a setter. This would allow us to have:
interface IReadableFoo {
    public var property(default, null);
}
And:
IWritableFoo implements IReadableFoo {
    public var property(default, default);
}
Implementations of IReadableFoo must have a getter for property, and may have a setter, too. Implementations of IWritableFoo must have both.

We could keep all the current keywords too, for backwards compatibility. However, I think you only need those two. That would be really sweet, since AS3 does not support that at the moment.

Thanks,

Pimm Hogeling

On Thu, Aug 13, 2009 at 02:26, Cauê Waneck <[hidden email]> wrote:
I don't think that is really possible, since the compiler seems to replace every call to a variable to its getter/setter function, so there's no way for it to know, at compile time, that the class implementation has a setter field different from the interface.
So maybe for now we've got to stick with having to declare the getters/setters on the interface itself.

Maybe the opposite would be possible: what could be done is to declare the getter/setter on the interface, and have a special keyword (it could be the default keyword, really), that will generate the function automatically. Meaning:

interface Elem
{
var x(get_x, set_x):Float
function get_x():Float;
function set_x(value:Float):Float;
}

class ElemImpl implements Elem
{
public var x(get_x, default);
public function new() { }

public function get_x():Float
{
trace("getting x");
return this.x;
}

}

This could automatically generate the function

public function set_x(value:Float):Float
{
return this.x = value;
}


That is not the current behaviour, but knowing how haXe works, this seems that could be an option

Oh! And a tip:

In haXe, you don't need to use _x:Float to store values. You can use the same variable name inside the getters and setters, just as it is used in here.

cheers!
Cauê Waneck
2009/8/12 Heinz Hölzer <[hidden email]>

it should be possible to declare a public property in an interface
and a read/write property in a class that implements this interface.

this is currently not possible:

interface Elem
{
  var x(getX, null):Float;
}

class ElemImpl implements Elem {
    public function new () {}
    private var _x:Float;
  public var x(getX, setX):Float;
    private function getX ():Float { return _x; }
  private function setX (value:Float):Float { _x = value; return _x; }
}

but it should be possible to hide the setter from the interface.

Is there a clean way to get this working?

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


--

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


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



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


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



--
Mark

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

Re: Getter and Setter Problem

jlm@justinfront.net
yer its swings and roundabouts I just wanted to make sure lines dont get too long and actually if properly that should be.
.
public var up( function():Float{ return _plain.up; }, function(r):Float{ _plain.up = r; return r; } ):Float

but function is obvious and the type is always Float or null, so normally with my suggestion there are 3 possibles... 

public var up( { return _plain.up; }, { _plain.up = r; return r; } ):Float
public var up( null, { _plain.up = r; return r; } ):Float
public var up( function():Float{ return _plain.up; }, null ):Float

and obviously some mixed versions
public var up( function():Float{ return _plain.up; }, set_up ):Float
public var up( get_up, { _plain.up = r; return r; } ):Float

So my suggestion is so much easier to scan read, the function version you mentioned is more correct but really verbose and often will not be suited for one line, for any complex get or set you would use a separate method but for simple as per my example the shortest form seems sensible.

Cheers

;j

On 14 Aug 2009, at 10:53, Mark de Bruijn wrote:

Hmm, nice. Though I suggest it as anonymous functions:
        public var up( function(){ return _plain.up; }, function(r){ _plain.up = r; return r; } ):Float
Just because that would be even less breaking.

On Fri, Aug 14, 2009 at 11:33 AM, Justin Lawerance Mills <[hidden email]> wrote:
My Quick thoughts.

Currently it can take a lot of code that is not quick to scan, so while more syntax might not be good, letting the compiler infer some would allow code that was much easier to scan.

Taking a typical instance...

        public var up( _get_up, _set_up ):Float;
            
        private function _get_up():Float{ return _plain.up; }
        private function _set_up( r: Float ):Float{ _plain.up = r; return r; }
        
It would be useful to be able to use the following short hand..
        
        public var up( { return _plain.up; }, { _plain.up = r; return r; } ):Float

This is not introducing any new syntax just expecting the compiler to infer some for you, I don't see this would reduce any current possibilities.

Cheers

;j

On 14 Aug 2009, at 08:26, Mark de Bruijn wrote:

How would the method resolvement be done?

I suggest the C# solution - I know, again C# - which is that for an property getter and setter, the functions are named as follows: get_PropName and set_PropName. Actually C# hides this by the following syntax:
Type PropName {
get {
// Any return code
}
set {
// Any set code with value as value holding keyword.
}
}
Haxefied:
var PropName:Type {
get {
// Any return code
}
set {
// Any set code with value as value holding keyword.
}
}
Both fields are optional, like in haXe, and there isn't a interface problem as there is now, as naming is standardized.
This would be an breaking change, surely, but maybe solve the current problems.

and where haXe has 
public var PropName(default, null):Type
has C# two solutions, depending on your problem.
In case you want a readonly value, you use just
public Type PropName { get { return value; } } 
in case of private setting the following
public Type PropName { get; private set; }
which is automagically transformed into a getter/setter with the appropiate backend variable.

Let me hear your opinions.


2009/8/13 Pimm Hogeling <[hidden email]>
This is actually the biggest issue I'm having with haXe. Not too big of an issue, but still, the biggest.

I know this is a known problem because the compiler replaces the getters and the setters, and I don't know if this would be possible, but here are my thoughts. In the ideal world an interface has only two different keywords for getters and setters: "default" (or maybe an other word, such as "existing") meaning there must be a getter or a setter and "null" meaning there might not be a getter or a setter. If default is used, implementations of that interface must have a getter, or a setter. This would allow us to have:
interface IReadableFoo {
    public var property(default, null);
}
And:
IWritableFoo implements IReadableFoo {
    public var property(default, default);
}
Implementations of IReadableFoo must have a getter for property, and may have a setter, too. Implementations of IWritableFoo must have both.

We could keep all the current keywords too, for backwards compatibility. However, I think you only need those two. That would be really sweet, since AS3 does not support that at the moment.

Thanks,

Pimm Hogeling

On Thu, Aug 13, 2009 at 02:26, Cauê Waneck <[hidden email]> wrote:
I don't think that is really possible, since the compiler seems to replace every call to a variable to its getter/setter function, so there's no way for it to know, at compile time, that the class implementation has a setter field different from the interface.
So maybe for now we've got to stick with having to declare the getters/setters on the interface itself.

Maybe the opposite would be possible: what could be done is to declare the getter/setter on the interface, and have a special keyword (it could be the default keyword, really), that will generate the function automatically. Meaning:

interface Elem
{
var x(get_x, set_x):Float
function get_x():Float;
function set_x(value:Float):Float;
}

class ElemImpl implements Elem
{
public var x(get_x, default);
public function new() { }

public function get_x():Float
{
trace("getting x");
return this.x;
}

}

This could automatically generate the function

public function set_x(value:Float):Float
{
return this.x = value;
}


That is not the current behaviour, but knowing how haXe works, this seems that could be an option

Oh! And a tip:

In haXe, you don't need to use _x:Float to store values. You can use the same variable name inside the getters and setters, just as it is used in here.

cheers!
Cauê Waneck
2009/8/12 Heinz Hölzer <[hidden email]>

it should be possible to declare a public property in an interface
and a read/write property in a class that implements this interface.

this is currently not possible:

interface Elem
{
  var x(getX, null):Float;
}

class ElemImpl implements Elem {
    public function new () {}
    private var _x:Float;
  public var x(getX, setX):Float;
    private function getX ():Float { return _x; }
  private function setX (value:Float):Float { _x = value; return _x; }
}

but it should be possible to hide the setter from the interface.

Is there a clean way to get this working?

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


--

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


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



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


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



--
Mark
--
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: Getter and Setter Problem

Simon Krajewski
In reply to this post by Mark de Bruijn | Dykam
Mark de Bruijn schrieb:

>
>
> On Fri, Aug 14, 2009 at 10:02 AM, Simon Krajewski <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Or maybe I'm just missing the point. I admit I'm not really used
>     to allowing variables in interfaces, but it just seems like
>     something that doesn't make any sense to begin with and leads to
>     confusing designs.
>
>
> If it is confused depends on experiences. I've used interface
> properties a lot, interfaces is for me one of the reasons to use
> properties. Or what some C# guru's say, always expose properties,
> never fields. You get used to it.
This doesn't have anything to do with interfaces though, it's a matter
of encapsulation.

The problem with C# comparisons is that C# properties are different from
haXe properties. In C#, a property does not define any fields, it's just
one (or two) methods that pretend to be a field. It's perfecly valid to
have a property X without having any field resembling that name, whereas
in haXe it's the other way around: You define a property by defining a
field, then you say "oh and this field has the following properties". A
field on the other hand is already an implementation detail and these
should not be part of interfaces.

Regards
Simon


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

Re: Getter and Setter Problem

Mark de Bruijn | Dykam


On Fri, Aug 14, 2009 at 6:09 PM, Simon Krajewski <[hidden email]> wrote:
The problem with C# comparisons is that C# properties are different from haXe properties. In C#, a property does not define any fields, it's just one (or two) methods that pretend to be a field. It's perfecly valid to have a property X without having any field resembling that name, whereas in haXe it's the other way around: You define a property by defining a field, then you say "oh and this field has the following properties". A field on the other hand is already an implementation detail and these should not be part of interfaces.

Oh, that. but isn't that subject for change?

--
Mark

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

Re: Getter and Setter Problem

Nicolas Cannasse
In reply to this post by Heinz Hölzer-2
Heinz Hölzer a écrit :

> it should be possible to declare a public property in an interface
> and a read/write property in a class that implements this interface.
>
> this is currently not possible:
>
> interface Elem
> {
>    var x(getX, null):Float;
> }
>
> class ElemImpl implements Elem {
>      public function new () {}
>      private var _x:Float;
>    public var x(getX, setX):Float;
>      private function getX ():Float { return _x; }
>    private function setX (value:Float):Float { _x = value; return _x; }
> }
>
> but it should be possible to hide the setter from the interface.

This should now be allowed on CVS.

Best,
Nicolas

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

Re: Getter and Setter Problem

Danny Wilson
On 18 sep 2009, at 14:06, Nicolas Cannasse wrote:

This should now be allowed on CVS.


Thanks!

You actually implemented something I requested, haha. ;-)


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

Re: Getter and Setter Problem

Heinz Hölzer-2
In reply to this post by Nicolas Cannasse
that's great, thank you very much!!

Nicolas Cannasse schrieb:

> Heinz Hölzer a écrit :
>> it should be possible to declare a public property in an interface
>> and a read/write property in a class that implements this interface.
>>
>> this is currently not possible:
>>
>> interface Elem
>> {
>>    var x(getX, null):Float;
>> }
>>
>> class ElemImpl implements Elem {
>>      public function new () {}
>>      private var _x:Float;
>>    public var x(getX, setX):Float;
>>      private function getX ():Float { return _x; }
>>    private function setX (value:Float):Float { _x = value; return _x; }
>> }
>>
>> but it should be possible to hide the setter from the interface.
>
> This should now be allowed on CVS.
>
> Best,
> Nicolas
>



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