July 24, 2009
"Nick Sabalausky" <a@a.a> wrote in message news:h4bdmq$115p$1@digitalmars.com...
> "Lutger" <lutger.blijdestijn@gmail.com> wrote in message news:h4agu7$2cme$1@digitalmars.com...
>>
>> There have been a lot of discussions on this topic in the past but I
>> can't
>> recall any conclusions. Perhaps some brave soul would dare to write a DIP
>> on
>> properties?
>>
>
> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4
>
> I'm making a post for this over on D.announce...
>

Erm... I mean right here on digitalmars.D...


July 24, 2009
> no overloading of !, &&, ||,

What bothers me about overloading && and || is they are control flow constructs, not really "operators". For example, ?: is also a control flow operator, and it sensibly isn't overloadable in C++.

What if you could overload if..else.. statements? I'm sure someone somewhere could find a use for that, but it's still not a good idea.
July 24, 2009
Rainer Deyke wrote:
> Walter Bright wrote:
>> Rainer Deyke wrote:
>>> Syntactic ambiguity.  Confusion between an instance of a class and a
>>> reference to that instance.
>> I was initially thrown by this when I started some Java programming. But
>> it soon became clear this was an advantage, and I came to prefer it.
> 
> I like it in Python, where all variables are references.  Java is
> similar to Python in this regard, although the existence of primitive
> value types complicates the situation somewhat.
> 
> I don't like it in D, where reference types and value types coexist.  I
> especially don't like it in templates in D, where it may not be clear if
> you're dealing with a reference type or a value type until instantiation.


Is C++ really better in that regard? Given a non-trivial struct or class declaration, I'd be hard pressed to determine if it was meant to be a value or reference type.
July 24, 2009
Daniel Keep wrote:
> That's true, but you haven't addressed the other side of it: property
> setters.

Right. Consider the case where there's a pure function with no arguments, and an overload with the same name and one argument, and no other overloads. Wouldn't it be reasonable to take that as a property setter?

> With D, you would need to explicitly state which methods are properties
> manually somehow; dunno how you would, though.  Especially when you
> consider subclassing and mixins.

See my rule above - I think it'll work.
July 24, 2009
Walter Bright wrote:
> Jarrett Billingsley wrote:
>> This "D" programming language is great because it obviates make.
> 
> 
> Ok, now about make's ability to switch compilers without having to edit config files?

I don't do it that way. I can't imagine when you would mix D1 and D2 in a single build.
Instead, I have a set of trivial scripts to change the symlink for the 'dmd' directory. Nothing else needs to be aware of the compiler version. From then on, I just use bud.

I'll be pretty annoyed if the D2 compiler changes its name to DMD2.
July 24, 2009
Walter Bright wrote:
> Rainer Deyke wrote:
>> I like it in Python, where all variables are references.  Java is similar to Python in this regard, although the existence of primitive value types complicates the situation somewhat.
>>
>> I don't like it in D, where reference types and value types coexist.  I especially don't like it in templates in D, where it may not be clear if you're dealing with a reference type or a value type until instantiation.
> 
> 
> Is C++ really better in that regard? Given a non-trivial struct or class declaration, I'd be hard pressed to determine if it was meant to be a value or reference type.

Yes, it is.  Mainly because C++ doesn't have reference types in same way that D does.

In C++, values of *all* types (including primitive integral types and even pointer types) can be placed on the heap, and such values are *always* managed by (smart) pointers, with pointer syntax.  In this sense, all types in C++ can be used as reference types.

There are C++ classes that are meant to always be placed on the heap and
managed by a pointer.  They are the closest C++ has to D-style classes.
 They are exceedingly rare.  They're also easy to identify: their
constructors are protected, so the only way to instantiate them is by
calling a factory function that returns a (smart) pointer.


-- 
Rainer Deyke - rainerd@eldwood.com
July 24, 2009

Walter Bright wrote:
> Daniel Keep wrote:
>> That's true, but you haven't addressed the other side of it: property setters.
> 
> Right. Consider the case where there's a pure function with no arguments, and an overload with the same name and one argument, and no other overloads. Wouldn't it be reasonable to take that as a property setter?
> 
>> With D, you would need to explicitly state which methods are properties manually somehow; dunno how you would, though.  Especially when you consider subclassing and mixins.
> 
> See my rule above - I think it'll work.

Actually, I've now come up with a counter-example for the idea of using pure at all:

class Lazy(T)
{
    private
    {
        T v;
        T delegate() dg;
    }
    this(T delegate() dg) { this.dg = dg; }
    T value()
    {
        if( dg !is null )
        {
            v = dg();
            dg = null;
        }
        return v;
    }
}

You can't make value pure, but it is supposed to be a property.  One of the examples Nick gives in DIP4 is a property that accesses an SQL database; there's no way to make that pure!
July 24, 2009

Walter Bright wrote:
> 
>> no overloading of !, &&, ||,
> 
> What bothers me about overloading && and || is they are control flow constructs, not really "operators". For example, ?: is also a control flow operator, and it sensibly isn't overloadable in C++.
> 
> What if you could overload if..else.. statements? I'm sure someone somewhere could find a use for that, but it's still not a good idea.

Ask downs about that one :3
July 24, 2009
Michiel Helvensteijn wrote:
>>>>> * Operator overloading (no fine control over comparison operators,
>>>>  > fixed commutativity,
>>>>
>>>> This is deliberate. Operator overloading should be restricted to
>>>> implementing arithmetic like operations on objects, not completely
>>>> different things like what iostreams, Spirit and Boost::regex do.
>>> Arithmetic like operations like matrix multiplication (which is not
>>> commutative)?
>> I believe this is completely controllable with D.
> 
> Not if commutativity of the * operator is fixed. The documentation states
> that * is commutative, which in fact for integers it is. So if I overload *
> for matrices, for all the guarantees the docs give me, a D compiler might
> choose to swap the operands around (perhaps to get some memory alignment
> advantage), and the returned matrix would be incorrect.

That's not what the documentation means. * is only 'default commutative'. If a.opMul(b) is defined, by default you get b * a  == a*b. To prevent this behaviour, you just need to define a.opMul_r(b), or b.opMul(a).

(The documenation could be a bit clearer on this).
July 24, 2009
Daniel Keep escribió:
> 
> Walter Bright wrote:
>> Daniel Keep wrote:
>>> That's true, but you haven't addressed the other side of it: property
>>> setters.
>> Right. Consider the case where there's a pure function with no
>> arguments, and an overload with the same name and one argument, and no
>> other overloads. Wouldn't it be reasonable to take that as a property
>> setter?
>>
>>> With D, you would need to explicitly state which methods are properties
>>> manually somehow; dunno how you would, though.  Especially when you
>>> consider subclassing and mixins.
>> See my rule above - I think it'll work.
> 
> Actually, I've now come up with a counter-example for the idea of using
> pure at all:
> 
> class Lazy(T)
> {
>     private
>     {
>         T v;
>         T delegate() dg;
>     }
>     this(T delegate() dg) { this.dg = dg; }
>     T value()
>     {
>         if( dg !is null )
>         {
>             v = dg();
>             dg = null;
>         }
>         return v;
>     }
> }
> 
> You can't make value pure, but it is supposed to be a property.  One of
> the examples Nick gives in DIP4 is a property that accesses an SQL
> database; there's no way to make that pure!

Exactly! That's why I said "kind of pure" (well, maybe I didn't say that :-P), but the idea is that properties don't modify anything visible from outside of the symbol they are contained in. But it's hard to define what that means...