Quantcast

properties in interfaces

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

properties in interfaces

Raoul Duke
hi,

would it be possible for interfaces to less overly specify the
properties? like, having to say what the name of the functions are in
the interface seems unfortunate to me because then the classes can't
make up their own internal private function names for them if they
like?

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

Re: properties in interfaces

Cauê W.
Since getters/setters are a compile-time feature, I can't see how it could be different :)

2011/12/9 Raoul Duke <[hidden email]>
hi,

would it be possible for interfaces to less overly specify the
properties? like, having to say what the name of the functions are in
the interface seems unfortunate to me because then the classes can't
make up their own internal private function names for them if they
like?

--
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
|  
Report Content as Inappropriate

Re: properties in interfaces

Raoul Duke
On Fri, Dec 9, 2011 at 7:46 AM, Cauê Waneck <[hidden email]> wrote:
> Since getters/setters are a compile-time feature, I can't see how it could
> be different :)

i don't know much about compilers... but the compiler would have the
information from the classes at compile time, no?

the point is to separate the orthogonal issues of permissions to
access vs. what the underlying function is that implements it.

sincerely.

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

Re: properties in interfaces

Franco Ponticelli
No it doesn't ... in a context where you are using only an interface type, the compiler cannot reliably say the real type of the object in use so it cannot really decide the getter/setter function to use.
I agree it could be a nice feature but I don't see how it cannot be applied. The only way I see is to "always" imply that getter/setters follow a very specific name convention (so every getter will be for example get_X).

Franco

On Fri, Dec 9, 2011 at 10:53 AM, Raoul Duke <[hidden email]> wrote:
On Fri, Dec 9, 2011 at 7:46 AM, Cauê Waneck <[hidden email]> wrote:
> Since getters/setters are a compile-time feature, I can't see how it could
> be different :)

i don't know much about compilers... but the compiler would have the
information from the classes at compile time, no?

the point is to separate the orthogonal issues of permissions to
access vs. what the underlying function is that implements it.

sincerely.

--
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
|  
Report Content as Inappropriate

RE: properties in interfaces

David Arno

I 100% agree with Raoul here. Interfaces are contracts only. So all an interface should be concerned about the visibility of a property (whether its read only, write only or read & write). It absolutely should not be concerned about how a class chooses to meet that contract.

 

So I would expect to be able to declare an interface as:

 

interface Interface1

{

                var x(default, default):Int;

}

 

And then in the class do:

 

var x(getX, setX):Int

 

and have it compile just fine. In fact I’m surprised that haXe allows functions to be specified for properties in interfaces as such a method should be private and thus should not be being specified in an interface. I accept that because of the way the haXe compiler has been implemented, this isn’t possible. The solution though should be to aim to fix it, maybe with haXe 3.

 

David.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Franco Ponticelli
Sent: 09 December 2011 18:02
To: The haXe compiler list
Subject: Re: [haXe] properties in interfaces

 

No it doesn't ... in a context where you are using only an interface type, the compiler cannot reliably say the real type of the object in use so it cannot really decide the getter/setter function to use.

I agree it could be a nice feature but I don't see how it cannot be applied. The only way I see is to "always" imply that getter/setters follow a very specific name convention (so every getter will be for example get_X).

 

Franco

On Fri, Dec 9, 2011 at 10:53 AM, Raoul Duke <[hidden email]> wrote:

On Fri, Dec 9, 2011 at 7:46 AM, Cauê Waneck <[hidden email]> wrote:
> Since getters/setters are a compile-time feature, I can't see how it could
> be different :)

i don't know much about compilers... but the compiler would have the
information from the classes at compile time, no?

the point is to separate the orthogonal issues of permissions to
access vs. what the underlying function is that implements it.

sincerely.


--
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
|  
Report Content as Inappropriate

Re: properties in interfaces

Cauê W.
I don't really see what's wrong wih defining a getter/setter name. After all, an interface is really a contract, and e.g. in Java you don't have variables so you really define the actual getX / setX functions in the interface.

2011/12/9 David Arno <[hidden email]>

I 100% agree with Raoul here. Interfaces are contracts only. So all an interface should be concerned about the visibility of a property (whether its read only, write only or read & write). It absolutely should not be concerned about how a class chooses to meet that contract.

 

So I would expect to be able to declare an interface as:

 

interface Interface1

{

                var x(default, default):Int;

}

 

And then in the class do:

 

var x(getX, setX):Int

 

