February 21, 2007
Jarrett Billingsley wrote:
> True properties would be understood by the compiler as a distinct construct, rather than a hackish rewrite of assignment into a call.  This would allow, among other things, for templated properties; properties as the destination of op=, ++, and --; and the abolishment of the '&' when getting the address of a function or delegate.  As well as preventing such foolishness as "writefln = 6;". 

Yes, exactly.

-- 
serg.
February 22, 2007
Jarrett Billingsley wrote

>> What are 'real properties'?
> 
> True properties would be understood by the compiler as a distinct construct, rather than a hackish rewrite of assignment into a call.

But what are the benefits of "distinct constructs" in terms of provable correctness? Btw. using the assignment symbol as an alternative for a call seems very canonical to me.

> This would allow, among other things, for templated properties;

What are "templated properties"? Are you really declaring, that a
"real" property is a "tempĆ¼lated" property?

> properties as the destination of op=, ++, and --;

That is already possible, except you do not want to buy such.

> the abolishment of the '&' when getting the address of a function or delegate.

I don't understand that. Would you please elaborate on that?

-manfred
February 22, 2007
Miles wrote

> Some concepts to apply to true properties:

What are this concepts good for in terms of provable correctness?

> The above code does a "little" more than what it really looks like.

For me that particular lines look like an exit or a system call.

-manfred
February 22, 2007
Manfred Nowak wrote:
> Jarrett Billingsley wrote
> 
>>> What are 'real properties'?
>> True properties would be understood by the compiler as a distinct
>> construct, rather than a hackish rewrite of assignment into a
>> call.
> 
> But what are the benefits of "distinct constructs" in terms of provable correctness? Btw. using the assignment symbol as an alternative for a call seems very canonical to me.

Yes, it's quite normal for an assignment to a property to actually be a function call.
It's *not* normal for an assignment to a _function_ to call said function...

Some functions simply weren't meant to be properties.

[snip]
>> the abolishment of the '&' when getting the address of a function
>> or delegate.
> 
> I don't understand that. Would you please elaborate on that?

---
import std.stdio;

int foo() {
    writefln("foo() called");
    return 0;
}

void main() {
    auto x = foo;
    writefln("x: ", typeid(typeof(x)));
    auto y = &foo;
    writefln("y: ", typeid(typeof(y)));
}
---

Output:
---
foo() called
x: int
y: int()*
---

So currently the line declaring & initializing x calls 'foo' and uses the return type as value, instead of x becoming a function pointer and assigning a pointer to 'foo' as its value. To get the function pointer you need to add an '&', like with y.
If 'foo' was not implicitly a property, the language could be changed so that the extra '&' would no longer be necessary. There would only be one possible value for 'foo' to evaluate to: a pointer to the function.
February 22, 2007
Manfred Nowak wrote:

>> Some concepts to apply to true properties:
> 
> What are this concepts good for in terms of provable correctness?

They're mostly syntactic sugar for normal programming.

However, I suppose they would be quite handy for GUI programming tools (like QT designer, Visual Basic, etc). Any object/widget could have a visible list of properties. The user of the GUI tool could change these properties with a convenient set of textboxes, comboboxes, etc.

For example: properties for a push-button:
* label (string, textbox)
* font (font, font-dialog)
* height (uint, spinbox)
* width(uint, spinbox)
* top (uint, spinbox)
* left(uint, spinbox)
* border (enum, combobox)
* color (color, color-dialog)

If they were not recognized as real properties, they could not be in such a list. You wouldn't want every little function to end up there.

QT designer uses some sort of C macro-trick to specify the properties for their designer tool.

I suppose it would be good if D formalizes properties if only for this purpose.

-- 
Michiel
February 22, 2007
Miles wrote:

> 1. Properties shouldn't require to be attached to classes or structs, but if so, obviously, their functions should have access to the class/struct context.

Could you explain this one? What would a property without an associated struct/class be? A property of the whole program perhaps?

> 3. Properties are translated on basis on what operations would have been done on it if it were a variable, and not a fancy representation of a function call. This should allow  property++  and  property += 5  (given that it provides both a getter and at least a setter).

But ++, -- and op= have their own definitions with certain class-types that can't be defined in terms of only setter and getter functions. You wouldn't want those operators to be expanded to (= x + 1), (= x - 1), (= x op y), since those are less efficient and perhaps subtly different from their expanded counterparts.

If you truly want them to work on properties, they should be defined next to the setter and getter functions for that property.

> 5. Ordinary functions should always require () to be executed. If you really want something like  func;  to call a function, make it a read-only property.

I don't agree. Properties shouldn't be used as functions at all. They should manage writes and reads to a single property.

> 6. Ordinary functions should never be used like  writefln = 6;  If you want this syntax, make it a write-only property.

