Allow overriding null setters in interfaces

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

Allow overriding null setters in interfaces

Danny Wilson
Hi Nicolas,

It would be great if the following compiled:

interface VO
{
        public var string (default, null) : String;
}

interface MutableVO
{
        public var string (default, setString) : String;
}

class Obj implements MutableVO, implements VO
{
        public var string (default, setString) : String;
       
        function setString(s){
                return string = s;
        }
       
        public function new()
        {
                string = "woo, modify me";
        }
       
        public function commit() : VO
        {
                string = "now i'm immutable!";
                return this;
        }
}

class Test
{
        static function main()
        {
                var mut = new Obj();
                mut.string = "no problem";
                var imm = mut.commit();
                // imm.string = "excellent compile err!";
        }
}

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

Re: Allow overriding null setters in interfaces

David Bergman
On Jun 23, 2009, at 7:11 PM, Danny Wilson wrote:

> Hi Nicolas,
>
> It would be great if the following compiled:
>
> interface VO
> {
> public var string (default, null) : String;
> }
>
> interface MutableVO
> {
> public var string (default, setString) : String;
> }

Currently, the accessors are looked up in compile-time and replaced  
with the corresponding method calls, such as

        VO obj;  obj.string = "foo";   =>  VO obj; obj.null("foo")... (i.e.,  
disallowed in compile-time)
        MutableVO obj: obj.string = "foo"; => MutableVO obj;  
obj.setString("foo");\

The upside of this early replacement is that even targets that have no  
notion of accessors can (seemingly) support them.

Again, it is important to distinguish these "compile-time" attributes  
from run-time attributes, which are basically the instance variables  
that takes up memory in the object structure; it is these latter  
attributes you reach through reflection.

Is this an ideal situation, having two worlds, one for compile-time  
and one for run-time? No, but it is better than any alternative -  
since it allows for a trivial homomorphism into the target space (no  
added wrappers in runtime) - and would be an even better solution if  
we (and I am looking at myself as well, carrying part of the guilt!)  
made this perfectly clear in our Wiki.

> class Obj implements MutableVO, implements VO
> {
> public var string (default, setString) : String;
>
> function setString(s){
> return string = s;
> }
>
> public function new()
> {
> string = "woo, modify me";
> }
>
> public function commit() : VO
> {
> string = "now i'm immutable!";
> return this;
> }
> }
>
> class Test
> {
> static function main()
> {
> var mut = new Obj();
> mut.string = "no problem";
> var imm = mut.commit();
> // imm.string = "excellent compile err!";
> }
> }

Will require a big change, where the accessor meta information,  
including the non-accessibility, is carried into the runtime  
structures for run-time use.

/David

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

Re: Allow overriding null setters in interfaces

Danny Wilson
Op Wed, 24 Jun 2009 01:27:43 +0200 schreef David Bergman  
<[hidden email]>:

> On Jun 23, 2009, at 7:11 PM, Danny Wilson wrote:
>
>> Hi Nicolas,
>>
>> It would be great if the following compiled:
>>
>> interface VO
>> {
>> public var string (default, null) : String;
>> }
>>
>> interface MutableVO
>> {
>> public var string (default, setString) : String;
>> }
>
> Currently, the accessors are looked up in compile-time and replaced with  
> the corresponding method calls, such as
>
> VO obj;  obj.string = "foo";   =>  VO obj; obj.null("foo")... (i.e.,  
> disallowed in compile-time)
> MutableVO obj: obj.string = "foo"; => MutableVO obj;  
> obj.setString("foo");\
>
> The upside of this early replacement is that even targets that have no  
> notion of accessors can (seemingly) support them.
>
> Again, it is important to distinguish these "compile-time" attributes  
> from run-time attributes, which are basically the instance variables  
> that takes up memory in the object structure; it is these latter  
> attributes you reach through reflection.
>
< ...
>
> Will require a big change, where the accessor meta information,  
> including the non-accessibility, is carried into the runtime structures  
> for run-time use.

Why? As you said, it's replaced at compile time with function calls. That  
happens in the interfaces just as well (or so i believe).

The mutable interface just has more functions then the immutable one...  
namely the setter functions.


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

Re: Allow overriding null setters in interfaces

David Bergman
On Jun 24, 2009, at 5:42 AM, Danny Wilson wrote:

