View mode: basic / threaded / horizontal-split · Log in · Help
February 18, 2012
Re: Inheritance of purity
Le 18/02/2012 16:04, Timon Gehr a écrit :
> For them, it is certainly safe. It is questionable how large the
> effective benefit is for const, since the const qualifier would be
> inherited for the method only, but not for its parameters.
>

The const qualifier does NEVER qualify a function. This is a 
misconception. In what we call const function, what is const is the 
hhidden parameter "this", not the function.
February 18, 2012
Re: Inheritance of purity
On 02/18/2012 10:06 PM, deadalnix wrote:
> Le 18/02/2012 16:04, Timon Gehr a écrit :
>> For them, it is certainly safe. It is questionable how large the
>> effective benefit is for const, since the const qualifier would be
>> inherited for the method only, but not for its parameters.
>>
>
> The const qualifier does NEVER qualify a function. This is a
> misconception.

I don't care whether or not it is a misconception. It is how the 
language is defined. If you want to change this, file an enhancement 
request.

> In what we call const function, what is const is the
> hhidden parameter "this", not the function.

Both are const. Ask the compiler.

struct S{
    void foo()const{
        static assert(is(typeof(this)==const));
        static assert(is(typeof(foo)==const));
    }
}

In fact, the incident that the method is const is what enables 
contravariant overriding of mutable/immutable by const methods. (This is 
not supported for the explicit formal parameter types.)
February 20, 2012
Re: Inheritance of purity
This doesn't make any sense. The const-ness of *this* is the logical
and obvious reason why methods overload on const. *this* is just as
good an valid parameter as everything other ones despite the fact,
that its hidden. The signature of two functions differ between *this*
parameter has different types. There we go: sensible overloading and
const never refers to the function itself.
The fact, that it does currently is a big bug, IMO.

On Sun, Feb 19, 2012 at 1:18 AM, Timon Gehr <timon.gehr@gmx.ch> wrote:
> On 02/18/2012 10:06 PM, deadalnix wrote:
>>
>> Le 18/02/2012 16:04, Timon Gehr a écrit :
>>>
>>> For them, it is certainly safe. It is questionable how large the
>>> effective benefit is for const, since the const qualifier would be
>>> inherited for the method only, but not for its parameters.
>>>
>>
>> The const qualifier does NEVER qualify a function. This is a
>> misconception.
>
>
> I don't care whether or not it is a misconception. It is how the language is
> defined. If you want to change this, file an enhancement request.
>
>
>> In what we call const function, what is const is the
>> hhidden parameter "this", not the function.
>
>
> Both are const. Ask the compiler.
>
> struct S{
>    void foo()const{
>        static assert(is(typeof(this)==const));
>        static assert(is(typeof(foo)==const));
>    }
> }
>
> In fact, the incident that the method is const is what enables contravariant
> overriding of mutable/immutable by const methods. (This is not supported for
> the explicit formal parameter types.)