Agreed on this point. I hadn't even realized this was possible at the moment.

-- 
Michiel
February 22, 2007
"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:erkjin$2t1o$1@digitalmars.com...
> Jarrett Billingsley wrote
>
> What are "templated properties"? Are you really declaring, that a "real" property is a "tempĆ¼lated" property?

No, I mean with the current "properties" it's not possible to use template functions as properties, i.e.

class A
{
    void x(T)(T value)
    {
        writefln("I'm a property and I got: ", value);
    }
}

void main()
{
    A a = new A();
    a.x = 5; // error, a.x is not an lvalue
}

This is because a.x is actually a template with one function declared in it. When you try to assign to it, it makes no sense, since a.x is a template. That check happens _before_ the rewrite to a function call happens.

If, however, you had a separate property syntax:

class A
{
    property x
    {
        void opSet(T)(T value) // just guessing at the name
        {
            writefln("I'm a property and I got: ", value);
        }
    }
}

void main()
{
    A a = new A();
    a.x = 5; // works
}

D would find that a.x is a property.  Assignment to a property is unambiguously a call to its opSet function, and so the call would be rewritten as

a.x.opSet(5);

which can then cause the template to be instantiated properly.

I suppose this could also be done with the current "properties" :)  (and hopefully it will, because I know that there is no way in hell that any property syntax is ever going to make it into D)

>
> That is already possible, except you do not want to buy such.

Uhh... "buy"?  I don't know what you're trying to say, and I don't know how this is at all possible (unless you mean that "trick" that you posted involving using an extra dummy index).


February 23, 2007
Frits van Bommel wrote

> It's *not* normal for an assignment to a _function_ to call said
> function...
> Some functions simply weren't meant to be properties.
As said before, to me it seems as canonical as can be to have an assignment be interpreted as a call. Seen this way property is just a synonym for function---and the last sentence of the citation above becomes senseless.

> So currently the line declaring & initializing x calls 'foo' and uses the return type as value
This explanation lets me doubt, that the whole paradigm of get/set- properties, as presented, is of any usefulness.

If a set-property can be seen as an agent bound to a deposit box for input, then a get-property should return an agent capable of answering questions about the output, i.e. a delegate.

Do you see the consequences? The confusion you presented stems from not
distinguishing between the type of the return value "typeof" and the
type of the return agent "agentof":
  typeid( typeof( foo)) == "int"
  typeid( agentof( foo)) == "int()"

So "&foo" is undefined in the sense that it can approximately mean both:  "&typeof( foo)" and "&agentof( foo)".

-manfred
February 23, 2007
Jarrett Billingsley wrote

> No, I mean with the current "properties" it's not possible to use template functions as properties

I do not see the general usability if such would be enabled. Under which circumstances are untemplated classes useful, that contain templated functions?


> Uhh... "buy"?  I don't know what you're trying to say, and I don't know how this is at all possible (unless you mean that "trick" that you posted involving using an extra dummy index).

"Buy" means, that it is somehow costly.

For a class C one has to define an inner class I that implements the required op=, ++, and -- operators; has to declare within Class C the property as approximately "I property;"; has to extend the constructor of Class C by a "property= new I;".

Then one can code:
  auto c= new C;
  c.property <op>= ...

The specs
| Note: Properties currently cannot be the lvalue of an op=, ++, or
| -- operator.
do not hold for class properties.

-manfred
February 24, 2007
"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:erns67$2d2$1@digitalmars.com...
>
> I do not see the general usability if such would be enabled. Under which circumstances are untemplated classes useful, that contain templated functions?
>

I've found templated member functions immensely useful for doing things with variant-like types, though I encounter that a lot only because I'm writing a dynamically-typed scripting language.  Additionally, I use tuples for variadic functions because there are some things which would just be too ugly/slow with normal variadic functions.  I have a ".call" method in my interpreter class that I can just pass a tuple of arguments, and it'll automatically convert them to variant types and push them onto the interpreter stack, and it does that in about six lines of code.  Other uses would include maybe an IO class that has to be able to write or read any kind of data.  Much easier to do so with a templated member function than with a million overloads (I'm looking at _you_, std.stream).

> For a class C one has to define an inner class I that implements the required op=, ++, and -- operators; has to declare within Class C the property as approximately "I property;"; has to extend the constructor of Class C by a "property= new I;".
>
> Then one can code:
>  auto c= new C;
>  c.property <op>= ...

Oh, I see.  Yeah, that is possible.  You could even do it with an inner struct, too.  Would be lighter weight.

> The specs
> | Note: Properties currently cannot be the lvalue of an op=, ++, or
> | -- operator.
> do not hold for class properties.

It holds for _typical_ class properties, i.e. implicit function calls.  But you're right, they can be made to _look_ like they're working correctly with a workaround.