> Op Wed, 24 Jun 2009 01:27:43 +0200 schreef David Bergman <[hidden email]
> >:
>
>> On Jun 23, 2009, at 7:11 PM, Danny Wilson wrote:
>>
>>> Hi Nicolas,
>>>
>>> It would be great if the following compiled:
>>>
>>> interface VO
>>> {
>>> public var string (default, null) : String;
>>> }
>>>
>>> interface MutableVO
>>> {
>>> public var string (default, setString) : String;
>>> }
>>
>> Currently, the accessors are looked up in compile-time and replaced  
>> with the corresponding method calls, such as
>>
>> VO obj;  obj.string = "foo";   =>  VO obj; obj.null("foo")...  
>> (i.e., disallowed in compile-time)
>> MutableVO obj: obj.string = "foo"; => MutableVO obj;  
>> obj.setString("foo");\
>>
>> The upside of this early replacement is that even targets that have  
>> no notion of accessors can (seemingly) support them.
>>
>> Again, it is important to distinguish these "compile-time"  
>> attributes from run-time attributes, which are basically the  
>> instance variables that takes up memory in the object structure; it  
>> is these latter attributes you reach through reflection.
>>
> < ...
>>
>> Will require a big change, where the accessor meta information,  
>> including the non-accessibility, is carried into the runtime  
>> structures for run-time use.
>
> Why? As you said, it's replaced at compile time with function calls.  
> That happens in the interfaces just as well (or so i believe).

Yes, in theory one could treat VO.string as a quite different beast  
than Obj.string, allowing for different accessor protocols. Such as

        interface Inter {  var string(default, setString); }
        class Clazz implements Inter {  var string(default, fooledYou);
                function fooledYou(var text: String) {
                        // haha, fooled you! I am not saving this text :-)
                        return text
                }
                function setString(var text: String) {
                        this.string = text;
                        return text;
                }
        }

This means that the object would act quite differently if the static  
type is Inter vz Clazz:

        Clazz obj1 = new Clazz();
        obj1.string = "foo";
        trace("Clazz.string = " + obj1.string); // print out   foo
        Inter obj2 = obj1;
        obj2.string = "bar";
        trace("Inter.string = " + obj2.string); // print out   foo

You might object that this is not what you were trying to achieve,  
your types merely differed in *accessibility* not the actual  
implementation, but for me that meta distinction is quite thin.  
Basically, one wants the object to behave the same no matter whether  
one uses the interface type or the implementing class as the static  
type. This will force one to go through the protocol of the interface  
when reaching the properties, i.e., using "null" (or "sorry, no  
access") in your VO/Obj case.

> The mutable interface just has more functions then the immutable  
> one... namely the setter functions.

They have different accessor protocols, and as I said above, having  
completely different behavior if you access the same object through  
one of its interface types vs another interface type or a class type  
is a recipe for disaster.

/David

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

Re: Allow overriding null setters in interfaces

Danny Wilson
Op Wed, 24 Jun 2009 17:25:09 +0200 schreef David Bergman  
<[hidden email]>:

  ...snip...
>
> You might object that this is not what you were trying to achieve, your  
> types merely differed in *accessibility* not the actual implementation,  
> but for me that meta distinction is quite thin. Basically, one wants the  
> object to behave the same no matter whether one uses the interface type  
> or the implementing class as the static type.

Exactly, I don't see how this is any different then the following:

interface VO {
  var s (default, null) : String;
}

class MutableVO implements VO {
  var s (default, null) : String;

  public function setS(str:String):String { return this.s = str; }
}

If you're passing around the type as interfaces, those classes should only  
care for read only access anyway as is defined in the interface.


What I wanted to use it for, is making sure when caching data in memory  
that would come from a database (for example) could not be modified by  
client code.

The cache however should be allowed to modify these objects (using the  
mutable type) to update them..!



> This will force one to go through the protocol of the interface when  
> reaching the properties, i.e., using "null" (or "sorry, no access") in  
> your VO/Obj case.
>
>> The mutable interface just has more functions then the immutable one...  
>> namely the setter functions.
>
> They have different accessor protocols, and as I said above, having  
> completely different behavior if you access the same object through one  
> of its interface types vs another interface type or a class type is a  
> recipe for disaster.

Behaviour is not different. What you're allowed to do is. Just like public  
and private properties.

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

Re: Allow overriding null setters in interfaces

Danny Wilson
Wow, I just noticed this is my crappiest English posting ever. Time for  
bed.

Op Wed, 24 Jun 2009 23:48:17 +0200 schreef Danny Wilson <[hidden email]>:

> stuff

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