-- 
Bye,
Gor Gyolchanyan.
February 23, 2012
Re: Inheritance of purity
On 17/02/2012 05:08, Kapps wrote:
> On Friday, 17 February 2012 at 03:24:50 UTC, Jonathan M Davis wrote:
>> On Thursday, February 16, 2012 18:49:40 Walter Bright wrote:
>>> Given:
>>>
>>> class A { void foo() { } }
>>> class B : A { override pure void foo() { } }
>>>
>>> This works great, because B.foo is covariant with A.foo, meaning it can
>>> "tighten", or place more restrictions, on foo. But:
>>>
>>> class A { pure void foo() { } }
>>> class B : A { override void foo() { } }
>>>
>>> fails, because B.foo tries to loosen the requirements, and so is not
>>> covariant.
>>>
>>> Where this gets annoying is when the qualifiers on the base class
>>> function
>>> have to be repeated on all its overrides. I ran headlong into this when
>>> experimenting with making the member functions of class Object pure.
>>>
>>> So it occurred to me that an overriding function could *inherit* the
>>> qualifiers from the overridden function. The qualifiers of the
>>> overriding
>>> function would be the "tightest" of its explicit qualifiers and its
>>> overridden function qualifiers. It turns out that most functions are
>>> naturally pure, so this greatly eases things and eliminates annoying
>>> typing.
>>>
>>> I want do to this for @safe, pure, nothrow, and even const.
>>>
>>> I think it is semantically sound, as well. The overriding function
>>> body will
>>> be semantically checked against this tightest set of qualifiers.
>>>
>>> What do you think?
>>
>> No. Absolutely not. I hate the fact that C++ does this with virtual.
>> It makes it so that you have to constantly look at the base classes to
>> figure out what's virtual and what isn't. It harms maintenance and
>> code understandability. And now you want to do that with @safe, pure,
>> nothrow, and const? Yuck.
>>
>> I can understand wanting to save some typing, but I really think that
>> this harms code maintainability. It's the sort of thing that an IDE is
>> good for. It does stuff like generate the function signatures for you
>> or fill in the attributes that are required but are missing. I grant
>> you that many D developers don't use IDEs at this point (at least not
>> for D) and that those sort of capabilities are likely to be in their
>> infancy for the IDEs that we _do_ have, but I really think that this
>> is the sort of thing that should be left up to the IDE. Inferring
>> attribtutes like that is just going to harm code maintainibility. It's
>> bad enough that we end up with them not being marked on templates due
>> to inferrence, but we _have_ to do it that way, because the attributes
>> vary per instantiation. That is _not_ the case with class member
>> functions.
>>
>> Please, do _not_ do this.
>>
>> - Jonathan M Davis
>
> In the situation where the IDE writes it for you, said IDE will help you
> only when you write the code.
>
> In the situation where the IDE tells you what they are (through
> something like hovering over it), it will help you no matter who writes
> the code. It is also significantly easier to implement, particularly
> taking into consideration things like style, comments, etc.

Exactly. If one is worried about having to look at the base classes, 
it's quite easy to check that info when you are using an IDE - for 
example, with a hover over the overriding function which lists all the 
parameters and attributes, and documentation too.


-- 
Bruno Medeiros - Software Engineer
February 23, 2012
Re: Inheritance of purity
On 17/02/2012 02:49, Walter Bright wrote:
> Given:
>
> class A { void foo() { } }
> class B : A { override pure void foo() { } }
>
> This works great, because B.foo is covariant with A.foo, meaning it can
> "tighten", or place more restrictions, on foo. But:
>
> class A { pure void foo() { } }
> class B : A { override void foo() { } }
>
> fails, because B.foo tries to loosen the requirements, and so is not
> covariant.
>
> Where this gets annoying is when the qualifiers on the base class
> function have to be repeated on all its overrides. I ran headlong into
> this when experimenting with making the member functions of class Object
> pure.
>
> So it occurred to me that an overriding function could *inherit* the
> qualifiers from the overridden function. The qualifiers of the
> overriding function would be the "tightest" of its explicit qualifiers
> and its overridden function qualifiers. It turns out that most functions
> are naturally pure, so this greatly eases things and eliminates annoying
> typing.
>
> I want do to this for @safe, pure, nothrow, and even const.
>
> I think it is semantically sound, as well. The overriding function body
> will be semantically checked against this tightest set of qualifiers.
>
> What do you think?

Sounds like a good idea.
I would even add to this that it might be useful to have similar syntax 
that would allow to define an override method without having to specify 
the return type nor the parameters of the overridden method. Sometimes 
in class hierarchies there is a lot of redundancy when overriding 
methods and it could be a nice small feature to reduce that (especially 
for methods with lots of parameters).

class Foo {
	int num;
	
	override opEquals {
		if(cast(Foo) o is null)
			return false;
		return this.num == (cast(Foo) o).num;
	}
	
	override toString {
		return to!(string)(num);
	}
	
}

-- 
Bruno Medeiros - Software Engineer
February 23, 2012
Re: Inheritance of purity
On 2/23/2012 8:59 AM, Bruno Medeiros wrote:
> I would even add to this that it might be useful to have similar syntax that
> would allow to define an override method without having to specify the return
> type nor the parameters of the overridden method. Sometimes in class hierarchies
> there is a lot of redundancy when overriding methods and it could be a nice
> small feature to reduce that (especially for methods with lots of parameters).
>
> class Foo {
> int num;
>
> override opEquals {
> if(cast(Foo) o is null)
> return false;
> return this.num == (cast(Foo) o).num;
> }
>
> override toString {
> return to!(string)(num);
> }
>
> }


