View mode: basic / threaded / horizontal-split · Log in · Help
February 21, 2007
Re: Restrict Class Properties?
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
Re: Restrict Class Properties?
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
Re: Restrict Class Properties?
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
Re: Restrict Class Properties?
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
Re: Restrict Class Properties?
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
Re: Restrict Class Properties?
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
Re: Restrict Class Properties?
"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
Re: Restrict Class Properties?
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
Re: Restrict Class Properties?
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
Re: Restrict Class Properties?
"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.
1 2 3
Top | Discussion index | About this forum | D home