@property - take it behind the woodshed and shoot it?

kenji hara k.hara.pg at gmail.com
Thu Jan 24 20:43:04 PST 2013


2013/1/25 Jonathan M Davis <jmdavisProg at gmx.com>

> On Friday, January 25, 2013 11:09:15 kenji hara wrote:
> >    That is more serious than (a). If we adopt this rule, we will *really*
> > get lost the way to distinguish property functions and raw data fields.
> > (Note that: In current typeof(foo) already returns int. So AddressExp is
> > only one way to getting (normal|property) function information by its
> > type.) From the view of meta-programming, I think this makes a serious
> flaw.
>
> We could add a __trait which detected whether a field was an actual
> variable or
> not.


OK, let's think.

When a property function exists:
@property int foo();

#1 Only check whether it is a property function or not.
static assert(__traits(isProperty, foo) == true);
Pros: We can get minimum information.
Cons: We cannot check whether the foo is other function attributes: pure,
nothrow, @safe.

#2 Returns a type from __traits.
static assert(__traits(getPropertyType, foo).stringof == "@property int()");
Pros: We can access all information about property function.
Cons: __traits() is parsed as an expression, so we cannot use it as a type
directly.
   __traits(getPropertyType, foo)* fp; // declaring function pointer
   Instead, some template should be required.
   TypeTuple!(__traits(getPropertyType, foo))[0]* fp;

#3 Adding a special case in CastExpression
auto fp = &foo;    // Not allowed, because property function foo returns an
rvalue.
auto fp = cast(function)&foo;   //New, Gets a function pointer of foo
Pros1: Can access fully information of foo from typeof(fp).
Pros2: We can call a property function indirectly through function pointer.
Pros3: Newly syntax and semantics has no conflict with existings.
Cons: cast(function) and cast(delegete) necessary.

#4 An extension from #3
auto p = cast(@property)&foo;  // p is a function pointer.
auto p = cast(@property)&s.foo;  // p is a delegate.
Pros: Only one new syntax is necessary.
Cons: Ugly...

---

In basic, I don't like adding new __traits for this purpose, like #1 and #2.
In the compile world of D, a function type is already a first class object
to carry the information related function. Similarly, function pointer and
delegate are widely used as a runtime container to make runtime bindings to
function symbols.
>From these facts, creating an escape hatch from property function to normal
function type/pointer is enough worthwhile to me. It makes it possible to
reuse a number of meta-programming operations for normal function/function
type/function pointers.

#3 and #4 are comes from an existing feature, which picking up one from
overloaded functions by CastExpression.
void foo() {}
void foo(int) {}
auto fp = cast(void function())&foo;
// fp is equal to the address of first foo.

So, I prefer adding newly meanings to CastExp.

Kenji Hara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130125/85006cd3/attachment.html>


More information about the Digitalmars-d mailing list