Not a bad idea, but it would be problematic if there were any overloads.
February 23, 2012
Re: Inheritance of purity
If it can be applied to const, wouldn't it be like "const by 
convention" that you argued against?

On Friday, 17 February 2012 at 02:49:40 UTC, Walter Bright wrote:
> Given:
>
>     class A { void foo() { } }
>     class B : A { override pure void foo() { } }
>
> This works great, because B.foo is covariant with A.foo, 
> meaning it can "tighten", or place more restrictions, on foo. 
> But:
>
>     class A { pure void foo() { } }
>     class B : A { override void foo() { } }
>
> fails, because B.foo tries to loosen the requirements, and so 
> is not covariant.
>
> Where this gets annoying is when the qualifiers on the base 
> class function have to be repeated on all its overrides. I ran 
> headlong into this when experimenting with making the member 
> functions of class Object pure.
>
> So it occurred to me that an overriding function could 
> *inherit* the qualifiers from the overridden function. The 
> qualifiers of the overriding function would be the "tightest" 
> of its explicit qualifiers and its overridden function 
> qualifiers. It turns out that most functions are naturally 
> pure, so this greatly eases things and eliminates annoying 
> typing.
>
> I want do to this for @safe, pure, nothrow, and even const.
>
> I think it is semantically sound, as well. The overriding 
> function body will be semantically checked against this 
> tightest set of qualifiers.
>
> What do you think?
February 23, 2012
Re: Inheritance of purity
On Thursday, 23 February 2012 at 18:32:12 UTC, Walter Bright 
wrote:

> Not a bad idea, but it would be problematic if there were any 
> overloads.

It is still applicable to return types.
But i don't like the idea. If you omit arguments and return type, 
you force both yourself and the reader to check the base class 
for everything.
February 23, 2012
Re: Inheritance of purity
On Friday, 17 February 2012 at 03:24:50 UTC, Jonathan M Davis 
wrote:

> No. Absolutely not. I hate the fact that C++ does this with 
> virtual. It makes
> it so that you have to constantly look at the base classes to 
> figure out what's
> virtual and what isn't. It harms maintenance and code 
> understandability. And
> now you want to do that with @safe, pure, nothrow, and const? 
> Yuck.
>
> I can understand wanting to save some typing, but I really 
> think that this
> harms code maintainability. It's the sort of thing that an IDE 
> is good for. It
> does stuff like generate the function signatures for you or 
> fill in the
> attributes that are required but are missing. I grant you that 
> many D
> developers don't use IDEs at this point (at least not for D) 
> and that those
> sort of capabilities are likely to be in their infancy for the 
> IDEs that we
> _do_ have, but I really think that this is the sort of thing 
> that should be
> left up to the IDE. Inferring attribtutes like that is just 
> going to harm code
> maintainibility. It's bad enough that we end up with them not 
> being marked on
> templates due to inferrence, but we _have_ to do it that way, 
> because the
> attributes vary per instantiation. That is _not_ the case with 
> class member
> functions.
>
> Please, do _not_ do this.
>
> - Jonathan M Davis

As much as i hate the "pure const system trusted" spam, I don't 
think i like the idea either. If you are not using an IDE or a 
mouse, this would be hell. A language shouldn't be designed with 
such assumptions, unless you are Microsoft.

Thing is, this will make things harder not easier. (which i think 
is the intention here) When you overload a function, at most you 
copy/paste it from base class.
February 23, 2012
Re: Inheritance of purity
UTC, so wrote:
> If you are not using an IDE or a mouse, this would be hell.

lol wut? This isn't the 80's.

In all seriousness, I think you're decoupling inherently 
ingrained pieces: the language and it's tools. The same way you 
*need* syntax highlighting to distinguish structure, you *should* 
have other productivity tools to help you analyze data-layout. 
It's not like these tools don't exist in abundance on every 
platform. And MS has pulled some really stupid shit in its day, 
but it's developer tools and support do not fall under that 
category.
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home