and have it compile just fine. In fact I’m surprised that haXe allows functions to be specified for properties in interfaces as such a method should be private and thus should not be being specified in an interface. I accept that because of the way the haXe compiler has been implemented, this isn’t possible. The solution though should be to aim to fix it, maybe with haXe 3.

 

David.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Franco Ponticelli
Sent: 09 December 2011 18:02
To: The haXe compiler list
Subject: Re: [haXe] properties in interfaces

 

No it doesn't ... in a context where you are using only an interface type, the compiler cannot reliably say the real type of the object in use so it cannot really decide the getter/setter function to use.

I agree it could be a nice feature but I don't see how it cannot be applied. The only way I see is to "always" imply that getter/setters follow a very specific name convention (so every getter will be for example get_X).

 

Franco

On Fri, Dec 9, 2011 at 10:53 AM, Raoul Duke <[hidden email]> wrote:

On Fri, Dec 9, 2011 at 7:46 AM, Cauê Waneck <[hidden email]> wrote:
> Since getters/setters are a compile-time feature, I can't see how it could
> be different :)

i don't know much about compilers... but the compiler would have the
information from the classes at compile time, no?

the point is to separate the orthogonal issues of permissions to
access vs. what the underlying function is that implements it.

sincerely.


--
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
|  
Report Content as Inappropriate

Re: properties in interfaces

Franco Ponticelli
In reply to this post by David Arno
Even if you agree with Raoul it is still impossible to add that feature. Properties must be changed in a way that will be no more compatible with the current ones and I personally like how they are implemented.

Franco

On Fri, Dec 9, 2011 at 11:31 AM, David Arno <[hidden email]> wrote:

I 100% agree with Raoul here. Interfaces are contracts only. So all an interface should be concerned about the visibility of a property (whether its read only, write only or read & write). It absolutely should not be concerned about how a class chooses to meet that contract.

 

So I would expect to be able to declare an interface as:

 

interface Interface1

{

                var x(default, default):Int;

}

 

And then in the class do:

 

var x(getX, setX):Int

 

and have it compile just fine. In fact I’m surprised that haXe allows functions to be specified for properties in interfaces as such a method should be private and thus should not be being specified in an interface. I accept that because of the way the haXe compiler has been implemented, this isn’t possible. The solution though should be to aim to fix it, maybe with haXe 3.

 

David.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Franco Ponticelli
Sent: 09 December 2011 18:02
To: The haXe compiler list
Subject: Re: [haXe] properties in interfaces

 

No it doesn't ... in a context where you are using only an interface type, the compiler cannot reliably say the real type of the object in use so it cannot really decide the getter/setter function to use.

I agree it could be a nice feature but I don't see how it cannot be applied. The only way I see is to "always" imply that getter/setters follow a very specific name convention (so every getter will be for example get_X).

 

Franco

On Fri, Dec 9, 2011 at 10:53 AM, Raoul Duke <[hidden email]> wrote:

On Fri, Dec 9, 2011 at 7:46 AM, Cauê Waneck <[hidden email]> wrote:
> Since getters/setters are a compile-time feature, I can't see how it could
> be different :)

i don't know much about compilers... but the compiler would have the
information from the classes at compile time, no?

the point is to separate the orthogonal issues of permissions to
access vs. what the underlying function is that implements it.

sincerely.


--
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
|  
Report Content as Inappropriate

Re: properties in interfaces

Juraj Kirchheim
Well, personally I think the way properties are implemented now
overshoots the mark. I really wonder what the value is in being able
to specify the accessor name. Sure, it's kinda clever, but is it
really usefull? Personally, I have long decided to call all getters
get_ident and all setters set_ident. Firstly this is what dynamic is
means anyway, secondly its pretty straight forward and thirdly by
convention underscore is uncommon in haXe, so collision is rather
unlikely, plus you have a relatively good chance to determine by
reflection whether a field has an accessor defined.

Of course many might feel deprived of a crucial freedom. I can't tell that.

One option would be to allow a different value for fields, as in:

     public var x(function, function):X;

Just like dynamic, the compiler would assume that get_x and set_x are
the corresponding accessors, but in this case it would ensure their
existence at compile-time.

And in an interface, a plain var would not be assumed (default,
default) but (function, function) instead.

On Fri, Dec 9, 2011 at 8:53 PM, Franco Ponticelli
<[hidden email]> wrote:
> Even if you agree with Raoul it is still impossible to add that feature.
> Properties must be changed in a way that will be no more compatible with the
> current ones and I personally like how they are implemented.
>
> Franco

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